galenry.Systems you can still change eighteen months in
Most systems don’t fail on launch day. They fail eighteen months in, when a change in one place breaks something nobody connected to it. We draw the boundaries first, and write down why they are where they are.
The shape of the work
Agreed before we start. You own everything we produce, whether or not you continue with us.
- Starts with
- Architecture review
- You get
- Target design + migration path
You are probably here because of one of these. Each one points to where we’d start.
- 01
What you are seeing
A release that needs four teams in the same room
The question it raises
Can we change this without a coordinated release across four teams?
Where we’d start
- Clear boundaries between the parts of the system
- 02
What you are seeing
A database every service reaches into directly
The question it raises
How do we get off the old system without stopping feature work?
Where we’d start
- Replacing the old system one route at a time
- 03
What you are seeing
Reports that slow down the product when they run
The question it raises
Where will this break first when volume doubles?
Where we’d start
- Separate copies for search and reporting
- 04
What you are seeing
Nobody left who knows why a core decision was made
The question it raises
Why was it built this way, and does that reason still hold?
Where we’d start
- Decisions written down in the repo
None of these sound right? Tell us what is actually happening.
Describe the problemThe decisions that are expensive to reverse. Not all four land in every engagement.
Clear boundaries between parts
Each part owns its data, and others reach it through an agreed interface. No reaching into another team’s tables, the habit that makes a system impossible to change.
Moving off the old system in steps
The old system is replaced one route at a time behind a router, so every step can be reversed and the business keeps running.
Reports that can’t slow the product
One source of truth, with separate copies shaped for search and reporting, so a heavy report can’t slow down checkout.
Decisions written down
A short record in the repo of what we chose, what we rejected and what would make us revisit it. The next team inherits the reasoning along with the code.
How the engagement runs. The shape holds; the depth of each phase moves with the problem.
Review
We map what exists: the services, who owns which data and the paths that carry real load, and find where the tangles are actually slowing delivery.
You get
Map of today + risks
Design the target
The design we are aiming at, with boundaries around the things that change together and the trade-offs stated plainly.
You get
Target design + decision records
Plan the route
An ordered migration where each step ships on its own and can be reversed. No stop-the-world rewrite.
You get
Step-by-step migration plan
Build the first parts
We build the first parts with your team, so the people who will extend the pattern understand it.
You get
First services + working pattern
What we can point at. Including where we cannot.
Excel sheets replaced by one system at a live food business
Dayone: a kitchen, a wholesale bakery round and a café now run on one system that carries each order through production, stock and dispatch.
See itWe have not yet delivered a large-scale enterprise migration
Said plainly because it is the first thing an enterprise buyer should ask. Our architecture work to date is at platform rather than programme scale.
Review first, commitment second
For work at a scale we have not done before, we start with a paid architecture review. You get the design and can take it elsewhere.
What we reach for first. Not the only things we work with, and we change them when there is a reason.
Runtime
Ordinary, well-supported choices, so the system is not tied to one team’s favourite.
- Node
- Python
- Containers
Data
One source of truth, with separate copies shaped for search and reporting.
- Postgres
- Event streams
- Reporting copies
Contracts
Parts talk through published agreements, so one can change without breaking another.
- OpenAPI
- Typed clients
- Versioning
Practice
Decisions written down and load tested, so nobody has to guess later.
- Decision records
- Load testing
- Migration plans
Tell us what you’re trying to build. We’ll tell you where we’d start.
Bring an idea, a stalled project, or a system that has outgrown itself.
Send us a brief
The problem, what you have tried, and what success looks like. A few lines is enough to start.
Prefer email? contact@galenry.com
What happens next
- 01Reply within one business dayFrom one of our engineers.
- 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
- 03An honest answerWhere we would start, or, if we are not the right team, who might be.