AutoBrief V1, in one night
Started the evening with a working title and no domain. Ended it with eleven routes, a deterministic rules engine, an AI brief generator, full roster CRUD, an audit trail, and twenty-nine passing tests. The leverage isn't AI — it's the founder being inside the work.
AutoBrief went from a renamed working title to a feature-complete V1 front-end in one sitting. Not a marketing page with a waitlist. The actual product surface — pilot roster, aircraft fleet, the pre-flight check, the AI brief, the audit log, the chief-pilot override flow.
The temptation is to attribute this to AI tooling. That's not the right read. The real leverage is more boring and more durable.
The fastest way to build software for a job is to be the person who does the job.
Why one night was enough
A normal startup needs six weeks of user research to figure out what a pre-flight check screen should look like. Which fields matter. What dispatchers care about. What edge cases the rules engine has to handle. What language to use in the brief so the customer doesn't have to translate jargon to plain English.
For AutoBrief that research never happened, because the spec was already in my head. I am the customer. I know what a current medical looks like, what 14 CFR 61.57(c) asks for, what a grounding squawk does to a flight schedule, what a chief pilot needs to see before signing an override. I have run those checks by hand at actual schools. The product is just the externalization of a mental model I already carry.
What got built
The deterministic rules engine encodes 14 CFR Part 61.23 (medical), 61.56 (flight review), 61.57(c) (IFR currency), 91.409(a) and (b) (annual + 100-hour), and 61.31 (endorsements). Pure functions, ~250 lines, twenty-nine unit tests. Same inputs always produce the same output — there is no model in the loop for the legal call.
On top of that, the AI brief: a separate layer that takes the engine's structured verdict and translates it into the two-or-three sentence plain-English paragraph a dispatcher actually reads. Claude Sonnet 4.6 with prompt caching on a fixed system prompt that includes five worked examples. Falls back to a rule-based summarizer if the API key is missing. The model never makes the legal call. It writes the brief.
And the surface: pilot roster (add, edit, remove with full medical+BFR+IFR+ endorsement fields), aircraft fleet (add, edit, remove + per-aircraft squawk management with severity tiers), the interactive check screen, the override flow with typed signature, and the audit-trail history page that captures every decision plus override.
What this proves
Not that AI builds products. AI typed the code. But AI didn't know that dispatchers don't need definitions of "BasicMed", or that 100-hour look-ahead math matters more than just the elapsed-hours check, or that the difference between MEL and grounding severity is a real operational distinction worth two different reason colors. I knew that. The AI took dictation.
The honest summary is something like: when the spec lives in the founder's head and the engineering capacity is the founder's hands, the cycle time on a software product compresses by about an order of magnitude. The AI shaves another factor off the typing. The result is a night that looks impossible from the outside and looks normal from inside.
What's next
The prototype runs on localStorage. To turn it into a real flight school's dispatch board, the next session wires Supabase: the auth schema, the pilots and aircraft tables with row-level security, the checks audit log, the override log, the SECURITY DEFINER RPCs for safe writes. The migrations are written. The Supabase project gets created tomorrow morning.
After that: the Stripe Starter tier, the cold-email batch to the FAA Part 141 list, and the first paying customer's onboarding. The six-week ship plan turned into a one-night front-end and a several-evenings backend. We'll see whose name lands on the first invoice.