Process
Five stages. Five sign-offs.
A focused MVP takes 10 to 16 weeks from kickoff to Play Store release. That splits into five stages — ideation, design, build, release and maintain — each with a fixed deliverable, a written sign-off, and a clear statement of what we need from you before it can start. The list below is the actual sequence, not a sales diagram.
- Typical MVP
- 10–16 weeks end to end
- Sprint length
- 2 weeks, one build each
- Decision-makers
- One, on your side
- Warranty
- 30 days on delivered work
- 01
Ideation
1–2 weeks
We map the users, cut the feature list to what proves the idea, and hand you a scoped MVP definition with a written estimate and timeline.
Ideation ends when the app has a defined edge. We work out who the app is for, what single job it has to do better than the alternative, and which features can wait until real users ask for them. The output is a document, not a conversation: an MVP definition, a screen inventory, and an estimate priced against that scope so the number does not move later without a written change.
What you get
- Written MVP definition and screen inventory
- Feature cut-list with reasons for each cut
- Estimate and timeline against that exact scope
What we need
An hour of your time and access to two or three people who would use the app.
- 02
Design
2–3 weeks
Flows, wireframes, then a complete UI kit and clickable prototype. You sign off screen by screen, so build never starts on an open question.
Design turns the scope into something you can click. Flows first, then wireframes for the screens with real complexity, then the full UI. Every screen is drawn with its empty, loading and error states, because those are the states users hit on a bad network and the ones teams forget to specify. Nothing moves to build until the file is signed off screen by screen.
What you get
- Figma file with flows, wireframes and the full UI kit
- Every screen state drawn: empty, loading, error, permission
- Clickable prototype for stakeholder and user testing
What we need
Your brand assets if you have them, and sign-off within a few days per batch.
- 03
Build
6–12 weeks
Two-week sprints. Every sprint ends with an installable build on your phone and a short demo call. Scope changes are priced before they are started.
Build runs in two-week sprints against the approved design. At the end of each sprint you install the app on your own device and we walk through it on a short call. Progress you can hold is the only progress report we trust — screenshots and percentage-complete numbers hide problems. Anything outside the approved scope gets a written price before work begins, so the budget never surprises you at the end.
What you get
- Installable build every two weeks
- Sprint demo call and a written summary
- Commits landing in your Git repository throughout
What we need
Feedback on each sprint build within a few days, and one decision-maker.
- 04
Release
1–2 weeks
Device testing, store listing, data-safety declarations, signing and a staged Play Store rollout. Crash and analytics reporting is live from day one.
Release is a checklist we have run five times on our own apps. Testing across real devices and Android versions, then the store listing, screenshots, privacy policy and data-safety form, then signing under your developer account. Rollout is staged: a small percentage of users first, with crash reporting and analytics already reporting, so a problem is caught while it is still small.
What you get
- Store listing copy, screenshots and policy documents
- Signing keys and the listing under your developer account
- Staged rollout with live crash and analytics dashboards
What we need
A Google Play developer account in your company's name.
- 05
Maintain
Ongoing
A monthly retainer covers OS upgrades, store policy changes, crash fixes and small features, so the app does not quietly rot after launch.
Every build carries a 30-day warranty on defects in delivered work at no charge. After that, maintenance is optional and honest: a fixed number of hours a month covering OS and SDK upgrades, store policy changes, crash triage and small feature work, with a log of what the hours went on. If you stop needing us, the code, the keys and the store listing are already yours.
What you get
- 30-day defect warranty on delivered work
- Fixed monthly hours with a named contact
- A written log of what every hour was spent on
What we need
Nothing, unless you want changes. We watch the crash dashboard either way.
The four rules behind it
The stages are the shape of the work. These are the rules that keep the shape honest when a project gets busy.
Nothing starts on an open question
A stage begins only when the previous one is signed off in writing. Ambiguity is cheap to fix in a document and expensive to fix in a codebase, so we resolve it where it is cheap.
Progress is something you can install
Every two weeks you get a build on your own phone. Percentage-complete reports hide problems for weeks; an app you can open tells you the truth in thirty seconds.
Scope changes are priced before they start
New ideas during a build are normal and welcome. Each one gets a written price and timeline impact before any work happens, so the final invoice never contains a surprise.
You own everything as it is made
Commits land in your Git repository from day one, designs live in your Figma, and the store listing sits in your developer account. Ownership is not a hand-over event at the end.
Next step
Start at stage one
Ideation is the cheapest place to change your mind. Send the problem you want solved and we will scope the smallest app that proves it is worth building.