The part nobody
ever sees.
This is where most of a system’s complexity lives and where almost every outage starts. A good backend is never noticed; only its absence is, usually on a busy day.
02 — What we build
Data that arrives where it should — and says so when it does not.
Everything under the interface: what holds the data, what moves it between systems, and what happens when the other system does not answer.
- APIs and services
- REST and GraphQL written to be consumed by someone else: documented, with errors that explain themselves, and versioned so a change on our side does not break an integration on yours.
- Databases
- PostgreSQL and MySQL schemas designed before the code rather than fitted around it. Indexed where queries actually run, with migrations that can be reversed.
- Third-party integrations
- Payments, invoicing, couriers, identity, ERP, the accounting software you already pay for. Including the ones with outdated documentation, or none at all.
- Automation
- The repetitive work done by hand today, moved into scheduled jobs: reports, syncs, imports and exports. With a log, so anyone can see what ran and what came out.
- Data migrations
- Moving from an old system to a new one, with reconciliation before and after. Records that do not match get reported, not quietly dropped.
What we useJava · Spring Boot · Node.js · Python · PostgreSQL · MySQL · REST · GraphQL
03 — When this is the problem
Signs this is where it hurts.
- Two systems that should talk do not, and somebody retypes data between them.
- Orders or invoices occasionally go missing and nobody can say where.
- Every API change breaks something elsewhere, so nothing gets changed any more.
- The month-end report is assembled by hand from three sources that disagree.
- The database has grown and nobody on the team is sure what is in it.
04 — How we work
What we handle that usually gets skipped.
What happens when the other system goes quiet
Every integration depends on a service that will be down one day. Retries, backoff, and requests that do not execute twice if they arrive twice — handled from the start, not after the first incident.
Reversible migrations
Every schema change ships with its way back written at the same time. A deploy that cannot be undone is a deploy that gets postponed, and postponements accumulate.
A written trail for every request
Logs you can reconstruct behaviour from. When a customer asks why their order never arrived, the answer is looked up rather than guessed.
Sensitive data treated as such
What must not appear in logs does not. Access is granted by role, secrets live outside the code, and personal data is collected only to the extent the system needs it.
05 — Common questions
What people ask about this part.
Can you work on a backend someone else wrote?
Yes. The first stage is a read of the code and the database, which produces a written list of what is solid, what is risky and what should be touched first. Most of the time the work continues inside what exists; a full rewrite is rarely the right answer and never the first one proposed.
The system we need to integrate with has no documentation. Is that workable?
Usually yes, with one extra stage. We start from what can be observed — real requests, real responses — and write the missing documentation as it is discovered. It is slower than integrating with a well-documented service, and we say so in the quote rather than along the way.
How do you handle personal data?
Only what the system needs is collected, it is kept for as long as it is useful, and it stays out of the logs. Where it makes sense, data is separated so a component that does not need a person’s name never receives it. This is not a compliance checklist ticked at the end; it is how the schema gets designed.
What happens to existing integrations when the API changes?
They keep working. The old version runs alongside the new one for an announced period, so whoever integrates with you has time to move. Breaking changes without notice are the reason many companies stop touching their API at all.
06 — The other capabilities
They rarely arrive one at a time.
Each one leans on the next: an app needs a backend, the backend needs somewhere to run, and whatever is already running needs someone to keep it alive. We take the whole chain, or just the link that is missing.
07 — Next step
Data going missing
somewhere in between?
Describe the route it takes and we will tell you where it breaks — often not where it looks like.