Why your developers say it is hard to change
A year after launch, the smallest change costs three times what it did at the start. That is not reluctance: it is an architecture decision made in month one.
6 min read
You had a tool built. For six months everything moved fast. Today, the smallest request comes back with a quote that surprises you and a timeline that irritates you.
What happened
Your business logic — who may do what, how a discount is calculated, when a reminder goes out — was written inside the screens. It is scattered across buttons, forms and queries.
With ten screens, that holds. With thirty, changing one rule means finding it in seventeen places, and missing two.
What we do instead
We isolate business rules in a layer that knows nothing about the screen or the database. They are written once, tested on their own, and the screen only calls them.
The benefit is invisible at delivery. It shows up in month eighteen, when you ask for a change and it costs what it should cost.
Covered here
- architecture
- technical debt
- clean architecture