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

Share
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