MVP in 30 days: what makes the cut and what doesn't

"We deliver in 30 days" sounds like a sales pitch. Often it is: there are teams that promise a month, hand over a demo that doesn't survive its first real day of use, and call that an MVP.

But the promise can also be genuine, and the difference isn't the team's speed. It's what got left out on purpose. A month is a perfectly reachable deadline for putting a system into production, as long as both sides accept an uncomfortable rule: in thirty days you don't get everything you want, and the hard conversation has to happen at the start.

This piece is about that conversation.

What an MVP is and isn't

The term has been worn down until it means "the cheap version". That isn't it.

An MVP is the smallest version of the system that's already good enough to work with. The word that matters isn't "minimum": it's "viable". If your team can't operate on it and has to keep the spreadsheet running alongside, you didn't deliver an MVP. You delivered a demo.

That's where the cut-off rule comes from, and it settles everything else:

A feature goes into the MVP if without it the system can't be used to do the work. Not if it's important, not if it's urgent, not if the client asked for it emphatically.

It's a harsh rule and that's why it works. "Important" covers almost everything; "we can't operate without this" covers much less.

What always makes the cut

In a business system, this is the floor. Take any of these out and you get something nobody can use:

The main flow, end to end. If the system manages orders, it has to be able to create an order, track it and close it. Half a flow is worth nothing.
Login and basic permissions. Even if it's only two roles. A system where everyone can do everything doesn't go into production at a real company.
Loading the data you already have. An empty system doesn't get used. The initial migration isn't optional.
Whatever the law or the client requires. If you have to issue a tax-compliant invoice, that isn't negotiable and it can't wait.
Not losing data. Backups, error handling, validations. It's the first thing that gets cut and the one that costs the system its credibility forever, the first time something disappears.

What almost always gets left out

This is the list that gets pushback, and it's where the month of difference lives.

Reports and dashboards. Almost everyone asks for them in the first meeting and almost nobody looks at them for the first two months. On top of that, the reports you'll actually use only become clear once the system has data in it. Building them earlier is guessing.
The mobile app. Unless the work happens on the road or in a warehouse with no signal. A web app built properly for a phone covers stage one.
Integrations that don't block the operation. If you can key something in by hand for a month, the integration goes to stage two. Integrations are the least predictable item on any schedule, because they depend on systems you don't control.
Edge cases. The vendor who bills differently, the customer with the legacy discount, the exception that shows up twice a year. In the MVP they get handled by hand, and in stage two you automate the ones that actually turned up.
Making everything configurable. The temptation to have "every parameter editable from an admin panel" doubles the work. In the MVP, anything that changes once a year is written into the system and adjusted by request.
Notifications and automations. Automatic emails, reminders, alerts. They add real value and none of them is essential in month one.

Why most of them fail

Three reasons, and none of them is technical.

1. The scope wasn't closed, it was postponed

The most common failure. Both sides avoid the uncomfortable conversation up front —saying no feels rude— and start with a fuzzy scope. The argument happens anyway, just in week three, with half the system built and the deadline in sight. By then you can't cut anything without throwing away finished work.

2. Nobody on the client side can decide alone

A thirty-day project needs decisions in hours, not weeks. If every definition has to pass through three departments and a board meeting, the schedule dies in the first week. It isn't a bureaucracy problem: a project can't move faster than its decisions.

An MVP in a month needs one person on the client side with the authority to decide and at least a few hours a week available. If that person doesn't exist, thirty days is the wrong deadline.

3. "Minimum" got confused with "sloppy"

An MVP is small in scope, not in quality. If you hit the date by cutting validations, error handling and testing, what you deliver is debt with interest: month two goes entirely into fixing month one, and the system starts out with a bad reputation inside the company. Winning back a team that tried a system and watched it break costs more than building it right would have.

What a month that works looks like

A realistic four-week schedule looks a lot like this:

Week 1 — Definition and structure. The scope gets closed in writing, the screens and business rules get agreed, the data model gets defined and the technical base of the project gets set up. By the end of the week there's something you can open, even if it's nearly empty.

Week 2 — The main flow. The full path gets built, end to end. Ugly, unpolished, but complete. At the end of the week the client tries it.

Week 3 — Everything around the flow. Permissions, validations, the cases that showed up when the client tried it the week before, loading the existing data.

Week 4 — Production. Adjustments, testing, final migration, deployment and training. The last week isn't for building: it's for getting the system into the real operation.

Two details make this work: the client tries something at the end of every week, and week four has no new features assigned to it. A schedule that fills the last week with development has no room for the one thing that's guaranteed to happen, which is that something turns out differently than planned.

Stage two, which is what makes any of this make sense

None of this works if the MVP is treated as the finish line. It's the first of several deliveries, and there's an economic reason: stage two gets defined with information you don't have today.

After a month of real use you know which screens get opened all day and which ones nobody touched, which report people actually want, which edge case showed up six times and which one never did. You can't get that information in a requirements meeting. You only get it by using the system.

In practice, the stage-two priority list almost never matches what got postponed in stage one. That isn't a planning failure: it's exactly the benefit of shipping to production fast. Building everything that was asked for in month zero would have meant paying for features that reality later deprioritized.

How to tell whether your project fits in a month

Four questions:

Can you name the main flow in one sentence? "Take an order, assign it to a driver, and close it with the customer's signature." If it doesn't fit in one sentence, it's probably two projects.
Is there one person who can decide without checking with anyone? With real availability.
Are the integrations essential on day one? If they are, the deadline depends on third parties and you don't control it.
Are you willing to have the first version ship without reports? If the answer is no, that's a valid answer, but the deadline isn't a month.

If all four come back yes, a month is realistic.

If one comes back no, it's still a perfectly healthy project: it just runs two or three months, and it's much better to know that in week zero than in week five.