The feature I deleted after shipping it
In 2021 I spent about six weeks building a discussion forum into Egxam. Threads, replies, moderation tools, notifications, the lot. It shipped, it worked, and roughly forty people used it. Nine months later I deleted it.
The deletion is the part I think about. Not because the feature was a bad idea in the abstract, but because at no point before building it had I written down what would have to be true for it to be worth six weeks. If I had, the answer would have been something like "several hundred students posting weekly", and I'd have known within a fortnight of launch that it wasn't going to happen. Instead I let it sit there for most of a year, because deleting something you built is a different kind of decision from not building it, and much harder.
That's the thing running a company teaches you that reviewing tickets doesn't. The cost of a feature is not the six weeks. It's the six weeks plus every subsequent month of maintenance, plus the support burden, plus the space it takes up in a UI that other things now have to work around, plus whatever you didn't build instead. Engineers are quite good at estimating the first term and tend not to price the rest at all.
I catch myself now asking a question in planning that used to annoy me when other people asked it: what happens if we don't do this? Not as a challenge. It's genuinely useful information. Sometimes the answer is that a client walks, or a compliance deadline passes, and then the conversation is over and we build it. Often the answer is a shrug, and a shrug is data.
The trap on the other side is treating this as an argument for always taking the cheap option, which it isn't. I've made that mistake too.
On a school ERP I once argued successfully for a quick fix to a fee-collection edge case rather than reworking how the module handled part payments. It was the right call on effort. It was the wrong call on everything else, because fee collection is the module the school's accounts team lives in during admission season, and the quick fix meant they had to remember a workaround. Which they did, for a while, and then a new person joined and didn't. The cost landed months later on someone I never met, and it landed as a phone call to support at the worst possible time of year.
The useful distinction isn't cheap versus thorough. It's whether the thing you're building sits on a path somebody walks every day. A rough edge on a feature used once a quarter by an administrator is a rough edge. A rough edge in the daily path is a tax, collected forever, from people who don't get a say.
The other thing founding a company changes is how you hear the word "requirement". When the person asking for a feature is a client, or a stakeholder, or a sales lead, the temptation is to treat the request as a specification and get on with it. What they've actually given you is a solution they've already designed in their head, and the problem behind it is usually still unstated.
I've had a request for an export button turn out to be someone reconciling two systems manually every morning, where the real answer was a scheduled job neither of us had discussed. I've also had requests where digging for the underlying problem was a waste of everyone's time and the client just wanted the button. Knowing which is which is mostly a matter of asking what they'll do with it, once, and listening to whether the answer has a person and a time of day in it.
None of this makes the estimates better. I'm as bad at estimating as I ever was. It changes what gets estimated, which turns out to matter more.
The forum, incidentally, was replaced by a WhatsApp group that one of our teachers set up on her own initiative. It has more activity than the forum ever did, cost nothing, and I have no control over it whatsoever. I've made my peace with that.