Building Yearfold: From Idea to a Live Product in 30 Days

On May 2 it was a name in a document. By May 31 it was a live retirement planner running 10,000-path simulations. The honest case study of an AI-built product.

We spend most of these notes writing about other people's systems — Copilot estates, agent governance, the occasional lobster-themed security incident. This one is about our own. In May we took a product from a name in a markdown file to a live, revenue-wired, SEO-instrumented web application in thirty days, with an AI agent writing the overwhelming majority of the code. The product is Yearfold — a free retirement calculator that runs 10,000-path Monte Carlo simulations on current Social Security, Medicare, and tax data, and models couples and dependents properly instead of pretending every household is one person.

This post is the case study we wish more people published: what the thirty days actually looked like, the method that made an AI agent safe to hand a whole product to, the two or three things that went sideways, and what we would tell anyone — founder or enterprise team — who wants to compress a quarter into a month. It is also, frankly, the receipts behind a claim we make to clients every week: AI-assisted delivery works when it is governed, and the governance is the interesting part.

Yearfold — idea to production in 30 days

Day zero: a name and a contract with the machine

The idea had been circling for a while — retirement math is genuinely hard, the free tools are either toys or lead-capture funnels for advisors, and the good simulators live behind subscriptions. The commitment happened on May 2, when the name landed: Yearfold. Fold your years forward. Domain registered, repo created, and then the single most important hour of the month: writing the spec.

Not a backlog. Not a Figma file. One document — a CLAUDE.md at the repo root — that reads like an engineering constitution: the product in one paragraph, explicit non-goals (no portfolio tracker, no robo-advisor, no chatbot), a locked stack table, the repository layout, the design tokens, the Monte Carlo engine's public API with TypeScript interfaces, the database schema with row-level security policies, compliance rules for financial content, and a do/don't list for the AI agent itself. Every working session for the next thirty days started with the agent reading that file.

If you read our later note on the Defender experiment, you know where this is going: the spec is the product. An AI agent with a vague brief produces a demo. An AI agent with a constitution produces a system. We wrote the constitution first and spent the rest of the month enforcing it.

What thirty days actually contained

The May build timeline

Week one was the engine, because the engine is the product. A retirement calculator that hand-waves the math is a marketing page. Yearfold's core is a Monte Carlo simulator: 10,000 paths, monthly steps, returns bootstrapped from nearly a century of market data with inflation sampled from the same months so the two stay correlated, Social Security benefit math with real bend points, Medicare premiums, required minimum distributions, the works. Two engineering rules made it trustworthy. First, the engine is pure — no framework imports, no browser dependencies — so it runs identically in a test harness and in the browser. Second, it is deterministic: a seeded random number generator means the same inputs produce byte-identical outputs, which turns "the simulation looks wrong" from a debate into a failing test. We set a performance budget in the spec — 10,000 paths in under 800 milliseconds on ordinary hardware — and the shipped engine ran around 523. The whole thing executes in a Web Worker so the interface never stutters while ten thousand futures compute.

Week two was the human half: the input wizard and the results view. A five-minute flow — you, your spouse if you have one, balances, contributions, the retirement you want — feeding a results dashboard built around a fan chart of outcomes: the median path, the lucky tenth percentile, the unlucky one, and the headline number, your probability of the money lasting. Under it, the feature we care most about: shortfall fixes. If your plan lands at 61%, the tool computes what specifically moves it — contribute this much more, retire this many months later, claim Social Security at this age instead — each with its resulting probability. Prescriptive, not just descriptive. Calculator inputs live in the URL, so a plan is shareable and bookmarkable by design.

Week three wired the business: accounts, saved plans, email, and the first revenue path — a one-time PDF export of your full plan via Stripe Checkout. This was also the week of our favorite war story, which we will get to.

Week four was the part most one-month builds skip: content and compliance. A methodology page that explains the simulation in plain English and links primary sources — SSA, IRS, CMS, the Shiller data — because a financial tool that will not show its work does not deserve trust. A blog, sixty programmatic scenario pages ("retire at 55 with $500k"), profession guides, sitemaps, structured data. Legal pages. And our favorite artifact of the whole project: the compliance disclaimer is enforced by a unit test — a static scan that fails the build if any calculator or results page ships without the required financial-education disclaimer. Compliance as code, because policy that depends on memory decays.

By May 31 the launch checklist was done, roughly seven hundred automated tests were green, and yearfold.com was live and taking traffic.

The method: why the speed did not produce a mess

The honest answer to "how does one month produce all that" is: the AI wrote most of the lines, and a set of unglamorous guardrails made that safe. Four of them did the heavy lifting.

One document ruled everything. The CLAUDE.md constitution meant the agent never improvised architecture. When a task conflicted with the spec, the standing instruction was to stop and ask, not to silently override. Most drift in AI-generated codebases is not bad code — it is undocumented decisions. We made decisions a written artifact, and the changelog at the bottom of that file grew into a complete build diary: every dependency added, every convention changed, dated and justified.

Every merge passed one gate. A single command — typecheck, lint, full test suite — had to pass before anything landed, with the engine benchmark run on changes that touched the math. No green, no merge, no exceptions, including for the human. It is the same discipline we preach for enterprise AI adoption: the model can write the code, but the definition of done belongs to you.

Tests were written where lying is expensive. Not coverage theater — targeted paranoia. The Social Security math is checked against the government's own worked examples. Property tests assert that success probability always lands between 0 and 1 and percentiles never cross, for any valid input. A snapshot test pins the seeded engine byte-for-byte. And the disclaimer scan makes an entire compliance class unshippable-wrong.

Boring infrastructure bought the month. Hosted Postgres with row-level security instead of self-managed anything. A transactional email service instead of SMTP archaeology. Push-to-deploy hosting with preview builds per pull request. MDX files in git instead of a CMS. Zero Docker, zero Kubernetes, zero infrastructure meetings. Every one of those choices was the least interesting available option, which is precisely why the interesting work fit in thirty days.

The stack, chosen for speed without regret

What went sideways, on the record

A case study without failures is an ad. Three things bit us.

Email scanners ate our sign-in links. The original auth flow used magic links — click the email, you are in. It worked everywhere except the real world, where corporate email security (Outlook Safe Links, Gmail scanning, Mimecast) pre-fetches every URL in every message to check it for malware. The scanner's fetch consumed the one-time link before the human ever clicked, producing "link expired" errors for precisely the professional users we wanted. The fix was to stop sending clickable links entirely: sign-in became a typed six-digit code, boring and scanner-proof. File that one away — any emailed one-time URL in 2026 must assume a robot clicks it first.

The engine had to be protected from the product. Twice during the month, feature work tried to reach into the simulation — a UI convenience here, a display shortcut there. The spec's rule ("the engine must run in a plain script with no browser") rejected both, and both times the feature found a cleaner shape. Purity rules feel pedantic until they save you; the same engine now powers the web app, the PDF renderer, the test suite, and later features we had not imagined in May, precisely because nothing welded it to a screen.

We underestimated content volume as engineering. Sixty scenario pages, a long methodology document, and a blog are not "marketing to sprinkle on later" — they are build artifacts with their own registries, validation, and tests. Week four was as dense as week one. If your launch plan says "then we write some pages," triple that line.

What happened after May

The thirty days were the start, not the story's end. June and July added a Pro subscription — monthly plan re-runs with narrated changes, a tax deadline calendar, an AI copilot that answers questions about your own plan by calling the real engine (every numeric claim must come from a tool call — a rule we recommend for any customer-facing AI), dynamic spending guardrails, and a Couples tier for household planning. The test count is past eight hundred and fifty. All of it sits on the May foundations: the pure engine, the one-document spec, the merge gate. Compounding is the whole argument.

What this means if you are not building a retirement calculator

We did this partly because Yearfold deserved to exist and partly as a controlled experiment on our own methodology. The transferable findings, stated plainly:

A month is the new quarter — for a well-specified product, with one senior person steering an AI agent full-time, idea-to-production in thirty days is now a realistic planning number, not a hackathon fantasy. The constraint has moved decisively from typing speed to decision speed: the agent was never the bottleneck; choosing correctly was. Guardrails are what make the speed compoundable — the check gate, the deterministic tests, the compliance scan are why week four could build confidently on week one instead of excavating it. And judgment did not compress at all: what to build, what to refuse to build, what the disclaimer must say, when "done" is true — the month was fast because those calls were made quickly, by a human, and written down.

That last paragraph is, not coincidentally, a description of our services. The same operating model — spec-first, AI-assisted, gate-everything — is what we bring to client engagements, whether the deliverable is an internal tool, a data pipeline, or a product like this one.

Go run your own numbers at yearfold.com — it is free, it takes about five minutes, and the methodology page will show you exactly how the sausage is simulated.

If you're facing this

If you have a product idea sitting in a document — or a backlog your team swears needs two quarters — we now have a very specific answer to "what could AI-assisted delivery actually do for us," and it is live at yearfold.com. We help teams set up the same machinery: the spec, the guardrails, the gates, and the month. Tell us what you want to build; we reply within one business day.

// related notes
// still relevant?

Facing a migration, platform, or AI build like this one?

If you are shipping something adjacent — RAG, agents, evals, Azure platform — send a brief. We reply within one business day with an honest read on fit.

Start a project →

← Back to notes