Outage status page for small wireless ISPs

The idea

When a tower goes down, a 500-subscriber WISP with a two-person office takes a hundred calls an hour, and every one of them is answered by the same person who should be fixing the tower. Generic status pages like Statuspage assume a SaaS audience checking a URL; they have no concept of which subscribers hang off which piece of infrastructure, so they either notify everyone or no one.

The wedge is the subscriber-to-tower mapping. Once the WISP has tagged customers to towers via a CSV import, one form fills the public status page and texts exactly the people affected, and the phone stops ringing. WISPs are a tight, reachable niche (WISPA, Facebook groups, the Brothers WISP community) and nobody is building for them at this price.

Who pays

The WISP owner-operator pays, typically the same person answering the phones. 49 dollars a month is trivially justified against a single afternoon of missed truck rolls, billed monthly per company with unlimited subscribers and SMS passed through at cost or capped generously. Distribution is direct: WISP forums, the WISPA vendor list, and Facebook groups where operators openly complain about outage-day call volume.

MVP scope

• Tower and sector setup, subscribers imported by CSV and tagged to towers
• Declare Outage form that updates the public page and SMS-blasts only affected subscribers
• Public per-company status page with incident history
• Incident update timeline with resolved state and delivery counts
• Skip for v1: billing integration, email notifications, subscriber self-service signup, API or monitoring integrations that auto-detect outages

Build TowerStatus, a web app for small wireless ISPs to manage outage communication. Stack: Next.js (App Router), Supabase for auth and Postgres, Twilio for SMS.

Core flow: an operator logs in (magic-link auth, no passwords), sets up their infrastructure as a list of towers, each with named sectors. They import subscribers via CSV upload with columns name, phone, tower, sector; store rows in a subscribers table keyed to tower/sector. When something breaks, the operator opens the Declare Outage form: pick affected towers/sectors, choose a status (investigating, identified, monitoring, resolved), write a one-line message. Submitting does two things in one transaction: updates the public status page and queues SMS via Twilio to only the subscribers on affected towers.

Pages: /login, /dashboard (tower list with current status), /outage/new, /outage/[id] (post updates, mark resolved, see SMS delivery counts), /import (CSV upload with a column-mapping step and dedupe on phone number), and a public page at /s/[company-slug] showing per-tower status with incident history, no login required.

Implementation details: send SMS through a Supabase Edge Function that batches Twilio calls at 50 messages per invocation to avoid timeouts, and record Twilio delivery status via webhook. Rate-limit outbound to one blast per outage update.

Pricing: single tier, 49 dollars/month, 14-day trial, Stripe checkout can wait until v2 (use a manual flag on the account).