Every change drags three more along.
The technology is current, the team is good, and still every feature costs more than the one before. Whoever changes one place has to follow up in three others, because everything in your software is connected to everything else.
Does this sound familiar?
For a new feature several teams have to coordinate and wait for each other.
Estimates are never right, because only the implementation shows what else is attached.
Only one or two people still know how everything fits together, and nothing moves without them.
This is rarely about the age of the technology. Even an up-to-date application gets sluggish when its parts have no clear boundaries. In the beginning, direct access is the fastest way: the order quickly reads the customer data, the invoice reaches into the order. Every single shortcut is reasonable, together they form a mesh in which no part can change without touching others.
AI agents don't solve this, they speed it up. An agent follows the structure it finds. Where boundaries are missing, it takes the shortcut too, only far more often per day than a human. You get more code, but not more delivery. Where a module ends and what it may expose is a decision about your business, not about code. That is exactly the decision you cannot delegate.
What waiting costs you every month
These costs don't grow evenly, they rise with every feature. What took a week in the first year takes a month in the third, with the same team. Anyone new to the team needs months before they dare to make a change. And if the one person who oversees the system is away, development stops.
Then there is what you don't get: AI tools that noticeably speed up others hardly help you. Every generated change has to be checked by hand against the whole system, because nobody can say for sure what else it touches.
How I approach it
Make dependencies visible
AI agents search the entire codebase and map which part accesses which, in days instead of weeks. I assess the map with your team: where do the boundaries of your business run, and where does the code violate them? You get a picture of your software that is understandable without technical knowledge.
Draw boundaries step by step
I define which modules exist and through which interfaces they talk to each other. Then connection after connection is rebuilt, starting where it slows your team down the most. Agents do the rebuilding according to my guidelines, I review every change. Your product stays deliverable at all times.
Enforce the rules
Automated architecture tests in the pipeline reject every change that violates a boundary, whether it comes from a human or from an agent. The most important decisions are documented briefly, so your team and its AI tools know why the boundaries are where they are.
Classic architecture tasks I take on
Documentation with arc42
Context, building blocks, runtime and deployment view, plus diagrams following the C4 model. Short enough to be maintained, and in the repository next to the code, so your team and its AI agents actually read it. Agents write the first draft from the code, I review it and add what is not in the code.
Recording architecture decisions
Architecture Decision Records (ADRs) capture in a few paragraphs what was decided, which alternatives existed and why they were rejected. Nobody has to guess in two years, and an agent knows which solution not to suggest.
Quality goals and scenarios
Maintainability, performance, security, availability: not everything matters equally. Together with you I clarify which quality characteristics from ISO 25010 count for your product and describe them as testable scenarios instead of a wish list.
Architecture review
I evaluate an existing or planned architecture against these quality goals, based on ATAM. You get a list of risks, technical debt and trade-offs, sorted by impact and with concrete recommendations.
Domain boundaries with Domain-Driven Design
In workshops such as Event Storming I work out with your domain experts which areas your business has and how they relate. The result is bounded contexts and a context map, the boundaries that modules and teams later align with.
Interfaces and technology selection
I design interfaces between modules and systems as verified contracts, for example with OpenAPI, and assess frameworks, databases and services against your requirements instead of trends. Every recommendation is justified and documented as a decision.
Frequently asked questions
Do we have to rewrite everything?
No. A rewrite usually takes longer than planned and often inherits the same problems, because the boundaries are still unclear. I rebuild the existing software step by step, module by module, while it keeps running.
Do we need microservices then?
Usually not. Clear boundaries can be drawn within a single application, which is cheaper to run and the better choice for most teams. Separate services only pay off when parts have to scale or ship independently. Spreading tangled code across several services leaves you with the same knots and a network in between.
Can we keep developing features in the meantime?
Yes. The rebuild runs alongside day-to-day work. I start with the parts your next features depend on, so the work pays off right away.
When will we notice an effect?
The map of dependencies usually already shows spots that can be resolved quickly. I draw the first boundary where your team currently loses the most time. Once it is in place, changes in that part get easier, long before the whole rebuild is finished.
Does this only apply to the frontend?
No. Coupling doesn't stop at the line between frontend and backend, often it sits right in between: in interfaces that reveal too much, or in a database everyone accesses directly. I work on both sides, for example with TypeScript, Go and Rust.
Can't AI simply design the architecture itself?
It delivers a proposal in minutes, and it looks convincing. But it knows neither your business nor your teams, and it doesn't know which parts will change in two years and which never will. That is exactly what decides where a boundary makes sense. I use AI to find dependencies and to carry out the rebuild. Where the boundaries lie, I decide together with you, and I stand behind the result.
Let's talk about your situation
In a free initial call we take a look at your problem together. You get an honest assessment of whether and how I can help.
Related topics
Problem
Your frontend slows down every new feature
Code that grew over years, outdated frameworks and nobody dares to touch it anymore. I modernize step by step while your product keeps running.
Problem
Before every release someone clicks through everything
Test rounds that take days, bugs that come back and releases that slip. I automate your tests so you can ship more often and more safely.