To Build or Not to Build
A condensed version of an article originally published on Medium in July 2024.
A founder in a Discord channel for an Accelerator programme asked the question every early-stage team eventually runs into:
“As a seed / pre-seed stage founder how does one balance priorities between a feature that will acquire more customers vs a feature that a particular customer asked for.”
At that stage, having a customer at all is a big deal. If the revenue potential is high enough, the temptation to drop everything and build that one feature is difficult to resist.
This only applies once you already have a clear problem statement, a working MVP, and an actual conversation with the customer behind the request. Skip any of those and the question is moot.
Two Forks, No GPS
Picture a long hike that splits into two forks. No signage, a dead phone, and a GPS that stopped working an hour ago. Take the wrong one and there’s no guarantee where you end up. Maybe a long, wasteful loop back to the trail. Maybe genuinely lost.
Entrepreneurship works the same way, minus the signage that hiking has mostly solved with apps and tracking. The destination is growth and revenue. The supplies are your runway money. The wrong fork is a product that drifts from the original problem, or one that eats far more time and money than it should have. Lost in the wilderness is running out of runway. Exhausted is pouring in the effort and having nothing left to show for it.
There’s no map for any of this. But there are questions worth asking before picking a fork.
The Questions Nobody Asks First
For a feature a specific customer is asking for:
- Is this a blocker to getting value from the product, or a nice-to-have?
- How much revenue does this customer actually represent?
- Would you lose them without it, contractually, not just emotionally?
- Are they willing to pay for it?
- Does it hold value for other customers beyond this one?
For a feature meant to win new customers:
- Is there research or data behind this, or just a gut feeling?
- What’s the realistic upside over the next six to twelve months?
- Does it help close deals already in the pipeline?
Founder’s Wishes
Sometimes a feature gets built because a founder is convinced, and no counter-argument moves them. The usual defence is a Steve Jobs line, frequently misquoted into service: “How does somebody know what they want if they have never even seen it?”
There’s a fine line between visionary and stubborn, and usually only time tells which side you were on. If you’re the founder: sit with it, get outside feedback, talk to mentors, before asking your team to believe. If you’re not the founder: don’t quote that line back at them. Ask the questions above instead, and let the founder arrive at the answer themselves.
My Own Frankenstein’s Monster
Early in my career, a product built for one team’s specific, exceptional workflow got extended, team by team, screen by screen, into something the original architecture was never designed to hold. Eventually the business funded a full rewrite: three times the original team size, roughly two months of work, and a long stretch where the business users got nothing new while it happened. A couple of years after I’d moved on, I heard the whole system had been decommissioned. It had become unmaintainable. Again!!!
That’s the real cost of skipping the introspection, just a slow accumulation of features nobody uses. Each one a little vestigial organ. Eventually the accumulated vestigies come in the way of actually moving forward with a name : Techinical Debt.
Take Away
The honest answer to the Discord question is another question: is this feature of value to all your current and future customers, not just the one asking?
If that’s an obvious yes, build it. The introspection above is still worth doing, but don’t let it become an excuse to stall. If it isn’t obvious, that’s the signal to slow down before the fork, not after.
The full article covers the complete hiking analogy, the full question set, and the Ulysses/Frankenstein detours that didn’t make the cut here.
If you are building something that matters and want a senior software architect in the room, let's talk.
