On June 11, 2026, AI Solve Quiz was a one-line idea: point your camera at a quiz question, get an answer that actually explains itself. On July 4 — twenty-three days later — it was live on the Chrome Web Store, the Apple App Store, and Google Play, localized into 21 store languages, with real payments flowing.
One engineer, working effectively solo. Five production surfaces: a browser extension, a marketing site, a customer portal, a backend API, and a Flutter mobile app. 140 commits. And almost every line of code written by AI agents running inside a system of plans, gates, and reviews.
This is an AI development case study with the receipts included — the timeline, the architecture, the process, and the parts that went wrong. We publish it because "we ship fast with AI" is an easy claim to make and a hard one to prove, and this is what our proof looks like.
The receipts
| Day | Date | What shipped |
|---|---|---|
| 1 | Jun 11 | Working prototype + a 949-line master plan + a full monorepo scaffold with 153 passing tests |
| 9 | Jun 19 | First real payment accepted (PayPal live); web, portal, and backend all in production |
| 10 | Jun 20 | Flutter app (23 screens) on TestFlight |
| 12 | Jun 22 | First Android build on Play internal track, store listing pushed via API |
| 21 | Jul 2 | Extension live on the Chrome Web Store |
| 23 | Jul 4 | Mobile v1.2.0 submitted to the App Store and live on Google Play — all three stores, 21 languages |
One honest footnote before anything else: of those 23 calendar days, only 13 had commits. The rest was store review queues and waiting. Call it roughly two working weeks of actual build time — which makes the number more interesting, not less.
Day 1: a cheap prototype killed an expensive mistake
The first day was not spent scaffolding the "real" codebase. It was spent on a throwaway browser extension — plain JavaScript, no build tools, bring-your-own API key — built to answer exactly one question: does the core loop work?
It almost didn't. The first version used OCR to read questions off the screen and a text-only model to answer them, and it failed immediately on anything with an image or a chart. So the pipeline was pivoted the same day: skip OCR entirely, send the cropped screenshot straight to a multimodal model. About 10 MB of OCR machinery was deleted before it ever touched the main codebase.
That decision — and the reason for it — was written into the plan's changelog and marked decided, do not re-litigate. That phrase matters more than it looks: when AI agents work on your codebase across many sessions, an unrecorded decision is a decision that will be silently reopened, re-debated, and sometimes reversed at 2 a.m. by an agent that wasn't in the room.
The lesson generalizes to any AI build: spend one day proving the risky assumption with the cheapest possible artifact. An architecture mistake caught in a throwaway prototype costs a day. The same mistake caught in week four costs the roadmap.
The system that let agents run for hours without drifting
The uncomfortable truth about AI coding agents is that raw capability is not the bottleneck — direction is. An agent that codes for six hours in the wrong direction is worse than useless. What kept this project on rails was a set of four documents, committed on day one, that acted as the agents' external memory:
- A master plan (949 lines): requirements, architecture diagrams, data model, pricing rules, security, milestones, risks — and a "decided stack, do not re-litigate" table that froze the framework choices up front.
- A machine-readable PRD: every milestone expressed as a story with acceptance criteria, each marked as either an automatic gate (verifiable by tests and builds) or a manual gate (needs real credentials — a payment sandbox, a live OAuth flow). This file was the project's state machine.
- An append-only progress log: what each milestone shipped, what was learned, and the full review trail.
- Per-milestone notepads: local working context for the executing agent, so the main plan never bloated.
On top of the documents sat three disciplines:
Every milestone verified itself. Typecheck, lint, build, and tests — with the database running in-memory and every external API mocked — had to pass before a milestone counted. The project ended its first day with 153 green tests across eleven milestones.
The agent that wrote code never approved it. A separate reviewer agent audited each milestone, and it had teeth — it rejected work on the first round more than once, forcing fixes before a second-round approval. A final cleanup pass hunted down leftover AI-generated cruft. If you run a single agent as its own reviewer, you have no reviewer.
Design happened before code, as HTML mockups committed to the repo. The mobile app's 23 screens, the extension's side panel, the portal — all existed as mockups first, and the agents implemented against them as the source of truth. Arguing with an agent about visual design in prose is a losing game; giving it a mockup ends the argument.
We wrote a beginner-friendly version of this workflow in vibe coding for beginners; this project is what the grown-up version looks like under production pressure.
One person, five surfaces: the architecture that made it possible
Five surfaces sounds like a team's worth of maintenance. The architecture is what made it a solo-sized job:
- A monorepo with one data contract. Every request and response shape lives in a single shared schema package; the backend validates against the exact schemas the clients use to call it. Change an API and the type-checker flags every affected app at once — across the extension, portal, and web — before anything runs.
- Static-first frontends. The marketing site and the customer portal both compile to static files served from a CDN's free tier. Exactly one server-side thing exists — a single backend API — so there is exactly one thing to keep alive.
- Independent deploys. Each app builds and ships on its own; a broken extension build cannot take down the website.
- Centralized, validated configuration. Every environment variable is declared in a schema and checked in CI against an example file, so a missing secret fails loudly at build time instead of silently in production.
The running cost for all of this — five production surfaces, database, email, monitoring, image storage — lands around $15–20 per month in fixed infrastructure, before usage-based AI API calls. Deliberate architecture is also a cost strategy.
Store releases as code, from day one
Publishing to three stores in 21 languages sounds like weeks of dashboard clicking. It was scripted instead:
- iOS shipped without opening Xcode. Building, signing, and uploading the app ran headless from scripts against Apple's App Store Connect API; store listings for all 21 locales lived as JSON files in git and were pushed by a script that only ever writes drafts — a human presses submit.
- Android used the same metadata-as-code approach, with release lanes for internal testing and production.
- Every screenshot for all three stores rendered from one HTML file — a self-made "screenshot studio" that headless Chrome turns into the full asset set: iPhone and iPad shots, Android phone and tablet, feature graphics, promo tiles. Rebranding the whole asset suite means editing one file.
The payoff is that store listings are diffable, reviewable, and rollbackable like any other code — and an AI agent can operate the entire release pipeline end to end.
What went wrong, kept honest
A case study that omits the failures is an ad. Three things bit hard:
Google indexed zero pages for weeks — because of trailing slashes. A static-site config mismatch meant every URL in the sitemap answered with a redirect, so all 577 of them were unindexable. The fix was two lines of build configuration. The lesson: submit-and-forget SEO does not exist; watch the index coverage report, not the sitemap submission receipt.
Apple rejected the app — twice, correctly. The listing said "Free" while the app sold credits without in-app purchase, violating two review guidelines. Fixing it properly meant integrating a whole IAP layer. Read the store guidelines before designing your pricing surface, not after the rejection email.
A perfect engine is not distribution. Our own July audit graded the project "engineering A, distribution F": flawless technical SEO, zero backlinks, zero reviews, zero social presence. Google barely bothered to crawl it. Shipping is a solved problem in this workflow; being found is a separate discipline with its own work.
What this means if you're scoping an AI build
The transferable asset here is not heroics — it is the process: prove the risk in a day, freeze decisions in writing, make every milestone verify itself, separate the builder from the reviewer, treat releases and store metadata as code. That process is exactly what we bring to client engagements, scaled to teams: it is why our AI agent development service starts with a short discovery sprint instead of a big contract, and why we put production gates in from week one.
And if you are currently comparing vendors, this article is the kind of evidence we suggest demanding from anyone — here is the 10-point checklist we'd score ourselves against.
FAQ
Was it really 23 days? Twenty-three calendar days from first commit to live on all three stores — June 11 to July 4, 2026. Only 13 of those days had commits; the gaps were mostly store review queues. We think the honest framing is "about two working weeks of build, three-plus weeks wall clock."
Did AI agents really write the code? Nearly all of it, via Claude Code running in an orchestrated loop: read the plan, build the milestone, verify the gates, log progress, repeat. Humans set direction, reviewed outputs, approved milestones, and handled the steps that need a person — store accounts, payment credentials, final submissions.
What did it cost to run? About $15–20/month in fixed infrastructure for all five surfaces, plus usage-based AI API calls and the developer-tool subscription. One-time store fees: Apple $99/year, Google Play $25, Chrome Web Store $5.
Does speed like this come at the cost of quality? The guardrails are the point: 153 automated tests from day one, milestone-level verification, and an adversarial review step where a separate agent rejected substandard work before it merged. Fast without gates is how you ship a demo; fast with gates is how you ship a product.
Can this process work for my product? The process transfers; the timeline depends on scope. A one-day feasibility prototype, written-down decisions, self-verifying milestones, and reviewer separation apply to any AI build — it is how we run client projects, starting with a discovery sprint rather than a leap of faith.
AI Solve Quiz is our own product — the same team and the same pipeline we put behind client work. If you want an AI build run with this level of discipline, talk to us about AI agent development.