1. Discovery — typically week one
We map what you are building, who it is for, and what success actually looks like in numbers rather than adjectives. The output is a written scope document listing every screen and every feature, with anything explicitly excluded written down as excluded. Most disputes later in a project trace back to something both sides assumed was included, so we put the boundary in writing while it is still cheap to discuss.
You approve: the scope document, the timeline, and the fixed price. Nothing is built before this is signed.
2. Architecture and design — weeks one to three
Before any production code exists, you see the actual screens and the data model behind them. This is where the expensive decisions get made: how your data is structured, which parts need to be custom-built versus integrated, and where the system needs room to change later. Getting this wrong is what makes products impossible to extend in year two, so we spend real time here rather than rushing to visible progress.
You approve: the interface designs and the technical approach.
3. Build — the bulk of the timeline
Development runs in weekly cycles, and at the end of each one you get a link to a live staging environment you can open on your own phone. Not a screenshot, not a progress percentage — running software you can use. This is the single most important part of how we work, because it means a misunderstanding surfaces in week two while it costs an afternoon to fix, instead of at handover when it costs a rebuild.
You get, every week: a working build, and a short written note on what changed and what is next.
4. Testing and hardening — before launch
Real devices, real edge cases, real load. We test what happens when the network drops mid-transaction, when a user enters something unexpected, and when a third-party service you depend on is slow or down. Security review and performance work happen here too, not as an afterthought once users are already on the system.
You approve: the release candidate, after using it yourself.
5. Launch and 30 days of support
We handle the deployment, the app store submissions where relevant, and the monitoring in the first weeks when real usage always reveals things testing did not. Thirty days of support is included in every engagement — not as an upsell, but because a product that breaks quietly two weeks after launch is not a product we finished.
You get: the running product, the source code, and documentation your next developer can actually follow.
What happens when something goes wrong
Occasionally a project hits something neither side predicted — a third-party API turns out not to do what its documentation claims, or testing reveals a feature is harder than it looked. When that happens you hear about it the same week, with the options and what each one costs in time and money. You will not find out at the deadline. It is the least comfortable conversation in this business and the one that most determines whether a project ends well.
