Build as Little as Possible — The Minimalist Entrepreneur's Minimal Building Rule

Have you ever had this experience: you spent three months building a feature, launched it, nobody used it, and then discovered that what users actually wanted could have been solved with a Google Sheet?

Sahil Lavingia says in The Minimalist Entrepreneur: this isn't bad luck — it's a problem with your sequence.

What MVP Actually Means

Most people's first reaction to MVP (Minimum Viable Product) is: "Build a simpler version with just the basic features." That understanding isn't wrong, but the emphasis usually lands in the wrong place.

Most people think of the "product" in MVP. Lavingia wants you to take one step earlier and think about the "process."

The first layer of what he means by "Build as Little as Possible" isn't "cut the product down to minimum features." It's: first build a Manual Valuable Process, validate that someone will pay for it, and only then begin to automate it.

This manual process might be: answering customer questions one-on-one over email, organizing data for someone in a spreadsheet, personally walking a student through a process over Zoom — these are all "services," not "products."

But they can tell you something no product ever could: where the customer's real problem is, and which words in what they say are the actual pain point.

Why Running a Process Matters More Than Writing Code

This is a deeply counterintuitive suggestion, especially for people with engineering backgrounds.

Here's the reason: software is expensive — not in money, but in "it's hard to change once built." Every line of code is an implicit assumption. When your assumptions are wrong, your code is amplifying your mistakes.

By contrast, the cost of changing a manual process is almost zero. You serve a customer one way today, switch to a different approach tomorrow — no legacy burden whatsoever. You're iterating with human effort, not engineering resources.

Lavingia's logic: "Work directly with customers to iterate toward a solution, and make sure it's worth paying for, before you take it to customers outside your community."

Notice the order in that sentence: iterate toward a solution first, confirm people will pay, then expand. Complete all three steps, and only then start building a product — that's the right timing.

How to Find the Solution Worth Building

Many people make one mistake when validating an idea: they ask the wrong question.

Lavingia gives a very direct comparison:

Wrong question: "If I built this, would you buy it?"
Right question: "Why haven't you solved this problem yet?"

The first gets you the other person's goodwill (they don't want to disappoint you, so they say yes). The second gets you the real friction — is it cost, lack of awareness, existing tools being inadequate, or do they not even see it as a problem?

That difference determines whether what you build later is a solution to a real need, or a product of your own imagination.

Another key point: at this stage, you can already charge money. You don't need to wait until you have a product before you have income. If you're genuinely helping someone solve a problem, you're entitled to charge a consulting fee, a service fee, or some form of compensation — and that money is simultaneously the most direct market validation of your hypothesis.

What's Worth Building

At this point you have a few customers, a manual process, and paid validation — so when is it "worth it" to turn this into a product?

Lavingia's standard is simple: when your manual process starts repeating, and the repeating parts can be automated, that's when to build a product.

Not "I think this could be automated," but "I've done this manually ten times, confirmed the process works, people are paying for it, and I'm repeating the same steps every time." When you build something at that point, every single feature has a real need supporting it — not a single line of code is a bet.

One more thing: do one thing, do it well. A Minimalist Entrepreneur's product doesn't try to do everything — it aims to be the best at one problem. That kind of product is easier to articulate who it's for, and easier for the right people to spread naturally.

Common Mistakes

"I should perfect the product before launching."
This sentence kills many good ideas every year. Nobody's first version is perfect. Perfection is earned through iteration, and iteration requires real users — so you need to go out first, not wait first.

"I need a proper MVP before I can start selling."
You don't need an MVP to start selling services. Before a product exists, you can sell your time, sell your process, sell your judgment. Sell first, validate first, build second — that's the Minimalist Entrepreneur's order.

"Freelancing or consulting isn't real entrepreneurship."
In the early stage, it is. Trading your time for income while deeply understanding customer problems — that's the most cost-effective market research there is. Many successful SaaS products started life as a manual service run by one person.

Next Step

You now have a solution someone is willing to pay for. Next you need to reach more customers — but "convincing more people to buy" has a completely different logic in the Minimalist Entrepreneur playbook.

Sell Through Education — Educational Selling, Not Persuasion breaks down how to replace sales pitches with education, letting customers walk in on their own.

Back to Series Overview

This is the second stop in the Minimalist Entrepreneur series, focused on the minimal building rule and product validation logic. For the complete reading path and other article topics, return to Minimalist Entrepreneur Beginner Course.