Building instead of selling is the most convincing procrastination a founder has, because it leaves something real behind. You add a feature, the app is genuinely better, and you feel like you worked. But if nobody has used the last five things you built, the sixth one is not product work.
It is avoidance with a commit history. The honest signal that you are doing this is simple: you keep improving a product almost no one has seen.
Should I add features or get customers
If you have to ask, you already know. The tell is not the question, it is your reflex when outreach gets uncomfortable. The feature request feels urgent, the roadmap feels behind, and building the next thing feels like the responsible move. None of that is about the customer.
It is about you being more comfortable in the editor than in someone's inbox.
Here is the plain version. Before real people have used what you have, more features cannot tell you anything. You are adding answers to questions nobody has asked yet. The only information that matters early comes from someone outside your own head touching the thing and either staying or leaving.
Until that happens, every feature is a guess stacked on a guess.
How do I tell build-avoidance from real product work
Real product work is downstream of a person. Someone used the product, hit a wall, told you or showed you through their behaviour, and you are fixing that specific wall. Build-avoidance is upstream of imaginary people. You picture a user who would want this, and you build for them.
The difference is whether you can name who the feature is for and point to the moment they needed it. If the answer is a hypothetical ("a user might want to export to CSV"), it is a guess.
If the answer is concrete ("three of the seven people who tried it asked for CSV in the same week"), it is work. Seven people is enough to act on. Zero people is not a smaller version of seven. It is a different category, and no amount of building changes that.
A feature nobody asked for is not progress. It is a bet placed before anyone showed up to the table.
Feature creep when you have no users
Feature creep with users is a discipline problem. Feature creep with no users is a hiding problem, and it is worse, because it feels like the opposite of hiding. You are producing. The repo is busy. The changelog is long.
And the whole time, the actual bottleneck, getting a stranger to look at the thing, sits untouched because it is the one task that offers no code to write and no clean sense of completion.
I have refactored a settings page to avoid sending five messages. The messages would have taught me something. The settings page taught me nothing except that I am good at avoiding messages.
If you have ever reorganised your database schema on a day you promised yourself you would do outreach, you know exactly the feeling, and you know it is not virtue.
Stop building, start selling: the rule that actually holds
Willpower will not fix this, because building genuinely feels good and selling genuinely feels bad. You need a rule that removes the decision, so here is the one I use. It has one moving part on purpose.
No new feature until N of the right people have seen the current one.
That is the whole rule. The mechanics around it:
- Pick N and the person. Small and real. Something like "twenty solo founders who run their own outbound." Not a market, a person you can picture. If you cannot picture them, you cannot count them.
- "Seen it" means used it, not visited it. A pageview is not a person. Signed up, clicked around, or watched you walk them through it. That is a seen.
- The feature you have is frozen until you hit N. Bugs that block use are fair game. Polish, new surface area, the thing you are itching to build, all locked.
- When you hit N, you read what happened before you build. What did they do, where did they stall, what did they ask for twice. Now you have a queue that came from outside your head.
- Then, and only then, you build the top item. And the counter resets. The next feature waits for the next N.
The rule works because it makes the uncomfortable task the only unlocked task. You want to build, and the single path back to building runs straight through the outreach you have been avoiding. It stops being a willpower fight and becomes a gate.
Where a tool fits, and where it does not
You can run this rule today with nothing but a spreadsheet and your own inbox, and you should, at least until getting people to see the thing is the only step still breaking. If your problem is that you keep building instead of shipping, no software fixes that. The gate above is free, and it is the whole fix.
The one place a tool earns its keep is step two, where "seen it" has to mean N real people actually looked. By hand that does not scale. A genuine walkthrough for one person is ten minutes, and twenty of them is your whole week, so it quietly rots into a generic blast nobody watches.
That is the wall I built Personade for, which makes it, yes, one more thing I built instead of selling. The difference is that it exists to push you back to sending.
You record one demo, each lead gets their own version with an opening line meant only for them, and you get the single number the rule is asking for: who opened it, who played it, how far they watched. That is the "seen it" signal, counted for you.
What it will not do is write the outreach, choose your N, or turn a product nobody wants into one people do. Those parts stay with you.
If you want the fuller version of why this shift happened, I wrote about why building got free and selling didn't, and if the deeper problem is that you skipped distribution entirely, start there instead.
Common questions
Should I add more features or focus on getting customers? Get customers first, almost always. A feature only teaches you something after real people have used the product and shown you where it breaks. With no users, a new feature is a guess with nothing to check it against. Set a rule you can enforce: no new feature until a set number of the right people have actually used the current one.
How do I know if I am building to avoid selling? Ask two questions about the feature. Who is it for, and when did they hit the wall it fixes. If you can name real people and the exact moment, it is product work. If the user is hypothetical and the timing is "someday," it is avoidance. Busy repos and long changelogs feel like progress but measure nothing while nobody has seen the product.
What is a good rule to stop feature creep with no users? Freeze the product until a fixed number of the right people have used what you already built. Pick something small and real, like twenty. "Used it" means they signed up and clicked around, not that they visited a page. Only after you hit the number do you read what they did and build the top request. Then the counter resets and you start again.
The features you are proud of are invisible to everyone but you until someone outside your head has reason to touch them. That is not a building problem, and you already solved the building problem.
It is the one task with no clean sense of completion, which is exactly why it keeps losing to the one that does. Put the gate in front of yourself this week and let it decide.