Your dev team spends more time updating frameworks than building features. And you can’t figure out why.
I myself have a love-hate relationship with frameworks.
Love: They give you structure, tools, speed. You can push products out fast.
Hate: Companies now spend more time managing frameworks than building value.
Pains I see and live:
- We need to upgrade [framework] before we can add that feature
- Framework X just deprecated our auth library
- This working code needs rewriting because the framework version is EOL
- Our framework is now obsolete because the interpreter is EOL
The problem? Frameworks evolve constantly. Versions become obsolete. Security updates stop.
Meanwhile, your product needs to last 5 or 10 years. Not 12 months.
Teams build products on frameworks that move faster than the business can sustain.
The technology underneath (the language itself) is stable. Languages from 20+ years ago still work fine today.
But frameworks? They’re the showstopper.
Here’s the thing: Java and C# – whatever your opinion on them – give you enormous long-term stability.
It’s cool to add new features constantly. But when businesses invest 100K+ EUR in a codebase, they want stability, not a rewrite every 2 years.
And no – AI won’t just “rewrite everything.” That’s bullshit. You don’t kill the cow that’s making money.
When selecting technology for a product that needs to last, ask:
- Does this framework have LTS (Long-Term Support)?
- Can I upgrade incrementally, or is it all-or-nothing?
- What’s the maintenance burden in 3 years?
- How much am I binding my business to this framework’s roadmap?
Choose technologies that:
- Bind you the least
- Give you a boost without creating dependency
- Let you spend time with customers, not housekeeping
The framework that helps you ship fast today might be the framework that stops you from shipping at all in 2 years. Been there, cried it through.
How much of your dev budget goes to framework maintenance vs. actual features? That’s a proper horror-story…
In the end be ready for one thing: you will still have to pick a trade-off as your solution.
