Build less than you think you need

A founder showed me his product at Hackhouse a few weeks ago. Onboarding flow, referral engine, an admin panel, three pricing tiers, even a chatbot. Eight months of building, all of it careful and clean. I asked how many people were using it. He paused and said, "We launch next month. Then we'll find out."

That sentence is where a lot of talented founders lose a year.

I have watched it happen more times than I can count, and I have done it myself. You start with an idea that could genuinely help someone. Then, before a single customer has paid you anything, you decide the idea needs accounts and settings and a dashboard and a mobile app and dark mode. At that point the product has quietly become something else: your picture of what a serious company is supposed to look like.

Here is what that instinct costs you.

Building feels safer than selling.

Talking to a customer is uncomfortable. They can say no. They can leave you on read. They can tell you the thing you spent months on is not worth 2,000 shillings to them. Writing code feels like progress you fully control, so you keep adding to it. Every new feature becomes another reason to delay the conversation that actually decides whether you have a business. Months go by and you feel busy the entire time.

You are copying the wrong companies.

You open the Safaricom app, or Uber, or some product you admire, and you try to match it. But you are looking at ten years of work by hundreds of people, shaped by the millions of users they already had. That polish arrived once the demand was already there. When you copy the finished product, you skip the only part that made it work, which was learning what people actually needed one uncomfortable lesson at a time.

Every feature you add is a feature you have to carry.

More screens mean more bugs, more things to explain to a new user, more that can break at 11pm before a demo. A heavy product is slow to change, and early on, changing quickly is the main advantage you hold over the big players. Pile on features and you trade that advantage away for the feeling of looking impressive.

Every month of building is a month of runway.

Most founders I meet are not sitting on one-two years of savings. You have rent, maybe a teammate or two, and a private number in your head for how long you can keep going. Eight months of building before your first shilling of revenue is eight months spent against that number with nothing coming back in. A small product earning 20,000 shillings a month buys you more time, and more truth, than a big one earning nothing.

So build less. Much less than feels comfortable.

Start by writing down, in one sentence, the single job your product does for one person. Not the vision. The job. "It lets a mama mboga see how much stock she has left." "It helps a landlord collect rent without chasing tenants on WhatsApp." If you cannot say it in one sentence, your customer cannot either, and people do not pay for something they cannot explain to a friend.

Then build only the path a paying customer walks through, and nothing on either side of it. Someone signs up, uses the one feature, pays you. That path has to work properly. Everything around it can wait. No settings page. No admin dashboard. No second language. No referral programme for users you do not have yet.

The rest, you do by hand.

This is where founders push back, so I will be concrete. You do not need to automate anything you can still do yourself while you have ten customers. Reconcile the M-Pesa payments in a spreadsheet every evening. Onboard each new user on a WhatsApp call. Type out the reports and send them one by one. It feels unscalable, and that is fine, because ten customers is far too few for scale to be what kills you. What matters at ten customers is learning who they are and what they actually need, and doing the work by hand teaches you that faster than any code could, because you feel every slow, annoying step yourself before you build for it.

One founder I worked with wanted to build a full logistics platform. Routing, driver apps, live tracking, all of it. I asked her to first find five shops that would pay for deliveries. She coordinated those deliveries herself for three weeks, over calls and one very busy WhatsApp group. By the end she knew which promises mattered to shop owners, which ones she had only imagined, and she had money coming in. The software she finally built was a quarter of what she first sketched, and it was the correct quarter.

Give yourself a deadline that scares you a little. Three to four weeks to something a real person can pay for. A short deadline does the cutting for you. When you only have three weeks, you stop arguing with yourself about dark mode.

Then put it in front of people before you feel ready, because you will not feel ready. The first version will be smaller and rougher than the one in your head, and it will teach you more in a week of use than another three months of building ever would. Putting it in front of someone is the only honest feedback you get. Everything before that is a guess.

I know how this lands when you have poured yourself into something. Cutting features can feel like abandoning the vision. In practice it protects the vision, because the vision only survives if it meets reality early enough to still bend. The founders who win here are usually not the ones who built the most. They are the ones who learned the fastest, and you learn fastest when the thing in front of a customer is small enough to change on a Tuesday.

If there is a product on your laptop that has been "almost ready" for months, take this as your permission to stop adding and start shipping. Find the one path. Cut everything else. Put it in front of one real person before the week is out.

And if you want people to pressure-test it with, that is a lot of what happens at Hackhouse. The founders here will gladly tell you which three features to delete before you lose another month to them. Come pull up a chair.

Build the small thing, put it in someone's hands, and let what they do with it decide what comes next.