What shipping a mobile platform in eight weeks taught us
Earlier this year we shipped a production mobile platform for a community organization: iOS, Android, and a web admin console with live AI services, taken from a lightweight requirements document and a throwaway proof-of-concept to app-store builds in eight weeks. One engineer, a small budget, a client whose own staff had to run the thing afterwards.
People ask how. The honest answer is that the product was the second thing we built. The first was the system that built the product.
Build the production line before the product
The temptation with a tight deadline is to start coding on day one. We did the opposite. The first stretch went into turning the requirements document into a full planning corpus: a product requirements document, a functional specification, a data model, a service contract, and a set of architecture decision records. Then the scope was decomposed into stories with acceptance criteria and arranged into a dependency-ordered build plan.
That sounds like ceremony. It was the opposite. Every story that followed was small, unambiguous, and already knew what done looked like. An AI-assisted workflow can move very fast through work like that. It moves very slowly, and very expensively, through work that is vague.
Let the harness enforce quality
With the plan in place, every story went through the same production line: branch, build, test, review, pull request. The tooling was purpose-built for this codebase, with its own commands, skills, and architecture rules, so the assistant was not guessing at conventions. It was following them.
The part we would repeat on every engagement is this: quality was enforced by the harness, not by hope. Strict types. Automated tests written alongside every story. Per-story acceptance verification before anything merged. By the end there were more than a thousand automated tests, not because anyone set a target, but because the process produced them as a side effect of shipping.
When people picture AI-assisted development, they often picture speed with less rigor. What we saw was speed because of rigor. The guardrails were what made it safe to go fast.
Design for the day you leave
The client was never going to have an engineering team. That constraint shaped the architecture more than any feature did.
The apps talk to a typed service adapter, never to the backend directly, so the stack can be swapped without rewriting the apps. Content lives in the CMS, so the organization updates the app without an engineer. Delivery went into the client's own repository with tagged milestones and a decision log they can read. And we wrote operator documentation for their team rather than for ours: setup, deployment, and a functional and technical reference for each part of the system.
None of that was in the requirements document. All of it is why the platform is still theirs.
What we would tell a team about to do this
Three things.
First, the plan is the accelerator. If your AI tooling seems slow, look at the inputs. Ambiguous stories produce ambiguous code, and then you spend the saved time in review.
Second, treat tests as the product's evidence, not its overhead. A system with a thousand tests is not slower to change. It is the only kind of system you can change quickly with confidence, whether a person or an agent is doing the changing.
Third, decide who owns the system after you, and design for them from the first commit. Handoff is not a phase at the end. It is a constraint on everything before it.
Eight weeks is a headline. The delivery system underneath it is the part that transfers to the next engagement, and the next. Detailed case studies are available on request.