One change breaks three other places
A small fix in billing breaks reports and the mobile app. Modules read each other's tables and call each other's internals, so nobody can predict what a change will touch, and incidents cross service boundaries.
Explore
Consultancy · Architecture & cloud review
Architecture that keeps every change small and local
Good architecture did the same job before AI and it does it now: it keeps a system easy to maintain and easy to extend. Clear module boundaries, low coupling and explicit contracts mean a change stays where you made it, instead of breaking three other places. Senior engineers read your code, infrastructure, cost reports and monitoring next to the diagram, then write down where coupling costs you, what to fix first and what each fix costs. The cloud gets the same treatment: in one app with 30,000 users, most of the database bill was image transformations repeated for every user, and the fixes cut the Supabase bill by about three quarters.
- 130+People, remote across Poland
- 12 questionsIn our public AI readiness scorecard
- 5.0Clutch rating, 11 reviews
This is for you if changes got slow and risky
Every feature costs more than the last
Releases slow down, estimates grow and engineers avoid parts of the code. You want to know which dependencies cause it and how to cut them without stopping delivery.
Agents write code faster than you can review it
Your team uses Claude Code, Cursor or Copilot. Without clear boundaries, every agent change pulls in half the repository and review turns into guesswork.
The cloud bill or a migration needs scrutiny
Supabase, Vercel, AWS or the model provider doubled without anyone deciding that, or someone proposed a new cloud or a rewrite. You want the numbers before the decision.
What you get. A plan to cut coupling and cost
A map of boundaries and coupling
Modules, data ownership and dependencies, mapped from the code, the infrastructure and production signals, and compared with the diagram. We mark where modules share tables, call each other's internals or have to change together in every release.
Contracts that keep changes local
Where each boundary needs a public interface, a typed contract or an event, and the checks that keep other modules out. Your engineers, and their coding agents, can then change one area without reading the whole repository.
Where the cloud money goes
The bill tied to the workloads behind it. Repeated work, queries without indexes and model calls in a loop are the usual suspects.
Reliability, security and portability
How failures move between services, what is exposed that shouldn't be, and how much of the setup is tied to one provider. We check whether the infrastructure lives in code, in Terraform or Pulumi, or only in someone's console history.
Ranked findings with a cost to fix
Each finding with its evidence, how confident we are, the effort to fix it and the first move. Coupling findings say what it costs you today: which releases it slows and which changes it makes risky.
A staged path, without a rewrite
Prioritized changes in small releases with a rollback: draw one boundary, put a contract in front of it, move to the next. A migration plan only where the findings support one.
Tech stack. What we read and measure before we recommend
Reviews combine reading the code and its dependencies, load tests, cost reports and infrastructure code, against the frameworks cloud providers publish.
Tech stack
- Modular monolith
- Hexagonal architecture
- Domain-driven design
- Event-driven architecture
- Microservices
- OpenAPI
- Java
- Spring Boot
- .NET
- Node.js
- TypeScript
- Python
- Ruby on Rails
- PostgreSQL
- MongoDB
- AWS
- Azure
- Google Cloud
- Supabase
- Vercel
- Cloudflare
- Terraform
- Pulumi
- Kubernetes
- AWS Well-Architected
- OpenTelemetry
- Grafana
- Datadog
- k6
- AWS Cost Explorer
How we work
Compare the diagram with the code and running behavior
We read the architecture material next to the code, the infrastructure configuration and the operational evidence. For coupling, we look at what changes together, who owns each table and which calls cross a boundary without a contract. For load, we check the same five things on every critical path: indexes that match the filters, bounded reads, short transactions, jobs that are safe when they arrive twice and connection pools budgeted across replicas. Any migration proposal explains how responsibility and recovery would work during the transition.
You want to build it stable enough so you can remove any piece without everything else falling apart. It’s way harder than it sounds.
How it works. From symptoms to structural options
Set the review questions
The decision the review has to inform (faster releases, fewer incidents, a smaller bill, a migration), its deadline and the access we need. NDA first if you want one.
Trace boundaries and coupling
Read access to the code, infrastructure code, cost reports, logs and dashboards, plus a few hours with the people who build and run the system. We find where one change spreads and why.
Compare improvement options
Targeted fixes, new boundaries and larger moves, each against its cost, risk and what it means to operate.
Agree a staged recommendation
Ranked findings and a sequence your team can implement in small steps, walked through with you. Fix it yourself, have us scope the work, or leave it.
Proof, not promises
PropTech · Platform
Rescuing a construction management platform after a failed first build
AI · FinTech
Taking over a crypto platform no one else could ship
Security · Government
Financial-crime investigation software for Poland's authorities
Questions about architecture, coupling and cloud
- No. We work in your repository, your cloud and the tools your team already uses. If one of them gets in the way of the work, we tell you what and why, and you decide.
- With a 30-minute scoping call. We look at what you have and what you need, then propose a first step with its scope and price before any work starts.
- Only if the numbers support it. Most of what we find can be fixed where you already are: repeated work, missing indexes, limits that hold for one user and give up with a team. When a move is justified, you get a staged path with its dependencies, transition risks and how you would roll back. When it isn't, the report says why, and records the tradeoffs of staying as well as moving.
- Read access to configuration, cost reports and monitoring, plus interviews, answers most questions. We don't change production during a review.
- For most products, a modular monolith first: one deployment, with modules that have clear boundaries and talk through contracts. You get low coupling without paying for a network between every piece. Microservices make sense when parts really need to scale, deploy or fail on their own. Splitting a tangled system into services gives you the same coupling, now over the network. On Signal Mesh we inherited about twenty Python microservices: we kept the ones that worked, put a Fastify API layer in front and replaced only what was broken or unsafe.
- One change breaks three places. Releases slow down because every change needs a wide round of testing. Engineers become afraid to touch parts of the code, and each new feature costs more than the last because it drags old dependencies along. The review names where this happens in your system and what it costs to cut.
- Usually, yes. We draw a boundary around one area, put a contract in front of it, move its rules behind that contract and keep other modules out with checks in the pipeline. Then the next area. Each step ships on its own and can be rolled back, so delivery keeps going while the structure improves.
- More than code written by hand. Agents change code fast, and in a tangled codebase they change it in the wrong places just as fast. A module with a clear boundary, a typed contract and tests gives the agent a smaller place to look and checks that can reject its work. We wrote about this in our brief Architecture is what the agent sees.
- Repeated work and missing indexes more often than a wrong provider. In a consumer app with 30,000 users, storing optimized images at upload and adding indexes cut the Supabase bill by about three quarters. On Signal Mesh, any logged-in user could read or delete all data; we locked that down before launch.
- Yes. The report includes the reasoning and the proposed sequence, written so another team could act on it. Implementation with us is a separately scoped engagement.
- It depends on the size of the system and the access available. We agree the scope and the schedule on the first call, and you get a price before the review starts.
How we think about this, in our own words
Interactive briefs and articles by our team, picked for this service
Architecture is what the agent sees
Ports, typed contracts, tests and pull request gates in a concrete Java/Spring and frontend example: what a good boundary looks like.
Read the briefWhy 10× isn't a constant
Why AI leverage decays as a codebase grows, from a field model built on 53 production projects.
Read the briefThe Most Expensive Decisions in IT Are the Ones Nobody Officially Makes
Why architecture problems often come from decisions everyone discussed for months and nobody officially made.
Read the articleBring the change that keeps breaking other things
A feature that touches too many places, a slow release, a cloud bill that keeps growing. Tell us what hurts and we will say where we would look first.
Direct contact
Mike KacprowiczBook a callChief Growth Officer