OpsSwipe

Production breaks while you're away. OpsSwipe puts the fix on your phone, and won't let a code fix merge until CI replays the exact requests that failed in production.

Comment 1

Next Gen Award entry, built solo by an 18-year-old university student. AI can already write the fix. OpsSwipe proves it: a code fix can only merge after CI replays the exact requests that failed in production, and nothing runs without your swipe and fingerprint.

Try the app: download the Android APK. Sign in, swipe the practice card, confirm with your fingerprint. No setup needed.

Inspiration

I'm a student, and I build and run backends for my own apps. The worst moment of that isn't the bug. It's finding out while I'm away from my laptop, and then finding out that my "fix" didn't actually fix it.

That second part kept bugging me. The tests passed. The pull request merged. Production was still returning 500s, because nobody tested the request my users actually sent. And now AI tools write fixes for us (Sentry's Seer opens fix PRs, Claude Code and Cursor write half our code), but those fixes are merged against the same tests that missed the bug in the first place.

Pagers like PagerDuty assume a team, a rotation and a laptop. Indie developers have none of those. They have a phone. So I asked: what if the failing production traffic became the test, and fixing it took one swipe?

What it does

OpsSwipe is an on-call pager for indie developers and small teams. When production breaks, your phone rings like an alarm and shows one card: what broke, the likely cause, and one suggested fix.

1. It finds out first. Your app reports its own 5xx responses (signed with HMAC), and a health check runs every minute for services too dead to report. Sentry alerts and any monitoring tool (Grafana, Alertmanager, plain JSON) can feed it too. A single error isn't an outage: OpsSwipe waits for a second one to confirm it, so it doesn't page you for noise.

2. It suggests the right fix, with a reason. Deterministic rules decide ("a deploy landed 1 minute before the failure, so roll back"). An AI model gives a second opinion that is shown to you, but never obeyed by the code.

3. One swipe, one fingerprint. Restart or roll back on Render and Railway, reboot a Google Cloud VM, open a revert PR, or have AI write the smallest fix plus a regression test. The server only runs a fix after verifying a key that the phone's secure hardware releases after your fingerprint.

4. Proof before merge — the core idea. A code fix is a pull request that carries the requests that failed in production (.opsswipe/replays/<commit>.json). A GitHub Actions workflow replays them against the PR's build, in locked-down containers, and runs your tests. OpsSwipe grades the run itself: every request must go from 5xx to 2xx. Only then does Merge unlock, and the merge is pinned to the exact commit that was proven. The replay file stays in the repo, so every future PR is checked against that outage forever.

5. Proof after deploy. "Back up" is only reported once the failing requests work in production again. If a fix didn't take, the card comes back.

6. It keeps your team and users in the loop. Alerts in Slack or Discord, a public status page that updates itself, a postmortem after every outage, team invites by email with 5-minute escalation, and an approval API so AI agents (a Claude Code hook is included) must ask your phone before running risky commands.

In the demo video everything is real, on real infrastructure, recorded on a real Android phone:

  • Google Cloud VM: a bad release, a revert PR carrying GET /api/price → 500, CI proves it, merge from the phone: back up after 2m 44s in total.
  • Railway: a deploy just landed, so OpsSwipe suggests Roll back. The free outage is used, so the RevenueCat paywall appears; after the Test Store purchase the rollback runs: back up after 52 s.
  • Render: rolled back from the phone: back up after 50 s.

How RevenueCat is used

RevenueCat isn't just the paywall here; it's part of how the product thinks about value.

  • Plans: Free (your first outage, start to finish), Pro ($14.99/month or $119.99/year) and Team ($39.99/month or $359.99/year, up to 10 people). Entitlements pro and team, a default offering, and a RevenueCat Paywall, so price and copy change from the dashboard.
  • The paywall appears at the moment of highest intent: production is down and your free outage is used. The 7-day trial is offered once during onboarding, never in the middle of an outage.
  • Billing is per outage, not per action. Metering each action would put a paywall between a revert PR and its proven merge, in the middle of your free outage. So the free tier is one whole incident, counted by an atomic Postgres function and refunded if the first fix fails.
  • Nothing unlocks on the phone. Every fix checks the entitlement on the server with RevenueCat's REST API. The phone never decides.
  • Billing can't block a fix. A RevenueCat webhook keeps a copy of each plan's expiry, used if RevenueCat's API is unreachable, so the pager never fails because billing did.
  • Revenue at risk: you can connect your own RevenueCat project (read-only v2 key), and every incident shows what the outage is costing you in dollars per hour, from your real revenue over the last 28 days.
  • One identity everywhere: the Supabase user id is the RevenueCat appUserID, so a plan follows you to a new phone; Restore Purchases and the Customer Center are built in.

How I built it

Built solo in under four days: the first commit is 28 September 2026 and the last is 1 October (more than 90 commits, all public in the repo history).

  • App: Expo SDK 57 and React Native (TypeScript), Reanimated and Gesture Handler for the swipe, expo-local-authentication for the fingerprint, expo-notifications for alarm-style push, react-native-purchases and react-native-purchases-ui for RevenueCat.
  • Backend: Supabase: Postgres with row-level security on every table, Vault for every user secret, Edge Functions (Deno) for everything that holds a key, pg_cron for the minute-by-minute health check.
  • Providers, all plain fetch: the GitHub App API (1-hour installation tokens; revert and fix PRs built with the Git Data API, no clone), Render's REST API, Railway's GraphQL API with OAuth, and Google Compute Engine with a JWT signed by WebCrypto.
  • Proof: a GitHub Actions workflow that authenticates with GitHub's OIDC token, so users store no secrets in their repo.
  • AI: a swappable, OpenAI-compatible provider (NVIDIA Nemotron with a Groq backup in the demo, or Claude on Vertex AI). It writes second opinions, fixes and postmortems, but rules decide and every output is checked by code.
  • Built with Claude Code as my pair programmer, through design, tests and a security audit.

Challenges I ran into

  • Proving a fix without breaking production again. Replaying a failed POST /checkout in production would create real orders. So requests are replayed only against the PR's build in CI, never production; samples carry no headers or cookies, secret-looking values are redacted, and bodies are capped.
  • Making the proof trustworthy. A PR could try to fake its own result. The proof is signed with GitHub's OIDC token, bound to the exact commit OpsSwipe opened, run in locked-down containers, and graded by OpsSwipe (a 4xx or a redirect is not a fix). The merge passes that commit's SHA, so GitHub refuses it if anything was pushed after the proof.
  • Connecting clouds without holding people's keys. Google Cloud access is a custom reset-only role on one VM, granted with your own Google sign-in and removed when you disconnect. Railway uses OAuth scoped to the projects you choose. Render has no OAuth, so its key is encrypted in Vault and never sent back to the phone.
  • Real-world rough edges I only found by using it. Railway marks a replaced deployment REMOVED, never SUCCESS, so my first rollback couldn't find anything to roll back to. It now uses Railway's own canRollback field. Railway's sign-in page also never hands control back to the app, so the app now finishes the connection itself when you close the window.

Accomplishments I'm proud of

  • The verified-fix loop works end to end on real infrastructure: break production, get paged, swipe, prove in CI, merge the proven commit, and verify production recovered, all from a phone.
  • Security without shortcuts: least-privilege cloud access, row-level security with SQL tests, fingerprint-bound fix keys checked by the server, OIDC-signed proofs, and an independent security audit whose findings are all fixed and documented.
  • Quality: 114 backend tests, SQL tests on Postgres 17 for tenant isolation and the free-outage meter, a 15-case labelled eval that must score 100% on safety for every fix suggestion, and CI on every push.

What I learned

  • The hard part of AI-written code isn't generating it; it's trusting it. The strongest trust signal I found is the exact traffic that failed.
  • Where a paywall sits matters as much as the price. Per-action billing felt fair on paper and was terrible mid-outage.
  • Every cloud provider is different in ways the docs don't say. You only find them by breaking real things on purpose.

What's next for OpsSwipe

The pager is the way in. The real product is the idea underneath it: the traffic that failed in production becomes the test. Everything next grows from that.

1. Prove every fix, not just code fixes. Before a rollback, CI builds the older commit and replays the failing requests against it, so "roll back" is proven the same way a revert PR is. Never against production.

2. An outage memory for every repo. Each outage already leaves its replay file in the repo. Next: every PR shows which past outages it was checked against, and warns when a change would bring one back, before it ships.

3. A human in the loop for every AI agent. An MCP server on top of the Approval API, so any agent (Claude Code, Cursor, Devin, your own) has to get a swipe and a fingerprint before it runs something risky in production.

4. On-call for small teams. Rotations, phone-call and SMS escalation when nobody answers, and two-person approval for risky fixes, all on the Team plan.

5. Revenue decides what comes first. A one-tap RevenueCat connection instead of a pasted key. When two things break at once, the one costing more per hour is paged first, and the weekly report shows the revenue each outage cost and how much the fix saved.

6. Everywhere indie apps run. Google Play and iOS releases, plus Fly.io, Vercel and Kubernetes, with scale-up as a new kind of fix.

Built With

Share this project:

Updates

Submission history