MVP in 2 Months: the method

The starting point: one question to validate

An MVP in 2 months starts from one clear question to validate, not a feature list. Before writing code, you need to define what the first version has to prove: not "everything works", but "this specific thing solves a real problem for these people". With BRUM, the question was whether an app could make preparing for the driving license exam more effective than a book or a traditional course. Everything else, the design, the secondary features, the integrations, came after, once the main question had an answer.

Cutting, not adding

The hardest work in the first weeks is not deciding what to build, it is deciding what not to build. Every "nice to have" feature that creeps into the first release's scope is time taken away from validating the main question. The practical rule is simple: if a feature does not help prove the idea works, it waits for version two. This also applies to requests that sound reasonable in the abstract: the right question is not "is this useful?", but "is this useful for answering the question we are validating right now?".

Stack and architecture built for day one, not year ten

A common mistake in the early stages is designing an architecture for a scale the product does not have yet. In 2 months you need a stack that lets you move fast, with reversible choices where possible: a simple architecture you can refactor later beats a complex one built for a user load that might never arrive. The genuinely hard-to-reverse decisions do deserve care upfront; everything else can stay deliberately simple.

Weekly iteration, not one big release

Two months is not enough time for a rigid plan set on day one and followed to the letter. It takes short, weekly cycles, with priorities that adjust as technical constraints or even informal feedback come in. The goal of the first weeks is to have something working as soon as possible, even if bare-bones, to start learning from contact with real users as early as possible. Every week that passes without something testable in hand is a week spent building on assumptions instead of data.

Store readiness: the last mile that gets underestimated

Publishing in the store, Apple App Store and Google Play, is not a last-minute detail, it is part of the plan from day one: review guidelines, technical requirements, privacy policy, graphic assets. Underestimating this step in the final weeks is one of the most common mistakes that adds unnecessary weeks. It needs to be planned from day one, not bolted on at the last moment: understanding which requirements apply to your specific case early on avoids surprises just when launch is days away.

What happens after the first release: the BRUM case

The MVP in store is not the finish line, it is the starting point for learning. With BRUM, after the first release in 2 months, the work continued by listening to real users and iterating continuously: today the platform counts 150,000 downloads, a 4.5★ rating, and 50,000 active users a month. None of those numbers existed at launch: they are the result of successive iterations built on top of a first release that was honest, not perfect, and of constantly listening to what worked and what did not for the people actually using the product.

What it actually takes to pull it off in 2 months

You do not need a huge team: you need a clear mandate and the ability to decide fast without going through too many layers of approval. In practice, that means someone with technical experience who can make those calls, stack, scope, priorities, without needing to validate them with the whole company every time: it is one of the reasons why, in early-stage phases, this role is often covered by a fractional CTO rather than a larger team. The speed comes more from clarity of mandate than from team size.

Frequently asked questions