When to say no. Most features don't move the business. They just add cost.

The features we never built — and survived

The Kanban board is the cleanest example. The pressure was real: a competitor had it, sales said deals hinged on it, it showed beautifully in demos. But when we looked past the noise, there was never an overwhelming part of our customer base actually asking for it. It was mostly FOMO and conjecture. On top of that, we believed it wouldn't even be practical for our customers, who often managed large numbers of deals — a Kanban board becomes unusable at that scale. So we never built it, and nothing bad happened.

The other one I'd point to is ERP integration. Customers asked for it, and there was a real rationale — a hope that it would pull in larger industrial accounts. But the complexity was brutal: the endless variants of SAP, the antiquated APIs, the long tail of other ERP systems we'd have to support forever. It was impractical, so we said no. And here's the thing being bootstrapped teaches you that funded companies never learn: the constraint is the advantage. You can't build everything, so you're forced to choose wisely — to bet only on the work you're confident your current and future customers will actually value. That forced focus is a gift, not a limitation. It's the same instinct behind choosing to grow slowly on purpose.

The customers we turned down

Saying no to features is one thing; saying no to revenue in front of you is harder. We did it anyway, repeatedly. Healthcare prospects kept pulling us toward HIPAA compliance, and we said no — that wasn't our ICP, and chasing it would have reshaped the product around a customer we'd decided not to serve. Larger customers would ask for complicated custom features, and we rarely said yes, even at the cost of losing the deal.

I won't pretend we were pure about it. Early on, when we needed revenue, we made a handful of feature commitments to close deals — but I can count them on one hand across sixteen years. And even then we were disciplined about it: we usually didn't do the work for free. We did it for a fee, and in exchange for a longer contract term. If a custom request was worth saying yes to, it was worth attaching real money and real commitment to. A "no" protects your roadmap; a rare "yes" should always have a price.

The "yes" that taught us to say no

The most expensive lesson came from a yes, not a no. Early in our journey, we got excited and said: let's build a second product — a different SaaS app, solving a different problem, for a different ICP, in a different market. We built it in three months. Then we hired a new senior VP of Sales, and he looked at it and said, plainly, you're crazy. I can't train the sales team to sell one product to a VP of Sales and then turn around and train them to sell a completely different product to a VP of HR. It doesn't work. It won't scale. He was right. We killed it within weeks.

The lesson burned itself in: say no to additional products. It was unfocused, and it was a bad move. What it taught us, though, was where that energy should have gone — into building an add-on for the VP of Sales we were already selling to, solving more of the sales problems we already understood. Depth in your lane beats breadth across lanes, almost every time. (We applied the same logic to international and multi-language support, and said no there too — our fields could already capture data in the customer's native language, so the demand evaporated under scrutiny.)

Where restraint over-rotated: the nos I regret

Here's where I have to complicate my own sermon, because saying no isn't a virtue in every direction. My hardest nos in hindsight weren't the features we declined — they were the add-ons we never got creative enough to build. We weren't thinking hard enough about expansion. We arrived at a real good-better-best pricing model late, and for too long we had almost no way to grow an account beyond adding seats or bumping them to a higher plan.

If I could redo it, I'd have said yes to a handful of features and packaged them as paid add-ons — a de-duping service, extra security and backups, data enrichment. The reason those are different from the Kanban board is simple and important: they carry direct revenue. That's the cleaner filter for what deserves a yes. Expansion revenue is one of the most powerful levers a SaaS business has, and a feature with a price tag attached is far easier to justify than one you bundle in and hope moves a number. Say no to features that just add surface area. Say yes, more often than I did, to features customers will pay extra for.

How we actually decided

None of this was instinct alone. As a leadership team we decided where to invest deliberately: we reviewed our strategy and our differentiators every quarter, we read the voice-of-the-customer data, the feature feedback, and — maybe most usefully — the cancellation data, which tells you what people actually leave over versus what they merely complain about. Cost was always in the frame too: could we build something genuinely good enough in a reasonable amount of time, or would it limp along half-supported forever?

We said no to the team's pet projects, and we said no to some of our own. And I'll be honest — we also got it wrong in the other direction and said yes to our own pet projects when we shouldn't have. My "goals" project is the poster child there: a thing I wanted, that I convinced myself mattered, that didn't earn its place. Founders are not immune to the disease they're supposed to be curing. The discipline has to apply to your own ideas first.

The feature won't move the business — and your customer pays for it

If I could get founders to internalize one thing about product decisions, it's this. You will be blinded into believing a new feature is going to move the business in some meaningful way — more new sales, better retention, higher adoption. More often than not, it simply doesn't. Your customer already bought from you because you solved about 85% of their problem; the marginal feature rarely changes that calculus. And most product teams aren't disciplined enough to ever measure the impact of what they just shipped. They build it, declare victory, and move on to the next new thing.

And there's a cost almost nobody contemplates. Every feature carries an incremental cost to maintain — forever. But the bigger cost lands on the customer who never asked for it and now pays for it anyway: in confusion, in clutter, in the new complexity that creeps into the interface. A product that does one thing cleanly is worth more to the people using it than a product that does ten things, badly, because no one was willing to say no. That's the real discipline of not building. Say no by default. Reserve your yes for the work your customers will genuinely value — or better yet, pay extra for — and let the rest go. Being bootstrapped doesn't just permit that restraint. It demands it, and that's exactly why it works.