Three months is a realistic timeline for the first version of a product. Not for a system “like the big players have”, but for an MVP: one main scenario that solves the user’s problem from start to finish. In a mobile app that usually means 5–8 screens, sign-in, data over an API and a simple admin panel.
To hold that timeline, writing code fast matters less than dropping the extras in time. Below is what those three months look like and what fits into them.
What an MVP really is
An MVP is the smallest version of a product with which a user can solve their problem completely. The key word is “completely”. Not a prototype, not a set of placeholder screens and not the first third of a large system, but a small yet finished product.
A handy test: can you hand the MVP to a real person without standing behind them explaining things? If the user goes from sign-in to the result on their own, it is an MVP. If halfway through they hit “this feature is coming later”, it is still a demo.
A good first version answers one question: do people need the product in this form? Anything that does not help answer that question can wait.
How the three months are spent
An approximate plan, if the task is clear and decisions are made quickly:
| Period | What happens | Result |
|---|---|---|
| Week 1 | introduction, estimate, stage plan | timeline, cost, first version scope |
| Weeks 2–3 | requirements, design, specification | approved mockups and specification |
| Weeks 4–10 | development in 2-week iterations | a working version on a demo after each iteration |
| Weeks 11–12 | testing, fixes, launch | the first version in users’ hands |
That gives three or four development iterations. After each one you see a working product, not a report about a percentage of completion. This matters: if the second demo shows that users need something else, the plan changes right away, not after launch.
Preparation takes less than three weeks, and it is not wasted time. Every day spent agreeing on a mockup saves several days of rework in code.
What to include in the first version
Start with the one scenario the product exists for. For an ordering service it is “find — order — pay — track the status”. For an internal tool it is “submit a request — see what happens to it”. Everything else is built around that.
An MVP usually includes:
- the main scenario in full, without placeholders;
- sign-in — by phone, email or a corporate account;
- the data the scenario cannot work without — a catalogue, reference lists, profiles;
- a simple admin panel, so the team can manage content without developers;
- analytics — which screens people open and where they stop;
- notifications, if the scenario breaks without them — an order status, for example.
That is enough to show the product to the first users and get an honest answer.
What you can safely postpone
This is where most of the time is saved. Typical candidates for “after launch”:
- the second and third user roles, if the first one can work without them;
- advanced analytics and reports — basic metrics are enough for the first months;
- settings, themes, personalisation;
- rare scenarios — something that happens once a month can be done by hand for a while;
- integrations “just in case” — connect only the ones the main scenario cannot work without;
- automating what is still easier to do by hand — exports for accounting, for example.
A good question for every feature: what happens if it is not in the first version? If the answer is “the user cannot solve the problem”, the feature is needed. If it is “things will be a little less convenient”, it can wait.
Where time usually gets lost
Three months easily turn into five. The reasons are almost always the same:
- decisions are slow. The demo is over, but feedback arrives two weeks later. An iteration is lost;
- the scope grows along the way. Each new feature looks small, but together they eat a month;
- external systems are not ready. An integration depends on an API with no access or documentation yet;
- access arrives at the last moment — to servers, app stores, the payment provider.
Much of this can be settled in advance: appoint one person who makes product decisions, agree on how soon feedback comes after a demo, and request all access in the first week.
How to test the idea
Launching an MVP is the start of the test, not its result. Before development, it helps to decide what result will count as success. For example:
- how many users should complete the main scenario in the first month;
- how many of them come back a second time;
- at which step users leave, and why;
- how much time employees save, if the product is internal.
The numbers depend on the product, but the approach is the same: agree on the criterion first, then look at the data. Without that, any first version seems “fine overall”, and decisions about what to build next are made on gut feeling.
After launch, new features are added in the same two-week iterations — but now based on real users’ data rather than a wish list from the first month.
What such an MVP costs
A mobile MVP for iOS and Android (5–8 screens, sign-in, API calls) costs from RUB 2.1 million and takes 2–3 months. For web products, a first version with the key scenario also ships in 2–3 months; the cost depends on the scope. We give an accurate estimate for free after a short conversation about the task. More on the custom software development and mobile app development pages.
Three months is not much. But it is usually enough to learn whether people need the product. The users will tell you the rest.
