Stop Building. You Do Not Have Ten Users Who Need What You Are Making.

Three months of clean code, and the user went straight for the feature we almost deleted.

Here's something the startup ecosystem doesn't say out loud often enough: a lot of technical founders are building products that nobody actually needs.

The founders are talented. The engineering is usually good, sometimes excellent. The issue sits somewhere else. Technical founders pick problems they understand technically, and those aren't always the problems a real person in a real business is desperate to solve. The gap between an interesting technical challenge and a genuine pain point someone will pay to make go away is where most early-stage products quietly die. Closing that gap means getting in front of real users before you disappear into a six-month build.

I've made this mistake. At Pasella we spent three months building inventory management for spaza shops in Soweto. Clean code, sound architecture, a feature set that ticked every box I'd written down at the start. The first shop owner who used it skipped past all of it and tapped on a tiny summary screen we'd added almost as filler. She wanted to know what had sold that morning so she could decide what to restock that afternoon. Inventory management wasn't the problem. The morning report was.

We had built the system right. We had not built the right system.

The technical founder's blindspot

It's not incompetence. It's comfort. Building feels like progress, and for someone whose primary skill is building, it's the most natural thing to reach for when the path forward is unclear. Unsure whether customers will pay? Ship another feature. Worried about product-market fit? Refactor the data model. Deployment pipeline a bit slow? Fix that first, talk to users later.

Try this instead. Before you open your editor tomorrow, schedule three conversations with people who might use what you're building. Not a demo, not a pitch, but a conversation where you ask what their day looks like, where they lose time, what they hate about the tools they use now. If you can't find three people willing to talk to you for half an hour, that itself is information.

I've sat in standups where the engineering discussion was sharp and the customer discussion was a single line item that got skipped because nobody had anything to report. Sprint velocity, deployment frequency, test coverage, all tracked weekly. Number of conversations with actual users that week: zero, and nobody flagged it. These weren't bad teams. They were good teams solving the wrong problem with real skill.

A clean board can hide the fact that you're shipping the wrong thing on time.

In markets where capital is tight and rounds are smaller and further apart, this is expensive in a way it isn't in San Francisco. In a lot of African markets, the distance between a failed first product and shutting the company down is months, not years.

There's no soft landing, no pivot narrative dressed up for a bridge round. The runway just ends.

Ten users is a reckoning, not a milestone

Your first ten users aren't there to tell you the product works. They're there to tell you whether it should exist.

That sounds harsh. The alternative? Building for a year before discovering the market doesn't care is even harsher.

Stitch, before becoming one of the standout API fintechs on the continent, was a small team in Cape Town working with a handful of developers who needed to plug into banking infrastructure. They didn't build a platform and wait for adoption. They found the developers with the actual problem, built for those specific people, and let the platform shape itself around what those users needed. The platform came after. The insight came first.

Early users aren't testers. Treat them as the most important collaborators you'll ever have.

Your first ten users should make you a little uncomfortable. They should be close enough that you can't hide behind a dashboard or a weekly report. Close enough that when they tell you something is off, you feel it physically. That discomfort is the signal you're listening for. If your first ten users are entirely happy, one of two things is true: you got it exactly right, which is rare, or they are not using it hard enough yet to show you what is wrong.

How to find ten users when you have no sales team

You do not need a sales team for your first ten users. You need a founder who is willing to leave the building.

I do not mean that as a metaphor. I mean physically leave. Go to where your customers work. Buy something. Introduce yourself. Ask if you can watch for twenty minutes. The first three Pasella users did not come from a Slack message or a landing page. They came from me walking into spaza shops with my phone in my hand, showing the product to the person behind the counter, and asking what they thought. Two of them signed up on the spot. The third told me the onboarding was confusing, which was more valuable than both sign-ups combined.

Founder-led sales is not a phase you rush through on the way to hiring a sales team. It is one of the most important commercial activities you will do in the first year of your company, because nobody else will hear the objections, watch the hesitations, or notice the moments where a customer's face changes from polite interest to real engagement. A sales hire can report those moments back to you in a weekly summary. That is still not the same as feeling them yourself.

The pattern that works is simple. Work out where your target customers physically gather, whether that is a market, a co-working space, an industry meetup, a business park, or a strip of shops in a township. Go there. Not once. Repeatedly. Become a familiar face before you become a pitch. And when you do pitch, keep it to one sentence: "I built something that helps you do [specific thing]. Can I show you?"

Online communities can supplement this, but they should not replace it. A WhatsApp message in a founder group might get you a warm introduction. A post in an industry forum might surface someone with the right problem. But the richest signal still comes from being in the room, watching a real person try to use your product in the middle of their actual workday, with customers waiting, stock to check, and a phone buzzing with supplier messages. That context is impossible to simulate remotely, and it is where you learn whether your product fits into a real life or only works in a demo.

Founders who skip this step and go straight to paid acquisition or content marketing are optimising for reach before they have earned the right to scale. You earn that right one user at a time, in person, by doing the work that does not scale until you understand why it eventually should.

The "right system" question

Every founding CTO should tape this question to their monitor: am I building the system right, or am I building the right system?

Two questions that look similar but lead to completely different companies.

Here is a quick self-check. Ask yourself these four questions honestly, and if you answer "no" to more than one, you are probably optimising in the wrong direction.

A quick self-check. If you answer "no" to more than one of these, you're optimising in the wrong direction:

• Can I name five specific people who have this problem and have told me so directly?
• Have I watched someone try to solve this problem without my product in the last two weeks?
• Can I describe the value my product delivers in one sentence that a user would recognise as accurate?
• Am I building the next feature because a real user asked for it, or because it's interesting to me?

Building the system right is engineering quality. It matters eventually, and it matters a lot once you have something worth scaling. But it's a second-order question. Building the right system is about whether anyone will pay, return, and tell a friend. That's a product question, and technical founders tend to defer it because it feels less concrete than a code review or a load test.

The way you answer it isn't through market research or TAM spreadsheets. You answer it through repeated, often awkward contact with the people you're building for. You sit in their shop or office. You watch them wrestle with the spreadsheet or the WhatsApp thread or the manual process your product is supposed to replace. You find out what frustrates them in practice, which is almost never what you assumed would frustrate them when you wrote the spec.

In my experience the assumed frustration and the actual frustration overlap maybe 30% of the time. The other 70% is where the real product hides.

The most expensive mistake you can make

The most expensive mistake isn't bad code or bad design. It's building something technically excellent that solves the wrong problem, then trying to market your way out of the mismatch.

I've watched more than a dozen teams do this in the last two years. Good engineers, capable products, wrong thesis. By the time they realise the market isn't responding the way they expected, six months of runway is gone and the only real option is a pivot, which in practice means starting the listening process they should have started with their first ten users.

CB Insights has reported that the top reason startups fail is building something the market doesn't want — cited in 42% of failed startups they analysed. Not running out of cash, not competition, not founder disputes. Misreading the market. The stat isn't new, and founders keep behaving as though it applies to other people.

The fix isn't complicated. It just requires a kind of discipline that doesn't come naturally to people who love to build. Talk to your first ten users before you build. Talk to them while you build. Talk to them after you build. Treat user contact as non-negotiable as code review.

A weekly routine that keeps this from becoming an intention you never act on: block ninety minutes every Friday. In that time, have one conversation with a current or prospective user, watch one session recording or piece of usage data, and write down one thing you learned that contradicts an assumption you were operating on. Drop it in a doc the whole team can see. Ninety minutes a week. The compounding effect is large, and the cost of skipping it is usually fatal.

And when one of your first ten users ignores the headline feature and falls in love with something you almost cut, don't argue. They're showing you what your product actually is, which is information you couldn't have generated any other way.

The feature they love is the product. The one they ignore was your hypothesis.