I get asked some version of the same question by nearly every founder I talk to. How long should it take to build a minimum viable product? My honest answer is almost always the same. If it is taking you longer than a month, you are not building an MVP anymore. You are building a proper product, and you have talked yourself into believing you need to before you have any evidence that anyone wants it.
I have built four businesses this way, CampSuite, Crocodile HR, Lavida and RealCube, and every single one started as something rough that went live inside a month. I am writing a whole book on this process called The 28 Day Startup, but the short version is simple enough to fit in one blog post. Here is how I actually do it.
What minimum viable actually means
Most founders get the word "viable" backwards. They read it as "good enough to impress people" and build accordingly, adding polish, extra features and edge case handling for problems they do not have customers for yet. Viable does not mean impressive. It means the product genuinely solves the core problem for a real person, even if it is ugly, manual in places and missing everything that is not essential.
The test I use is brutally simple. Can a stranger complete the one thing your product promises, start to finish, without you standing next to them explaining it? If yes, it is viable. Everything else, the settings pages, the admin dashboard, the nice onboarding flow, can wait until you know people actually want the core thing.
Week one: pick the one problem and say no to everything else
The first week is not for coding. It is for cutting. Write down every feature you think the product needs, then cross out everything except the single feature that delivers the core value. If you cannot describe your MVP in one sentence that a non technical friend understands, you have not scoped it tightly enough yet.
I wrote about the validation work that should happen before this stage in my post on how to validate a business idea before you build anything. If you skip that step, week one of the build becomes guesswork instead of execution, and guesswork is where months disappear.
Week two: build the ugly version first
This is where founders lose the most time, usually by over engineering something nobody has paid for yet. In week two I am not thinking about scale, clean architecture or the perfect database schema. I am thinking about the fastest honest path to a working product. Hard code what you can. Use a spreadsheet behind the scenes if it saves you a week. Skip the admin panel and run things manually from a database client for now.
None of this is bad practice at this stage. It is the correct trade. You are trading long term elegance for short term proof that the thing is worth building properly at all. I have thrown away plenty of week two code once a product proved itself, and I have never once regretted the speed it bought me.
Week three: wire up the boring but essential bits
Once the core feature works, week three is for the unglamorous plumbing that makes a product real rather than a demo. That means payments, if you are charging money, and it means the basics of authentication and data protection, because those are not optional even in an MVP. Stripe or a similar provider will get you a working checkout in a day. Do not build your own billing system at this stage, and honestly, do not build your own billing system at any stage unless billing is your product.
This is also the week to sort out the deployment story. You do not need a sophisticated pipeline. You need something that reliably gets your code in front of users without you manually copying files around at midnight. I have written before about keeping this kind of thing simple for small teams, and the same logic applies tenfold when the team is just you.
Week four: get it in front of real people
The mistake I see most often in the final week is founders polishing instead of shipping. They add one more feature, fix one more cosmetic issue, tell themselves it is nearly ready. It was ready a week ago. The only thing that actually moves you forward now is real users interacting with the real product and telling you, directly or through their behaviour, what is wrong with it.
Get it in front of the smallest group of people who actually have the problem you are solving. Watch what they do rather than asking what they think, because what people say and what they actually do with a product are frequently two different things entirely. Once you have real customers, the next question becomes which numbers actually matter, and I cover that properly in my piece on the SaaS metrics worth tracking when you are bootstrapped.
The mistake I made that cost me two months
On an early version of one of my businesses, I spent almost two months building a proper multi tenant architecture before a single customer had used the product. It felt responsible at the time. In hindsight it was procrastination dressed up as engineering discipline. Nobody had told me they wanted the product yet, and I was solving a scaling problem I did not have.
When I finally launched a genuinely rough version a few weeks later, half of what I had carefully architected for turned out to be irrelevant because real customers used the product completely differently to how I had imagined. That lesson stuck. Build for the ten users in front of you, not the ten thousand you are hoping for.
Why the deadline matters more than the plan
A hard deadline is the single most useful tool I have found for keeping an MVP genuinely minimal. Without one, scope creeps in gradually and invisibly. Every "it would only take a day" addition feels reasonable in isolation, and six weeks later you have a product that is more polished and further from launched than the version you could have shipped on day thirty.
Twenty eight days works because it is short enough to force real discipline about what matters, and long enough to actually build something that works rather than a prototype held together with hope. Pick your own number if you prefer, but pick one and treat it as fixed, not aspirational.
Start smaller than feels comfortable
If you take one thing from this, make it that your first version should feel slightly embarrassing to launch. Not broken, not dishonest about what it does, but smaller and rougher than you would naturally want to put your name to. That discomfort is a decent signal you have actually built a minimum viable product rather than talked yourself into another few months of building.
Ship it, watch what real people do with it, and let their behaviour tell you what to build next. That is the entire method. It is not clever. It just works, repeatedly, if you actually stick to it.
