Backend & APIs
This may or may not be how your current setup looks.
It’s okay. We’ve seen it all.
Scroll down and we’ll fix it, one part at a time.
Backend & APIs
Here’s how we’d fix it.
One part at a time, in the order we’d really do it. We agree the API contract with you before we write the code behind it, and your system keeps running the whole way through.
The API gateway
Your APIs are what attackers go after now.
87% of organisations reported at least one API-related security incident in the past twelve months, up from 76% in 2022. Broken authentication was behind more than half of the publicly disclosed API breaches of 2025. The cause people name most often is API sprawl: more endpoints than anyone is keeping track of.
What’s going wrongThere’s no single way in. Some endpoints were never listed, old versions are still answering, and authorisation is checked once at the edge but not for each object a request touches.
Figures fromAkamai, 2026
The fix
Agree the contract first.
We design authentication and authorisation into the contract before the first endpoint exists. We keep an inventory of every API you expose. And we add contract tests that fail the build when the shape of an API changes.
We start with working sessions with the people who own the system: the business owner, the product lead and the engineers who are on call for it today.
- This isn’t requirements capture. We look at the business case for the software as a whole, together: what it has to do, who it’s for, what load it takes and which rules it has to follow.
- What comes out is a model of the problem (domain, data, integrations, failure modes) and a shape for the solution: the architecture, the migration order and the scope.
- It’s contract-first, so the API and the schema are reviewed before the code. We write the contract as OpenAPI and review it the same way we review code.
Further readingOWASP API Security Top 10, 2023 (API1 object-level authorisation, API9 inventory)
The delivery pipeline
AI made your teams faster and your releases less stable.
The 2025 DORA report finds that AI adoption now raises throughput but still lowers delivery stability, with more change failures and more rework. Whether AI pays off at all comes down to the quality of the platform it’s used on.
What’s going wrongChanges arrive faster than anyone can verify them. DORA’s finding is that AI amplifies whatever it lands in: a strong delivery platform gets faster, and a weak one gets less stable.
Figures fromDORA, 2025
The fix
Test it with the people who’ll call it.
We build a delivery platform that keeps up with the code: small reviewed changes, CI that runs the contract tests, and migrations that roll forward and back. Those guardrails are what let a faster team stay a safe one.
Both sides have to agree that the shape is the best answer. We don’t build anything until they do.
- We generate a mock from the contract, so the teams who’ll call the API can start before it exists.
- What they expect from it becomes contract tests. Those run in CI from then on, and they fail the build when the shape changes.
Further readingDORA, State of AI-assisted Software Development, 2025Ian Robinson, Consumer-Driven Contracts
The database
Your board knows what an hour of downtime costs.
Nine in ten mid-size and large enterprises put an hour of downtime above $300,000, and one in five outages now costs more than $1 million. The people who get paged at night are also the people you can least afford to lose.
What’s going wrongOne database, one copy, and nobody has agreed how reliable it needs to be. It’s a single point of failure, and nobody measures it until the day it fails.
Figures fromITIC; Uptime Institute 2026
The fix
Build behind the contract.
We design for 99.95% availability and run migrations without a maintenance window. Tracing, SLOs and alerts go in before features, so a three-in-the-morning call is rare, and short when it does happen.
Senior engineers build to that shape. Only senior engineers.
- Small reviewed changes, continuous integration, and a commit history you can read to see why each thing changed.
- Documentation is a first-class deliverable: decision records, runbooks, on-call notes, and onboarding that a new engineer can follow on day one.
- Tracing, SLOs and alerts go in before the first feature.
Further readingGoogle SRE, Service Level Objectives and the four golden signalsAWS Well-Architected, Reliability Pillar: designing for 99.95%
The legacy core
The rewrite that never ships.
Seven in ten legacy modernisation programmes run 30% or more over budget. Gartner expects more than 70% of mainframe exit projects to fail because they over-estimate what generative AI can do for them. Big-bang rewrites usually fail. Incremental migrations mostly don’t.
What’s going wrongA big-bang rewrite is planned, but the legacy core still shares its database with everything new. Nothing can move unless everything moves at once.
Figures fromGartner, via Hashbyt
The fix
Change it without breaking it.
We modernise strangler-style. The old system keeps running while we move it across one slice at a time, and each slice is live and measured before we start the next. There’s no feature freeze and no cutover weekend.
We write the codebase so your team can run it and extend it without m.a.d labs, whenever you choose to.
- Versions are additive. A new field or resource never breaks a client that’s already using the API.
- Migrations expand before they contract, and they roll forward and back without a maintenance window.
- Old systems are strangled slice by slice behind the contract. Each slice is live and measured, and nothing is ever cut over on a weekend.
Further readingMartin Fowler, Strangler FigAzure Architecture Center, Anti-corruption LayerMartin Fowler, Parallel Change (expand and contract)
Between your systems
Everything is connected, except your systems.
The average organisation now runs around 957 applications, and only 27% of them are connected. Two in three integration projects are delayed by months because there aren’t enough people to do them, so the product roadmap sits waiting behind the integration backlog.
What’s going wrongEvery system is wired directly to every other one. With n systems that’s up to n(n−1)/2 connections, and nobody owns any of them.
Figures fromMuleSoft 2026 benchmark
The fix
Connect each system once.
We stop wiring systems to each other one pair at a time and put one integration layer in the middle. It uses contract-first APIs, and events where events fit, so the next system plugs into something that’s already there.
Further readingGregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Backend & APIs
Same system, five fixes later.
Nothing was switched off to get here. This is how it runs now, and what we hand to your team when we leave.
How it’s running
Payments API, contract-first
- Throughput
- 14k req/ssteady
- Latency, p99
- 42 mswithin budget
- Maintenance windows
- 0none needed
- Last migration
- zero downtimerolled forward
Handover
What we hand over
- OpenAPI contracts with generated clients and contract tests in CI
- A Postgres schema with reviewed, reversible migrations and a zero-downtime deploy path
- One integration layer, event-driven where that’s the right shape
- Tracing, SLOs and alerting that your team owns
- Decision records and runbooks, in a repository that’s 100% yours
- Your own team, able to run it at three in the morning without us
APIs, databases and integrations designed to be boring at three in the morning.
Backend consultancy. API design, contract-first, OpenAPI, Postgres, schema design, event-driven integration, Kafka, observability, SLOs, zero-downtime migration, legacy modernisation, strangler pattern, API security, Node, Go, .NET, senior engineers, documentation, handover.
Services: API design & contracts, Postgres & schema design, Event-driven integration, Observability & SLOs.
Stack: Node, Go, .NET, Postgres, Redis, Kafka, OpenAPI.