Field notes · 01

From idea to production with AI in the loop

Sixty-three days from the first business-plan commit to production messages firing on a real event. One person. Here is the stage map, and where judgment had to gate each transition.

2026 · 13 min read

Last northern spring I took a product from a positioning hunch to a production platform running live events: SplitKit, a race-day experience layer for endurance-event timers. The business plan's first commit is dated April 26. On June 28, it fired its first production finish-line messages during a real customer's event. Between those dates sit a market analysis, a business plan, four sets of product requirements, an architecture, ten repositories of working code, and the operational tooling to run it all, built by one person, no team, with AI agents doing most of the typing.

That last clause is the least interesting part. Agents made the volume possible; they did not decide what to build, what not to build, or when something was safe to ship. The useful story is the sequence: five stages, each ending in a gate. The sequence is the part you can take with you.

1.0Position before product

The first repository wasn't code. For five days there was only a business plan.1

And the first decision in it wasn't a feature. It was what type of business to build. One person, no funding, no team: that constraint has to be chosen deliberately, because it decides everything after it. A venture-shaped plan wants growth infrastructure, headcount, and burn. A one-person business wants near-zero idle cost, a knowable market, and operations that fit inside one attention span. Settling that before any market analysis is what made the rest of the plan coherent instead of aspirational.

The plan grew to forty-eight numbered documents (business overview and go-to-market, a revenue model, the technical architecture, privacy policy and terms of service, finance operations, a race-day playbook) plus the research dossiers: competitor deep-dives, market shape, personas and channels, a tiered analysis of the small, fully enumerable set of companies that could ever become customers. Alongside the words came the visual foundation: brand identity and per-surface design guides, drafted with the same AI tooling, so every later agent session inherits one visual language instead of reinventing it.

The dossiers were agent-drafted in days, work that once took a strategy consultant a quarter. But the calls that shaped everything downstream came from more than a decade inside this industry, and they were mostly narrowing calls. A market of a hundred-odd knowable buyers means distribution is a phone list, not a funnel. A vendor ecosystem you complement rather than compete with means integration depth is the moat. None of that is in the training data. All of it is in the plan.

The narrowing came from RaceResults360, the endurance-events platform I co-founded in 2012 and wound up cleanly this year: a decade of race weekends spent close enough to timers to know what they will pay for, what they refuse to configure twice, and whose relationships they guard.

Decision record · Fig. 1
The default path
Asked to plan a product in this space, an agent proposes breadth: a feature-rich platform for race directors, timers, and participants alike, with a marketing funnel to match. Plausible, ambitious, and unbuildable by one person.
What I directed instead
A single wedge: complement the timing platform incumbents already use, sell the experience layer timers can offer their race directors, and accept a deliberately small, fully enumerable market.
What it bought
Every downstream decision got simpler. Distribution became a list of names. The integration surface became one vendor done deeply instead of five done thinly. And the plan became something one person could actually execute.

2.0Specs as agent context, not paperwork

On May 1, four product repositories were scaffolded, one per portal, and each got its own PRD set: fourteen documents for the timer portal, sixteen for the participant app, sixteen for the API, eleven for the admin surface.

Written for a human team, that would be process theatre at this scale. But these PRDs have a different job: they are the context an agent session loads before touching that portal. A session in the timer repo reads the timer PRDs and nothing else. Small context, consistent answers, and no possibility of the participant app's assumptions leaking into the timer's. They are also living documents; all four sets were edited again this month. When the spec is the agent's working memory, letting it rot is letting the next hundred sessions rot.

3.0Doctrine before code

The architecture principles were written and locked the same day the repos were scaffolded: eight of them, before any application code existed. The one that did the most work is a cost gate phrased as a question: what does this cost when no races are running? The answer had to be near zero. Races are spiky; the platform is idle most days of the year, and a stack that bills while idle is a stack that eventually forces revenue decisions for infrastructure reasons.

That question ruled out the default serverless kit entirely,2 and it produced the platform's most consequential design: a single scheduled worker polls the timing vendor once a minute, does all ranking, sorting, and age-grading, and writes flat JSON files to a CDN. Participants poll a static file. Read scale is decoupled from the vendor's rate limit by construction, not by a throttle bolted on after the first big race melts.

Decision record · Fig. 2
The default path
The standard cloud-native answer: managed API gateway, functions, queues, and an event bus. It works, it scales, and it idles expensively across four portals, with the vendor's one-request-per-second limit handled by retry logic on the hot path.
What I directed instead
Serverless-rendered frontends on one platform; a residual cloud footprint of storage, CDN, and a key-value table; all live-timing reads served from preprocessed static JSON. Always-on compute excluded from the stack by written principle, not preference.
What it bought
Idle cost near zero, so the platform can wait for its market without burning. Read scale independent of the upstream vendor entirely. And an architecture simple enough for one person to hold in their head, which is itself a reliability feature.

The cost gate is one principle of eight, and the eight are one chapter of a larger rulebook that spans UX copy, data handling, pricing integrity, and the business itself. That rulebook, and how it keeps a fleet of agent sessions pointed the same direction, earns its own entry. The point here is the timing: the doctrine existed before the code did.

4.0Build fast where it's cheap to be wrong

With the plan, the specs, and the doctrine in place, the build moved at agent speed: payments wired end-to-end by day seventeen of the project, observability and a knowledge architecture by day twenty-two, the SMS path verified live in production by day thirty. This is where AI genuinely compresses the calendar. Weeks of implementation typing became days.

The buy-versus-build instinct applied to expertise, too. Where packaged skills already existed (video production, observability wired through a marketplace integration rather than hand-rolled) they got used, and the building effort went to the parts no one else could supply: the domain logic and the rules.

The discipline was keeping the speed inside guardrails. Every repo carries written rules that encode hard-won judgment, each one traceable to a specific incident, and by mid-June every pull request in every repository was being reviewed by an adversarial agent before merge: automatically, with the review posted to the PR and a ledger the committer must read. A month in, deep adversarial audits swept the two riskiest repos and turned up ninety-three findings; every critical one was remediated the same window, before launch rather than after. Those systems each earn their own write-up. Here, the point is their position in the sequence: the velocity and the gates arrived together, not gates-later.

5.0Operate like you'll be asleep

The stage most solo builds skip is the one that started earliest here: production wasn't considered shipped until it could be watched, and watched by something with judgment, because one person cannot stare at dashboards on race morning while also being the support desk.

Deploy verification became a one-command smoke test. Monitoring went in with uptime checks, cron heartbeats, and durable logs. And on July 1, a read-only ops agent went live on always-on hardware: every sixty seconds it reads the same telemetry a human operator would and reasons about whether the race is actually performing, escalating only when an issue is current, material, and corroborated by more than one signal. Its reasoning agenda fits in a single operating manual; its IAM permissions are read-only by design, so the only thing it can ever do to production is understand it.

The first real test came three days before that agent shipped. On June 28, during the first production live-fire on a real customer's event, an optional blank date field in the vendor platform surfaced an assumption the code should never have made. The fix shipped the same day, and so did a doctrine now written at the top of the workspace: we adapt to the vendor's reality, never the reverse. Incidents become rules; rules steer every future agent session. That loop is the operational rigour.

Decision record · Fig. 3
The default path
Ship, stand up dashboards and threshold alerts, and let the founder be the pager. Standard for a solo build, and it caps the whole system at the founder's attention span.
What I directed instead
Operational rigour as a build artefact: scripted deploy verification, automated adversarial review on every merge, and a reasoning agent watching production with read-only credentials and a strict no-false-alarms escalation rule.
What it bought
A one-person platform that runs live events without a war room. The human gets pulled in on judgment calls, not on noise, and every incident that does occur gets converted into a rule the next hundred agent sessions inherit.

6.0If you're doing this yourself

The stage map, with the gate question that ends each stage:

  1. Position before product. Decide what type of business you're building, then let agents draft the research while you make the narrowing calls; they are the ones that require having been in the room. Gate: can you name your buyers and your distribution channel without the word "funnel"?
  2. Write specs as agent context. One living PRD set per product surface, sized so a session loads only what it needs. Gate: could a fresh session answer "what should this do?" from the documents alone?
  3. Lock doctrine before code. Principles that can veto a stack, written down, with the cost-at-zero question near the top. Gate: what does this cost when nothing is happening?
  4. Build fast inside gates. Velocity from the agent; correctness from written rules and adversarial review. Gate: can anything reach production unreviewed?
  5. Operate for judgment, not just metrics. Instrument the system, then put something with reasoning (human or agent) between the telemetry and the pager. Gate: when something odd happens at 6 a.m., what reasons about it first?

Nothing in the sixty-three days skipped a stage; the stages just stopped taking months. The typing compressed. The sequence, and the vetoes, were still the job.

∎

Entry 01 · Written after the platform's first production season