When someone describes the tool or product they've been imagining, they describe the finished cathedral: every user type, every feature, every future contingency. It's natural — they've had years to accumulate the vision. It's also the main reason the project never happened. Cathedrals get quoted like cathedrals, and the quote goes in a drawer.
The move that unlocks these projects is not courage or budget. It's subtraction.
Useful is the load-bearing word
"Minimum viable product" has been abused into meaning "the broken version we apologize for." That's not what we mean. The smallest useful version is complete — it fully solves one real problem for one real user, today. Small refers to its footprint, not its quality. A two-day automation that reliably kills a weekly retyping chore is finished software; a half-built portal with nine placeholder screens is not smaller, just worse.
The test we apply: if we built only this, and nothing else ever, would it have been worth doing? If no, it's not the smallest useful version yet — it's a fragment. If yes, build exactly that, and let reality vote before anything else gets funded.
Finding the cut line
- Follow the pain, not the vision. The vision is a directory-slash-community-slash-marketplace. The pain is "I can't find local events in one place." Build the front page, skip the forum. That's how Mohawk Central shipped where a decade of grander versions hadn't.
- One user type first. Every additional audience roughly doubles the surface. The version for you — or your staff, or your best customer — is usually a fraction of the version for everyone.
- Cut the admin panel. Early on, a spreadsheet or a developer's ten minutes replaces most of the back-office you imagined. Build it when volume demands it, not before.
- Defer everything that depends on scale. Accounts, permissions, notifications, analytics dashboards — features that matter at a thousand users are pure cost at ten.
- Let a constraint be the design. Clipsboard is nine clips in a grid, on purpose. The limit isn't a compromise; it's the product.
When smaller is wrong
Honesty requires the other half. Some things can't be usefully small: half a payment flow, half a security model, half a data migration. If the "small version" would corrupt trust or data the moment it's used, the true smallest useful version includes those foundations — which is a fact worth knowing before committing, not a surprise after. And some ideas fail the worth-doing test at any size; lower prices are not a reason to build them. We say that too, for free, because it's cheaper than saying it after an invoice.
Why this is the buyer's best defense
Scope is where software money is lost — rarely in the hourly rate, almost always in building the wrong amount of the wrong thing. A provider who scopes down before scoping up is aligning with your budget; a provider whose first proposal is the cathedral is aligning with theirs. It's the first thing to check in any estimate, including ours: every Ivylane project starts with a written, plain-English scope built around the smallest version that's genuinely useful — and an explicit list of what we're deliberately not building yet, so growth is a decision instead of a surprise.