Opportunities › Distributed WAF with independent DNS failover › Proposed app
Sidegate
Run two WAF providers with independent DNS failover, from one policy
- Score
- 35
- confidence 42
- Evidence
- 4
- items on the page
- Rivals
- 1
- named in sources
- First version
- 60 d
- estimate
- Type
- Mobile app
- PWA: installs on iPhone and Android
- Market since
- 2010
- Mature market · AI estimate
ScreensConcept
Mobile app: On-call engineers need to approve critical failover decisions and monitor SLA impact instantly during incidents, whether at their desk or away. Sample screens on a phone, in the proposed brand. Their numbers are sample data.
Services
99.97%
- api.example.comPath A active
- app.example.comPath B active
- Provider A probesHealthy
- Provider B probesHealthy
- Rule parity41 of 42
About this appAI proposal
Sidegate lets engineering teams put more than one WAF provider in front of their apps without making any one of them the single point of failure. You write your rules once. Sidegate keeps them in step across providers and watches each path from outside.
When a provider's WAF or DNS path degrades, Sidegate moves traffic to another path through DNS hosted separately from the failing provider. It also tracks how much of your annual availability budget each incident used, so you can see the cost of each dependency.
It is built for teams with contractual uptime targets who want WAF features but do not want their SLA tied to one vendor. Sidegate is a control plane: it does not replace your providers, it keeps you from depending on just one.
- Tagline
- Your WAF should not be your single point of failure.
- Voice
- CalmPrecisePlain
- Why this name
- A side gate is the second way in when the main one is shut. The name says the product adds a route without replacing yours.
In the first version
Members say which features they would use. It tells PWAS what people want; it changes no score.
One policy, many providers
Write rules once and push them to each connected WAF. Sidegate flags any rule a provider cannot express, so parity gaps show up before an outage.
No member yet
Independent DNS failover
Failover records live in a DNS provider separate from your WAF vendors, so a vendor outage cannot block the switch.
No member yet
Outside-in health probes
Probes from several regions check each provider path for real requests, not just pings, and decide when a path is unhealthy.
No member yet
SLA budget tracker
See your yearly downtime allowance, how much each incident used, and which provider caused it.
No member yet
Brand identityAI proposal
Check the name against trademark registers before using it.
Palette
#12262BHarbor Ink · text and icon background#F4F1EAPaper · surface#0E5A63Deep Teal · primary#E8A33DSignal Amber · accent#C2452DAlarm Brick · data, failing state
Typography
Aa
Sidegate
ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789
Your WAF should not be your single point of failure.
PricingAI proposal
The material gives no competitor prices and no usage figures. These tiers are a starting point to test; the opportunity suggests pricing by traffic, redundancy and features.
Starter
$99 a month
- 2 WAF providers
- 3 services
- Health probes from 3 regions
- Email and push alerts
Team
$399 a month
- Up to 4 providers
- 25 services
- Probes from 8 regions
- Approve-first failover
- SLA budget reports
Enterprise
Contact us
- Unlimited services
- Custom probe regions
- SSO and audit export
What it could be worthEstimate
What a software business making this much sells for today, from real deals. Pick a monthly revenue.
If it makes
Worth about
$194,000
Sale range $132,000 to $263,000
$120,000 a year in revenue
From 87 software businesses listed and sold on Empire Flippers in the last year, revenue vetted by the broker: they sell for about 19× their monthly revenue, most between 13× and 26×.
Measured on profit, the middle deal is 32× monthly net profit: about 2.7 years of profit.
An estimate, not an offer or financial advice. A real price depends on profit, growth, churn, how much of the work is the owner's, and the buyer.
How it would growAI proposal
How the product would reach new customers through its own use, and how the first ones would be found. A plan to test, not a result.
- Built-in loop
- No loop in the product. Sidegate runs behind the scenes for the infrastructure team. Public status pages or incident exports could mention it, but customers' end users do not use it, so there is no built-in loop.
- Do they become customers?
- Reach comes from content, outage write-ups and direct outreach. To test: whether SRE leads at high-SLA firms will pay for a second WAF path after reading a post-incident analysis.
- First customers
- SRE and platform leads at B2B SaaS companies of 50 to 500 staff with a contractual 99.9% or higher uptime SLA, who use one WAF provider today.
- Where to reach them
- Hacker News and engineering blogs: Publish a clear write-up on how an SLA budget is used up by a WAF outage and how a second path would have changed it.
- SRE and DevOps communities: Offer a free SLA budget calculator in relevant Slack groups and forums, and invite users to a design-partner list.
- Direct outreach: Email SRE leads at companies that publicly posted incident reports mentioning WAF or DNS outages.
- First milestone
- Five design partners each paying for a Starter or Team plan after a two-week pilot of one service with a backup path.
Why people already pay for this
- VerifiedHacker News post received 28 points and 16 comments
- Public claimCloudflare WAF outages consume catastrophic amounts of availability budget for high-SLA customers
- Public claimTeams value WAF features but reject the availability risk of centralization
- Public claimCentralized WAF architecture contradicts the distributed design of DNS
Tech stack
Every proposal builds on the same PWA base, installable from the browser on any phone or computer. Dashed boxes are what this app adds.
- AppNext.js and TypeScript
- PWAManifest and service worker
- UITailwind CSS
- Data and authSupabase Postgres
- PaymentsStripe
- EmailResend
- HostingVercel
- This app · Probe networkMulti-region workers on a cloud separate from the WAF…Probes must run outside the providers they watch, or they fail with them.
- This app · Secondary DNSAuthoritative DNS API on a separate providerFailover records must not share a vendor with the WAFs being switched.
RisksAI inference
- TechnicalRule parity is hard. Providers differ in rule languages, bot scoring and managed rulesets, so some protections cannot be copied exactly and could leave one path weaker.
- TechnicalSwitching DNS between WAF paths involves TLS certificates, origin allow-lists and DNS TTL delays. A bad failover could cause an outage rather than prevent one.
- PlatformProviders may limit API access, change rule formats, or forbid some setups in their terms. Connectors need constant upkeep.
- CommercialTeams may judge a second WAF too costly or complex. Evidence is only a Hacker News thread with public claims; paying demand is unproven.
- RegulatoryThe control plane holds API keys with power over customers' traffic. Buyers will ask for security reviews and audit logs before trusting it.
Everything marked AI proposal or AI inference was written by a model from the evidence on the opportunity page. The proposed name must be checked against trademark registers before it is used.