Shipping Sentinel solo, from idea to App Store

Sentinel started as a single sentence in a Notion doc. "What if anyone could run the kind of intelligence pass that newsrooms and hedge funds run, without paying for either of them?" Nine months later it shipped on the App Store and at sentinelintel.app as a freemium iOS and web product. I built it by myself, end to end. This is what I would tell a friend who wanted to do the same thing tomorrow.

Pick the scope you can finish

The first PRD for Sentinel listed twelve features. The one that shipped listed five. The cut happened in the first week and saved the project. A solo team can ship a great five-feature product or a broken twelve-feature one. There is no third option.

The five that survived: a topic search that returns a verified intelligence report, source attribution with confidence scores, a daily push of breaking developments on tracked topics, audio briefings, and Ask Sentinel chat over any report. Everything else is post-launch.

Pick the constraints, then pick the stack

Constraints first. Native iOS for credibility with the audience I cared about. Free tier so a curious user can finish their first query without paying. Pro at a price point that makes sense as a daily-news habit. Production cost capped at two figures per month until a real subscriber count justifies more.

The stack falls out of those constraints. SwiftUI for iOS so the UI stays one codebase. Supabase as the back end because RLS plus Postgres plus Edge Functions plus auth in one box pays for itself in week one. Gemini 2.5 Flash for analysis because cost per million tokens is the lowest of any frontier model that hits the reasoning bar Sentinel needs. Firecrawl for scrape because writing a multi-region scraper as a solo founder is a year of work I did not have. StoreKit 2 because Pro is iOS-first and Apple's billing is non-negotiable on phone.

Build the pipeline once, then iterate the prompts

The single biggest engineering win was treating the intel pipeline as one named queue with explicit stages. Search, scrape, translate, extract claims, score confidence, identify blind spots, render. Each stage has its own table row and each report is one of a small set of state-machine values. The whole thing runs through a self-chaining Edge Function that processes one report per invocation and triggers itself for the next, bypassing Supabase's worker limits without renting a separate worker box.

Once that structure was in place, every product change became a prompt change or a schema change, not a code change. Adding a new claim type took twenty minutes. Re-tuning the blind-spots prompt is a five-line diff in a single file. The pipeline architecture turned the product into a content problem instead of an engineering problem.

Treat the App Store as a release pipeline, not a launch event

Review took seven days the first time. It now takes about two. I learned to make every build a candidate. Every Friday a build goes up for review whether or not the next feature is ready, because rejection on a small change is recoverable in two days and rejection on a huge change is a two-week stall.

What I would do differently

Two things. I would build the marketing pipeline (the Sentinel Carousel project on this site) on day one instead of month six. The compounding cost of doing IG carousels by hand for five months was bigger than the cost of writing the pipeline. And I would say no to the social layer for another quarter. Comments, follows, and DMs ate three sprints and the audience that uses them is still small.

That is the playbook. Cut to five features. Pick constraints first. Build a stage-machine pipeline so the product is mostly prompts. Ship every Friday.