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

In my experience, vibe-coding a prototype gets you a working demo in days, or even hours with a well-structured prompt. It covers enough of what you personally need to feel close to done, and it is about a fifth of the total work. Going from something that runs for me to something strangers can use took six months and four times the code: testing, guardrails, monitoring, cost control, privacy enforcement, a multi-user rewrite, 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.

A check-in, start to finish

01Nearby

02Check in

03Confirmed

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 Other 80% - The Real Work

Testing

The prototype had close to no tests at the start. The platform now has more than 14,000 automated test cases, and about two thousand of them were written in the first two weeks of September alone. In the backend, 46% of all PHP is test code. In the Go media server the tests outweigh the source, 25,900 lines against 22,100. Among them are more than 150 named regression guard tests, each one pinning a specific class of bug that was found and fixed, so it cannot return quietly.

Unit tests with mocked databases carried the project for months, then stopped being enough. August brought a seeded suite that runs against a real local MySQL with per-branch schemas. The seeded suite runs the same logic against a real MySQL instance, so it catches the cases a mocked database only assumed and never ran.

An independent maintainability review, run read-only and cross-checked by a second AI vendor, scored the mobile codebase 90 out of 100, an A. That score measures how the code is built to change, which is the first thing a fast build is supposed to cost you.

Guardrails

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 109 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 dirty or has drifted from what production carries.

Every one of those gates exists because AI writes code fast enough to outrun human review.

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

Planning goes to the strongest reasoning model available, and implementation to something faster and cheaper. Final review goes to a different model from a different vendor, because a reviewer shouldn't share the author's blind spots. I've built 58 custom skills and slash commands and 55 automated hooks around that routine, covering everything from simulator QA journeys to deploy checklists.

Here's that routine end to end.

A repository that contains no code at all holds the architecture contracts between the five repos and an append-only status log for each surface, and in its first six weeks it accumulated 582 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

A full-codebase audit in early July surfaced real problems, all fixed before any user was affected, the default visibility for new content moved from public to friends, and a privacy probe now runs against production after every deploy. Privacy turned into a hard rule that summer.

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, because a commercial product cannot run on someone else's free tier. 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.

Testing the App the Way a User Does

The camera bug that shipped in 3.2.0 lived in the gap between passing tests and a tap that actually lands: unit tests prove that functions return the right values, but they don't prove the check-in sheet opened or that a photo made it through the filters. So the last gate before a build goes to the app stores is an AI agent driving the real app in the iOS Simulator, the way a user would.

Six Journeys in the Simulator

The Sim QA skill builds a release version of the app, boots an iPhone 17 Pro simulator, installs it, and runs six journeys in order.

1. Cold launch. Open the app and land on the signed-in tab bar, not the sign-in screen.
2. The core loop. Nearby fills with places, a check-in gets written and posted, the confirmation screen appears.
3. Movement. The simulator streams a fake drive at about 40 miles an hour through three points in downtown Washington, and the map has to follow once you've moved more than a hundred meters.
4. Photos and filters, through the photo library. The simulator has no camera, the surface where the 3.2.0 bug hid.
5. Deep links. One from the app's own link scheme and one public web link, both have to open the right screen.
6. The map and the globe. A missing map token shows up here as a blank basemap.

Every tap that changes something is followed by a screenshot or a read of the accessibility tree, and the rule in the skill file is blunt: an assertion counts only what the pixels show. A failed journey gets logged as a finding, and the run keeps going. The app under test talks to production with a real test account, so the agent never types a password, every QA check-in is private, and all of them go to the trash when the run ends. A run on September 13 counted exactly 34 selectable photos in the postcard picker by reading the accessibility tree. A screenshot can't count.

The first touch driver we used reported success on every tap while the tap never reached the app. We caught that on August 29 and swapped it out. After any journey with a pop-up sheet, the agent now scans the device log for sheets that failed to appear, because a screenshot can't show a thing that never showed up. And the bottom of the file lists what the simulator can't do and stays on a physical phone: real camera capture, background GPS on an actual drive, the widget gallery, the Watch and CarPlay companions, and push notifications.

Audits in Waves

The July security program in the next section was the first audit we ran as a project instead of a checklist, and the habit stuck. On August 14 the mobile app got the same treatment: twelve auditors reading in parallel, each checking every file for five things (bugs, security, architecture, dead code, and missing tests), about 715 file passes in all, with every API call checked against the 163 endpoints the backend serves. The result was zero critical, zero high, 25 medium, and about ninety low. A second audit in September found eight verified issues, and fixing them is the idea that went through the board in three hours above.

One agent drives the simulator and takes screenshots. A second agent looks at each screenshot against a short written description of what the screen is supposed to look like and returns approve or revise, with findings ranked from blocker down to low. A third makes the smallest fix for the blockers and highs, runs the typecheck, and hands the screen back to the first agent. The loop is capped so polish never holds a build forever. This covers the part of the app the 14,000+ tests can't reach.

The Hard Parts

When Sessions Collide

For several days in August we had enough Claude and Codex sessions running at once, across separate worktrees, that they started colliding. Two subagents committed against the same git index. Work from one session was swept into another session's commit. Branches drifted far enough apart that pulling them back together meant rebasing sessions against each other before any of it could merge. On August 19 a deploy from a stale working copy silently reverted the live admin interface to an older version, and nothing about the page looked wrong afterward.

Getting out of that cost a day of careful rebasing. Every session now takes a lease on its own worktree. A reaper reclaims abandoned checkouts and refuses to delete one without positive evidence that the session ended, on the principle that visible toil is a better failure than a deleted session. A deploy guard refuses to ship from any checkout that does not match what the repository says production carries, with an override that has to be typed out in full and only for hotfixes.

One person running AI at this speed produces the parallel work of a team and inherits its coordination problems along with it. A small headcount only buys you time before you need the same workflow.

Failures That Pass Every Check

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.

A schema completeness check on the GDPR export passed across three migrations while two columns were quietly missing from the export, because the fixture it compared against had gone stale alongside the code. Two stale things matching is not a pass, and a green suite is only worth what its assertions reach.

Security Became a Program

In early July we stopped treating security as something to check before a release and ran it as its own project. Five audit waves swept the full codebase over three days and turned up seven privacy leaks and two data-loss bugs, all fixed before any user was affected, with a written remediation plan and a retrospective kept in the repository. What came out of it is not a checklist. Request handling gained bounded body reads and typed field validators, rate limiting now runs through more than ninety files, remote image fetches reject private address ranges and redirects outright, the database users were cut down to least privilege, and a privacy probe runs against production after every deploy.

Performance Stopped Being Free

The feed query behind the app's busiest screen ran 275 milliseconds against real data volumes, and covering indexes plus buffer pool tuning brought it to roughly 1.5. A prototype serving one person never has to notice. Benchmarking is now a daily read of the numbers.

Keeping Track of All of It

The volume of feedback, half-formed features, and known problems outgrew notes and memory somewhere around midsummer. The My Day board described above came out of that pressure, and so did the cross-repo status log. Before the board, an idea lived wherever it was last mentioned, and the plan for it lived in whichever session happened to write one. Neither is glamorous work, and without them priority drifts to whatever came up last.

The Bottom Line

The five-day prototype was a real app, and the original case study captured how fast that kind of build can come together. What six months of production hardening adds is the part of the argument that matters to anyone deciding whether to build this way: the demo comes fast on the same models everyone has, and the other 80% 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 more than 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.