Haunts.IO, Six Months Later: The Other 20%

In my experience, vibe-coding a prototype gets you roughly 80% of what you need in days, or even hours with a well-structured prompt. The other 20% can take months: testing, guardrails, monitoring, cost control, privacy enforcement, and the structured workflow that lets AI keep building at full speed without breaking what already shipped. AI is the builder, but a lazy one prone to shortcuts and a wandering mind. The person driving it is the architect, and the architect's real output is the machinery around the code.

From Check-Ins to Stories

"Check-ins are the breadcrumbs that become stories" has been the Haunts tagline from the start. Six months of work have turned that line from an intent into a description of the actual product. Check-ins captured on a road trip become map-matched routes. Routes become rendered trip videos with music and cold-open titles. Days become journals written by AI against the evidence of where you went, and trips become printable posters and share cards you can hand to someone.

A user on r/hauntsio described what that feels like from the other side, and their own words carry it better than any summary could:

A real afternoon from a favorite trip, lost for two years, returned by a story written from their own check-ins. Twelve years of those afternoons are waiting behind it, and the stories can return them one at a time. The breadcrumbs were already there. They needed a system to surface them as stories.

The Other 20%

Here is what the months of work went into.

Testing

The prototype had close to no tests at the start, now the platform has 9,653 automated test cases. In the backend, 43% of all PHP is test code. In the Go media server, the ratio is higher: 54% of the source is tests. Among them are 136 named regression guard tests, each one pinning a specific class of bug that was found and fixed, so it cannot return quietly.

The test infrastructure itself went through a maturity step. Unit tests with mocked databases carried the project for months, and then stopped being enough, so August brought a seeded suite that runs against a real local MySQL with per-branch schemas. Mocks test against what you assume the database will do. The seeded suite runs the same logic against a real MySQL instance and catches what the assumption missed.

Guardrails

Every guardrail here is enforced automatically, in code. A commit is blocked unless a code review has passed. A commit message starting with fix: is blocked unless a formal bug hunt has completed first, which requires three written hypotheses and a failing test that reproduces the bug before any fix is written. There are 104 of those hunts on file. A pre-push hook runs the typecheck before any version bump leaves the machine, because a red build wastes a 25-minute release cycle. A deploy guard refuses to ship from any checkout that is stale, dirty, or diverged from what production carries.

Every one of those gates exists because AI writes code fast enough to outrun human review. The gates make that speed safe to use without slowing it down.

I've often spoken to others about the velocity of AI development and the challenges it puts on our human brains. It's not possible for us to keep up with this kind of development pace without taking the time to understand what it's doing. And, even then, when we are switching from one project to another, there is that lag of realigning our thoughts. I can't emphasize enough how important a structured workflow is to try to keep up, and not burn out.

The Architect's Job

Building with AI at this pace is a dispatching problem. Planning happens in the strongest reasoning model available. Implementation runs in a faster, cheaper one. Final review goes to a different model from a different vendor, on the theory that a reviewer should not share the author's blind spots. Around that routine sit 40 custom skills and 54 automated hooks covering everything from simulator QA journeys to deploy checklists.

My typical workflow might look like this: Brainstorm with Claude Fable, Ultraplan, Codex adversarial reviews, reiterate until it goes to Implementation Planning, codex reviews. On to implementation using a lower cost module like Sonnet. And then on to code reviews with Codex and Fable before sim qa tests.

The clearest measure of where the effort goes is a repository that contains no code at all. It holds the architecture contracts between the five repos and an append-only status log for each surface, and in its first 27 days it accumulated 292 commits, more than any other satellite repository in the system. Multiple AI sessions work concurrently across the codebase, and the only reason that works is that writing down what happened is treated as part of the work itself.

Privacy and Cost Controls

Privacy and cost both hardened into invariants over the summer. In early July, a full-codebase audit program swept the platform in five waves and found seven privacy leaks and two data-loss bugs. All were fixed before any user was affected, the default visibility for new content was moved from public to friends, and a privacy probe now runs against production after every deploy.

Cost got the same treatment. A commercial product cannot run on someone else's free tier, so every external vendor now has a quota bucket, spend rolls up daily, and an advisor job files a month-end report on where the API dollars went. Billing itself is wired end to end, webhooks, reconciliation jobs and all, and sits dormant behind a flag until the moment is right to start charging.

Lessons From the Incident Log

Three incidents from the log show where the machinery above came from.

For five days in August, edge delivery of media was silently disabled. Nothing threw an error and no user saw a symptom, since the system fell back to the origin, and every documented post-deploy check passed the entire time, because all of them pass with edge delivery fully off. The fix re-enabled edge delivery and added a new alert for the condition the existing checks were structurally unable to see.

On August 19, a deploy from a stale working copy silently reverted the live admin interface to an older version. That failure produced the deploy guard, which now refuses any deploy that is not clean, current, and identical to what the repository says production should be.

And the feed query behind the app's busiest screen was taken from 275 milliseconds to about 1.5 milliseconds through covering indexes and buffer pool tuning, the kind of work a five-day prototype has no reason to do. Even now, benchmarking is a daily review of data to identify opportunities for performance boosts.

The Bottom Line

The five-day prototype was real, and the case study that described it holds up. What six months of production hardening adds is the part of the argument that matters to anyone deciding whether to build this way: the 80% comes fast on the same models everyone has, and the 20% is a long stretch of testing, guardrails, and operations where an experienced architect earns the title. Haunts became a commercial product because that machinery got built.

Today the app runs across six surfaces, carries half a million lines of code, and holds up under strangers using it in ways no demo ever predicted. If you want the same arc for your product, tell us what you need built and we will tell you what it takes.