Killing the Child
On the features that are expensive to keep and harder to cut
I write this newsletter to share my learnings about founder-led growth and bootstrapping, gained from my past 10 years of building AI startups and my current journey with MadScript. AI is pushing the cost of building products and launching startups down toward zero. What's left is authentic POV, based on lived experiences, shared compellingly.
The feature we were proud of
We had a feature in our first company that took a full screenshot of a client's website every five minutes.
If you were a news editor at Forbes, you could go back to any point in time and see exactly what the homepage looked like. Not just the metrics, the actual page, visually, with the performance data layered on top of it. You could go to January 5th at noon and see what was running and how it performed in the hours after it was published. It was a genuinely cool piece of engineering.
It also consumed about ten percent of our infrastructure budget. The processing power to spin up something that frequently, take the screenshots, store the data, keep it forever, was expensive in a way that was hard to justify as the company grew.
Two clients used it. Maybe three on a good month.
Why it took so long to kill
We knew the analytics. We could see the usage numbers. We had the conversations about infrastructure costs. None of that made the decision easy.
I think features feel like children to founders in a way that's hard to explain to anyone who hasn't built something from scratch. This particular feature had been hard to build. We were proud of it. There were two clients who genuinely loved it, who had integrated it into how they worked, and who would be frustrated if it went away. Cutting it felt like telling those clients their workflow didn't matter, even though that wasn't what we meant at all.
I know the framework. Sunk cost fallacy. I can explain it cold. Knowing it didn't make the conversation easier. The internal debate went on longer than it should have, and part of that was just that we were proud of the feature and didn't want to admit that pride was part of what was holding us back.
How we actually made it happen
We didn't kill it all at once. We started by de-emphasizing it in the interface, putting it a few clicks deeper than it had been. Then we watched the usage data for a while longer. Then we gave the clients who were using it a long notice window, long enough that it didn't feel like we were pulling the rug out, and we had real conversations with them about why we were making the decision.
That process helped. Giving people time and a real explanation is different from just removing something. The decision is the same either way, but how you do it matters.
Eventually we cut it. The infrastructure costs came down. Nothing broke. The clients who had been using it were frustrated for a bit and then mostly moved on.
What this reveals about the middle stage
Early on, when you have no users and no paying clients, these decisions are much easier. You're only accountable to yourself and your co-founder. You can kill something in an afternoon and rebuild it differently by the end of the week.
Once you have paying clients and a team that built the thing, that changes. It's harder. The internal debate goes longer than it should. And I think the honest thing is to just acknowledge that, knowing the framework doesn't make it easy. You still have to work through it, be honest about what's making it hard, and actually make the call.
We got there eventually. It took longer than it should have. I think that's probably normal.