Mobile app MVP
One key scenario works end to end on real data, and the app is in the App Store and Google Play. The rest is postponed deliberately rather than forgotten.
- Buildfrom $3,550
- Timeline6–10 weeks
- Supportfrom $420/mo
Who this suits: A product that exists as mockups and a feature list, when what needs checking is one scenario with real people on their own phones.
What is in the first version
- one whole scenario
- iOS and Android screens
- sign-in and an account
- publication in both stores
The figures above are the package this sits on: MVP or full product. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
Install and the first screen
The person lands inside the scenario, and sign-up asks only for what the next step cannot happen without.
- 02
The scenario runs to its end
It has a finish: an order created, a measurement recorded, a report sent, not a continuation in a web account.
- 03
The result outlives the phone
What the person makes goes to the server, and a record is confirmed by the server rather than an animation.
What decides whether this works or annoys people
Review rejects what is not code
Account deletion, the privacy policy, Sign in with Apple and the camera explanation go into the first version.
One scenario whole, not three halves
Half a scenario tests nothing, so the line around the list is drawn before the build and the rest is written down.
The signal drops, the send repeats
The app queues what does not go through, and the server recognises a repeat by key, or one order becomes three.
What to measure once it is live
- installs that reach the end of the scenario
- time from install to the first result
- sessions with no crash
- people who come back the next week
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- The appFlutterSwiftKotlin
- Server and dataTypeScriptNode.jsPostgreSQLPrismaRedisS3
- Alerts and operationsTelegram Bot APIDockerGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- developer accounts in both stores
- the store’s share of in-app purchases
- the server and file storage
- SMS with a confirmation code at sign-in
Asked before the first call
- Both platforms at once?
- Yes, from a single codebase, inside the first release. Only push, in-app purchases and permissions diverge. If the scenario rests on something one platform alone has, we say so before the estimate.
- Who submits it to the stores, and what if it is rejected?
- We submit and we close the review comments, and that is part of the work rather than a separate invoice. The usual stumbling requirements are handled before we send it in.
- Whose accounts and whose code?
- The developer accounts are opened for your business, the signing keys stay with you, and the repository is yours from the first day. Nothing a next team needs stays on our side.