Sell it before you build it: a 5-step validation blueprint

This blueprint is for building software for other businesses.

Internal tools. Micro-solutions. Small, unglamorous software that companies are happy to pay for because it removes a job nobody wants to do. That’s the territory where this works, and it works well.

If you’re building for consumers, most of what follows won’t apply. Going to market is a different game there, and it needs its own guide.

The other thing worth saying upfront: this works fine alongside a job. You just move slower. 10 to 15 hours a week is enough to run every step here. It turns a 2-month process into a 5-month one. That’s a real cost, but it’s still much smaller than spending 5 months building something nobody buys.

We’re not starting with a framework. We’re starting with one real customer problem and working outward from there.

The 5 steps

1. Find 1 real pain. Talk to people. Find out what they already pay for, struggle with, or work around. Look for proof, not opinions.

2. Sell the smallest solution you can deliver. By hand, with existing tools, or with a small piece of software. Whatever is fastest. Charge for it. This is your first real validation.

3. Package it. Turn what you delivered into something repeatable. A one-pager, a landing page, a case study. Not a product. Just enough to sell the same thing again.

4. Sell the same thing 10 times. Use the first customer’s story as the pitch. If you can sell it 10 times, you’ve found something real.

5. Turn it into a system. Now, and only now, start building more. Automate and improve what you’ve already proven works.

Each step depends on the one before it. You can’t package a solution you haven’t delivered. You can’t turn something into a system if it only worked once.

Step 1: Find 1 real pain

Every product that works starts with a problem that hurts, not with a clever idea.

The fastest way to spot a real one is to look for signs that people are already paying, spending time, or putting workarounds in place to solve it. Existing effort is proof. Enthusiasm isn’t.

Questions that reveal actual behaviour

The goal is to find out what people do, not what they think they might do:

• “When was the last time you tried to solve this?”
• “How are you handling it now?”
• “What have you tried before? What worked and what didn’t?”
• “How much time or money did that cost you?”
• “What’s the most annoying part of the current setup?”

These questions get you closer to what is actually happening. And what people are already doing is much more useful than what they say they might do.

Where to look

You don’t need a eureka moment. Most real problems are already sitting in plain sight.

In your own work. What do people complain about every week? What takes far too long? What makes everyone groan when it comes up?

In what already works elsewhere. Look at things that work in another market or another country. Could they be adapted to your market?

In online communities. Reddit, niche Slack and Discord groups, industry forums. People describe their real problems publicly, often in a lot of detail.

In everyday workarounds. Spreadsheets, copy-paste routines, manual handoffs. Wherever there’s a workaround, there’s a problem someone has already decided is worth their time.

I ran an agency for 5 years, and most of what we were hired to build was a replacement for exactly this: an Excel file, a paper process, or a clunky internal workflow. Those inefficiencies haven’t gone anywhere. Every company still has them.

A small example

A friend works at an architecture firm. Every month they had to manually stamp dozens of PDFs. Same stamp, same position, one file at a time. They drew lots to decide who had to do it.

I automated it for him in 15 minutes.

The interesting part wasn’t his firm. It was that this probably wasn’t a problem unique to them. Other architecture and design offices were likely handling the same task in the same way.

One annoying task is a favour. The same annoying task in 30 offices is a pattern. And a pattern is where you start to see demand.

If you can’t find a pain that someone is already acting on, don’t build yet. Keep looking.

Step 2: Sell the smallest solution you can deliver

Opinions aren’t proof. The test is what saying yes costs someone, and this is the step where you ask them to pay it.

Solve one person’s problem in the fastest way you can, charge for it, and see whether it actually helps. Don’t think about scale yet. This is the stage Paul Graham was describing:

“Do things that don’t scale.”

It feels inefficient. That’s the point. You’re not building a business yet. You’re finding out whether one exists.

What “smallest solution” means now

The old version of this advice was: do it by hand. A spreadsheet you maintain yourself. A Make.com scenario. A done-for-you service you deliver every Monday morning.

That’s still often the right answer. But things have changed, and it’s worth being honest about it: sometimes the fastest way to solve someone’s problem now is to build a small piece of software. If Claude Code gets you there in 2 days and the manual version would take 2 days a month forever, build it.

Here’s where it gets dangerous. It feels quick. You think you’ll just knock it out. Then there are bugs, edge cases, and things you didn’t think about. Suddenly the 2-day build is a 3-week build, and you’ve stopped talking to the customer.

There’s no universal rule here. You decide per project. But there is a test that works:

Sometimes the answer is a spreadsheet. Sometimes it’s wiring 2 existing tools together. Sometimes it’s a small, ugly, single-purpose app. The question isn’t which one is more respectable. It’s which one gets you to a paying customer fastest.

How to think about pricing

Don’t overthink it. If your solution removes hours of manual work, that’s the easiest value to point at.

Saved time is saved money. Save someone 5 hours a month, and their time is worth €50 an hour, and you’ve created €250 of value. Charging €50 to €100 for that is an easy decision for them.

The exact amount doesn’t matter much at this stage. €20, €50, €200. What matters is that someone valued it enough to pay anything at all.

The example we’ll follow

A coaching business needed to track client sessions and handle invoicing. The goal was to detect when a client showed up, count the sessions, and generate an invoice at the end of each period.

The first version was a Make.com automation. No custom code, no product. Just a workflow I set up to prove the concept. She used it. It solved the problem. She paid for it.

Only then did we start building anything bigger, and even then in layers. The first proper version had no calendar sync of its own. We kept the Make.com scenario watching for calendar changes and notifying our system through a webhook. It was ready-made and it worked. We replaced it with real code much later, when there was a reason to.

You don’t jump from manual to finished product. You grow in layers, and each layer has to earn its place.

Your action: pick one pain from Step 1. Don’t design and don’t plan a product. Build or arrange the smallest possible solution and offer it to one person. Deliver it. Ask for money or a firm commitment. Write down what they said and what actually changed for them.

That’s your first customer story.

Step 3: Package it

You’ve solved one person’s problem. Now make it repeatable. Not by building a SaaS, but by delivering the same scrappy solution to the next customer.

Don’t start building accounts, logins, automated payments, billing, or a system that can support every possible customer. You already have a solution that works. Package it clearly and offer that same solution to someone with the same problem.

That can be as simple as:

• A one-page PDF explaining the problem, the solution, and the result
• A landing page with the offer and a way to get in touch
• A short demo or rough no-code prototype that shows how the workflow works

The goal isn’t to build a product or automate the delivery. It’s to make the existing solution easy to understand, sell, and deliver again.

Why a case study beats a pitch

Most people think selling means convincing. Cold outreach, objection handling, a persona you put on.

A case study makes it much simpler. You’re not trying to convince someone that your idea is useful. You’re showing them that it already worked for someone like them.

“I helped someone in your position with this. Here’s what we did and what it saved them. If that sounds useful, let’s talk.”

That’s it. No pressure, and no sales voice you have to fake. You’re showing someone that this worked for a peer in their world. If they recognise themselves in the story, the conversation becomes much easier, especially if selling isn’t your background.

Write it down in 6 parts

Don’t just deliver. Document.

1. Project: what were they trying to accomplish?
2. Context: why was this a priority now? What made them finally act?
3. Options: what else did they consider or try first?
4. Results: what did success look like to them? Be specific: hours, euros, stress.
5. How: how did you get them there? What was the process?
6. What: what exactly did they buy? What did the deliverable look like?

Here’s the coaching example in that shape:

1. Project: automate session tracking and invoicing for a coaching business
2. Context: she no longer had enough time to manage invoicing herself, so she was already paying an assistant around €200 to €300 a month to handle it
3. Options: there were ready-made tools on the market, but they required changing some of the way she worked. She didn’t want to change those parts of her process, so we built around the way she already worked
4. Results: the system automated session tracking and invoicing, saving her the monthly cost of having an assistant handle it. It also followed up with past clients six months after their coaching ended, asking how they were doing and whether they were still making progress
5. How: we first looked at how she worked and what she actually needed. Then we built the automation in several iterations, testing and adjusting it with her. The total work was around 2 to 3 days, spread across the process
6. What: a custom automation setup that initially only needed a Make.com plan to run. Everything else stayed within free tiers

Read that back and notice what it isn’t. It isn’t a feature list. Points 2 and 3, why now and what else they considered, are the parts most people skip. They’re also the parts that make the next customer recognise themselves.

Your action: document your first customer story in these 6 parts. That becomes your one-pager, your pitch, and your proof. You don’t need a designer or a developer. You need a clear description of the problem, evidence that you solved it, and a way to say “I can do this for you too.”

Step 4: Sell the same thing 10 times

You have a case study. The smart move now is not to build more. It’s to sell the exact same solution again.

• Use the same one-pager or pitch
• Approach people in the same role or industry
• Change as little as possible

Where to find the next 9

You don’t need a marketing strategy for this.

Ask for referrals. Your first customer knows others in the same situation. “Do you know anyone else in your field who deals with this?” People usually want to help.

Search LinkedIn by role. If your first customer was a coach, search for coaches. Read what they post about. Reach out to the ones describing the problem you just solved.

Sit in their groups. Find where your market talks to itself. Don’t pitch into it. Listen first, be useful, and share the case study when it’s actually relevant.

Why 10

10 isn’t a scientific number. It’s a point where you run out of ways to explain the result away.

That’s what you’re really getting from this step. Not revenue. €500 of one-off work is not a business. You’re getting enough evidence to stop guessing about whether the pattern is real.

And a warning that applies to everyone reading this, me included: building is fun. It’s satisfying to make something and watch it come together. Selling is not fun in the same way. But if you’re not selling, you’re not building a business. You’re entertaining yourself with a very expensive hobby.

The build phase is something you earn.

Your action: get 10 people to hear the same story and say yes. Track it properly: how many you approached, how many said yes, what the objections were, and what surprised you. That last column is worth more than the other three.

Step 5: Turn it into a system

Once people have paid for the same thing more than once, it’s time to make it consistent.

That doesn’t mean starting a big build. It means taking what already worked and making it repeatable.

Start by asking:

• How different were the 10 solutions, really?
• Can they be turned into one process?
• Which parts are genuinely custom, and which just felt custom at the time?

Most customers will accept a small change to their workflow if their actual problem gets solved. You don’t need to handle every edge case. You need to find the common thread.

Build in layers

Layer 1: keep some of it manual. Maybe you still onboard every customer by hand, but once they’re set up, it runs by itself.

Layer 2: use simple tools before building your own. Maybe you’re still invoicing manually instead of integrating payments. That’s fine for a long time.

Layer 3: wrap it in an interface. Hide the automation behind a small app. Let customers manage their own settings. Replace pieces gradually. Swap the spreadsheet input for a form, then the form for something better.

Write down which parts of your solution were identical for every customer. That’s Layer 1. And when you hand the first layer to AI, hand it one layer at a time — a big spec doesn’t work, and you now know exactly which part is proven.

When you’ve done this

If you get through all 5 steps, you have 10 paying customers and a system that delivers the same solution to them.

That’s further than most startups get, including well-funded ones. You found a real problem, sold a real solution, and proved that people will pay for it before spending months building.

Everything after this is execution. And now you’ve earned the right to do it.