What Is the Minimum Viable Unit of Saleable Software?
In the world of software development, the phrase "minimum viable product" gets thrown around constantly. But there's a subtler, more precise question hiding beneath the MVP debate: what is the minimum viable unit of saleable software? Not software that users tolerate or that earns a waitlist signup — but software that someone will actually open their wallet for.
This distinction matters enormously, especially for indie hackers, bootstrapped founders, and small software teams who can't afford to spend months building features no one will pay for. The gap between "usable" and "saleable" is where most early software products go to die. Understanding that gap — and learning how to close it as efficiently as possible — can be the difference between a sustainable software business and an abandoned side project.
Why "Minimum Viable" Isn't Always "Minimum Saleable"
The traditional MVP framework, popularized by Eric Ries in The Lean Startup, encourages teams to release early and learn fast. The problem is that an MVP optimized for learning is not the same as a product optimized for revenue. A landing page with a signup form teaches you about demand. A rough prototype with five beta users teaches you about usability. But neither of those is necessarily something a stranger on the internet will pay real money for today.
Saleable software must clear a higher bar. It needs to solve a problem well enough that a buyer feels the exchange of money is justified. That means the product must deliver perceived value that exceeds its price — and it must do so reliably, without requiring hand-holding from the founder on every interaction.
This is why so many indie developers struggle even after launching a technically functional product. Functional is not the same as compelling. And compelling is not the same as worth paying for.
The Core Components of a Saleable Software Unit
When you strip away all the noise, a minimum viable unit of saleable software tends to share a few non-negotiable properties. These aren't features — they're structural requirements that make the product transactable in the first place.
1. A Clearly Defined Problem
Saleable software solves one problem that a buyer already knows they have. Not a problem the founder thinks they should have. Not a problem that requires extensive education to appreciate. Buyers don't pay for potential — they pay for relief. The more clearly the product's marketing and onboarding communicate "this is for your exact problem," the faster the sales cycle becomes.
2. A Functional Delivery Mechanism
The software must be deliverable without the founder in the loop. That means an onboarding flow that doesn't require a demo call, a payment system that processes transactions automatically, and a product experience that doesn't break on first contact. This sounds obvious, but it eliminates a huge percentage of products that call themselves "launched." If you have to personally shepherd every new user through setup, you don't have a product — you have a consulting engagement wearing a SaaS costume.
3. A Price the Market Can Decode
Pricing is a communication tool before it's a revenue tool. The price of your software tells a buyer who it's for, how serious the solution is, and whether they're in the right place. A $5/month price signals a casual utility. A $299/month price signals a business tool with measurable ROI. Mispricing — in either direction — kills conversions even when the product itself is strong. A minimum saleable product needs a price that makes intuitive sense given the problem it solves and the buyer it's targeting.
4. Enough Trust to Trigger a Purchase
Trust is the invisible ingredient in every software sale. Buyers need to believe the product will work, that the company won't disappear next month, and that they won't be trapped in a billing nightmare if they want to cancel. At minimum, this means a professional-looking website, clear terms, visible contact information, and some form of social proof — even if that's just a handful of honest testimonials. Without trust, even great software goes unsold.
What You Can Safely Leave Out
One of the most valuable exercises for any software founder is identifying what not to build before launch. Many early-stage products are bloated with features that feel necessary but aren't — admin dashboards, advanced reporting, team collaboration tools, integrations with every possible third-party service.
A minimum saleable product doesn't need any of those things. It needs the single workflow that delivers the core value, executed well. Everything else is a future version. Shipping a focused, well-executed core product beats shipping a sprawling half-finished one every single time — both in terms of user experience and in terms of the founder's sanity.
The Saleable Unit Is Smaller Than You Think
One of the most counterintuitive insights in software product development is that the minimum viable unit of saleable software is usually smaller — much smaller — than founders expect. The tendency to over-build before launch is almost universal, and it's driven by fear: fear that buyers will reject the product for being too simple, fear of bad reviews, fear of looking amateurish.
In practice, buyers are far more forgiving of simplicity than founders imagine, provided the software does what it promises. A single-feature tool that solves one painful problem reliably will outsell a feature-rich product that tries to do everything and does none of it perfectly.
Shipping Is a Skill, Not Just a Decision
Understanding what makes software saleable is only half the equation. The other half is developing the discipline to stop building and start selling. Many technically excellent developers never reach their first dollar of revenue not because their product wasn't good enough, but because they kept adding "just one more feature" before launch.
The minimum viable unit of saleable software is ultimately defined by the market, not the builder. The fastest way to find out where that line sits is to put something real in front of real buyers — with a real price attached — and watch what happens. The feedback you get from a paying customer in 24 hours is worth more than six months of internal iteration.
Build less. Ship sooner. Charge real money. That's the formula that separates software businesses from software hobbies.