"Can it be built in 30 days?" is a question about the calendar. The better question is what the calendar has to hold. The number of days is what's left after other decisions have been made: what problem the first version has to prove, what it needs to contain to prove it, and what it deliberately leaves out. Speed comes downstream of those decisions, not instead of them.
So, can you? Sometimes. But 30 days is a ceiling to aim at once those decisions are made. We wouldn't promise it, and we have no evidence that every MVP can or should ship in 30 days. What our own project records show is narrower: Ifyify's first phase took two weeks, and Skill x Swap's MVP phase took six. Those are different products, so the numbers can't be compared — which is the point. A duration means little without the scope it was attached to.
Speed only helps once the problem is evidenced
A fast build points in one direction, so it makes the direction matter more, not less. If the problem behind the product is still a hypothesis, the quick version is a finished answer to a question nobody has confirmed.
Evidence here doesn't have to be a survey. It's a person who has the problem, and something they already do about it: a workaround, a spreadsheet, money already spent. Without that, the first version's job is to find the evidence, and that changes what belongs in it.
Decide the first version by the loop, not the feature list
A feature list grows because every item is individually reasonable. A loop is harder to argue with: the smallest complete path in which a user gets the outcome the product promises, and you can watch it happen. Everything in the first version should be on that path, or be needed to learn something the path can't show you.
The test is blunt: if this item disappeared, would the loop stop working, or would we stop being able to learn from it? If neither, it isn't part of the first version. It may still be a good idea. That's what the next section is for.
Liftly's founder had a sophisticated pricing engine at the centre of the vision. The first release was the operational loop around it: booking, serviceability, payment and the admin controls to run bookings. Ifyify's first phase was a guided flow, with style selection, that generates bios, taglines and brand personas, plus onboarding, authentication and a backend structured for expansion. In both, the first release was a working loop, with more expected later.
Scope arguments get simpler once an idea has to be in one of these states, out loud.
- Built. In this release. It costs build time, so it has to belong to the loop. Liftly's booking, serviceability, payment and admin controls are built. So is Ifyify's guided generation flow.
- Designed, not built. Thought through and written down, with no code shipped. It costs thinking, not build time, and it's worth doing where being wrong would be expensive to fix later. Liftly's Pricing Engine V2 is exactly this: service minimums, distance bands, labor, stairs, urgency and margin protection, scoped during V1 and not built, not shipped. Skill x Swap's record is a smaller case: its architecture was prepared for Stripe subscriptions and an enterprise edition in later phases.
- Later, not yet justified. Named so it isn't lost, with no design and no build. We can't point to an item in our records and say what became of it, so we won't pretend to.
What earns the next layer
Two different questions move an idea between states, and they're easy to blur.
Later to designed: would being wrong about this be expensive to fix afterwards? If so, think it through now, while thinking is cheap. That's judgment, and it's the reasoning behind scoping Liftly's pricing engine during V1 rather than treating it as something to figure out eventually.
Designed to built: did something you observed after shipping make this the next thing to build? This one needs evidence, not enthusiasm: what real users did, where the loop needed rescuing by hand, what they asked for that was already on your list.
We don't have that evidence for Liftly. The record shows V1 built and Pricing Engine V2 designed, and it contains no post-launch usage data. So V2 stays where it is: designed, not built. What would justify building it is the observation above: real use showing that the missing pricing capability is what now limits the product. Decision Room #001 works through that decision in full.
When speed gets dangerous
These are judgment calls from our work, not measured rates.
- The problem is still a guess. Speed delivers the wrong answer sooner.
- The deadline came before the scope. The calendar is fixed first, so the scope is squeezed to fit, and nobody decided which parts to cut.
- Later ideas leak into the first version. Anything never named as later gets added as "just one more screen."
- Nothing is watched after launch. If you can't see what people do, shipping fast only means deploying fast, and nothing can earn the next layer.
What the records show, and what they don't
Three first versions, described only as far as their project records go:
- Ifyify, an AI personal branding tool. The record lists the first phase as delivered in two weeks. The client, Kelly Andrews of Best Business Services, wrote: “Looking forward to Phase 2 expansion!”
- Skill x Swap, a credit-based skill-trading mobile app. The MVP phase took six weeks, with the architecture prepared for later phases.
- Liftly, in Decision Room #001: the operational core was built; the pricing engine was designed and is not built.
What the records don't tell us is what each first version left out, or what happened after launch. So we're not claiming these were fast in any comparative sense, or that the sequencing paid off. They show first versions scoped as phases, with later phases named. Judge the reasoning on its own merits.
