Do we refactor the code that's getting messy? Or do we ship the feature customers are requesting? Do we fix the architecture that's becoming a liability? Or do we add the integration that could close deals, but adds complexity? This is my eternal struggle at appointmed.
It’s also a constant point of discussion within the team. The developers want time to clean up the mess. The business side wants to ship what customers are asking for.
Nobody's wrong. That's what makes it hard.
Every new feature is a promise. A promise to maintain it, support it, keep it working as everything else evolves around it. Features are easy to add. They're incredibly hard to remove. And every single one, no matter how small, adds complexity. More code to maintain. More edge cases. More potential failures. Harder onboarding.
But customers don't see any of this. They see features. And they assume more is always better.
Meanwhile, all the work that keeps the system healthy is invisible. We just spent months refactoring our invoicing system. Zero visible changes. The workflow looks exactly the same. Nobody will notice, but it was absolutely necessary.
I used to think this tension was a sign I was doing something wrong. That with better planning, it would go away. Truth is: It doesn't go away. And it shouldn't.
If we only cared about features, there would be no tension. Ship, ship, ship. If we only cared about perfect code, there would be no tension either. Refactor endlessly, never ship.
The tension is the balance. What's right for the product today versus what's right in three years. Some months, we focus on features. Other months, we invest in the foundation.
You simply get better at living with the struggle.
