Bella Stone

We added 4 new software tools to our operations this year. Two became essential. Two completely disrupted our momentum.

Here is the honest breakdown of what we got wrong.

Tool 1 Async video messaging (Loom). Worked out. Replaced our daily 30-minute status syncs and helped devs debug 40% faster. Adopted naturally from the bottom up.

Tool 2 Enterprise project management platform. Did not work out. Abandoned in 60 days. Setting up custom workflows took weeks, and the team ended up spending more time updating status tags than doing actual work. Heavy, rigid, and completely wrong for our team size that was management's fault for forcing it top-down.

We built a collaborative annotation feature in January of last year. It took 6 weeks to build and shipped in March. We deprecated it this May. Here is the full lifecycle:

• Build time: 6 weeks (2 engineers, roughly $19,000 in salary)

• Maintenance: 14 months of bug fixes, roughly 4 hours per month

• Adoption: peaked at 340 monthly active users in month 4, declined to 88 by month 12

• Revenue attributable: $0. We could never tie a single upgrade or retention to it.

• Support tickets mentioning it: 61 over 14 months, mostly "how do I turn this off"

• Users who complained when we announced deprecation: 3

• Users who churned because of deprecation: 1

The feature never had a clear owner. It was built because a loud user asked for it in month 2. That user left in month 5.

We ran a 30-day sunset with data export. Total cost of the whole experiment, all in: roughly $23,000 and 14 months of a feature slot that could have been something else.

I spent two weeks building an elegant architecture for a problem users didn't care about. They just wanted an export button.

It worked beautifully. Nobody noticed.

How do you tell the difference between engineering you're doing for yourself and engineering that actually matters to the people using your product?