Backend Development
A backend is judged at three in the morning by somebody who did not build it. That is the standard we design to.
- Typical duration
- Four to twelve months
- Team shape
- Two to five senior engineers
- Starts with
- A data model review
The data model is the decision you cannot take back cheaply
Frameworks get replaced, services get rewritten, and interfaces get redesigned every few years. The shape of the data outlives all of it, and almost every expensive backend problem traces back to a modelling decision made in the first fortnight.
So that is where we start, and where we spend the argument. After that the work is unglamorous and largely about operability: explicit boundaries between services, migrations that can be run backwards, failures that say what failed, and enough instrumentation that the first question after an incident has an answer.
What usually goes wrong, and what we do instead
The pattern is consistent enough that we now check for it before writing anything.
Where backends become hard to operate
- A schema shaped around the first screen rather than the domain
- Business logic spread across the API, a job runner and a trigger
- Migrations that only go forwards, so a bad release cannot be undone
- Errors that log a stack trace and nothing about the request
- Integrations retried by hand because nothing is idempotent
How we build it instead
- The domain modelled first, and the API derived from it
- One place that owns each rule, with the others reading from it
- Every migration reversible, and the rollback tested before release
- Structured logs and traces carrying the request through the system
- Idempotent writes and explicit retry semantics on every integration
What we build
The parts of a backend that decide whether it can be handed over.
API design
REST or GraphQL with a versioning story, documented from the schema rather than beside it.
Data modelling
A schema shaped around the domain, with reversible migrations and constraints the database enforces.
Service boundaries
Explicit seams between services, so one can be replaced without an archaeology project first.
Jobs and workflows
Long-running and scheduled work that survives a restart and can be replayed after a failure.
Authentication and authorisation
One permission model, enforced at the data layer rather than repeated in every endpoint.
Observability
Structured logs, traces and alerts that point at a cause rather than at a symptom.
What you end up with
Stated from your side rather than ours.
A system your team can operate
Runbooks, dashboards and alerts that name the thing that broke, so an incident does not require the original author.
Releases you can undo
Every migration reversible and every rollback path tested before it ships, so a bad Tuesday stays a bad hour.
Integrations that stop paging you
Idempotent writes and explicit retries mean a partner's outage becomes a delay rather than a data-repair job.
A codebase that documents its decisions
The trade-off, the alternatives and the reason are written down as the work happens, so the next team does not relitigate them.
How the build runs
The same five stages as every engagement, applied to services and data.
Diagnose
The domain, the load it actually carries, and which of today's problems are modelling problems.
Decide
Data model, service boundaries and the consistency guarantees, written down with what each one costs.
Prove
One path through the system end to end in production, including its failure case and its rollback.
Deliver
Services built in slices, each one live and instrumented before the next is scoped.
Hand over
Your team runs it with us watching, then without us.
What we build it with
Chosen for what a system has to survive in operation, not for novelty.
Services
- Node.js
- TypeScript
- Java
- Spring Boot
- Python
- Go
Interfaces
- REST
- GraphQL
- Kafka
- Temporal
Data
- PostgreSQL
- MySQL
- MongoDB
- Redis
- Elasticsearch
- Row-level security
Platform
- AWS
- Docker
- Kubernetes
- Terraform
- Datadog
- Sentry
What you get, and when
Handed over as it is produced, not assembled at the end.
- A data model with its constraints and its trade-offs
- Service boundaries and the consistency guarantees at each one
- A written assessment of what today's schema makes expensive
- Source in repositories you own
- Infrastructure as code, in your accounts
- Reversible migrations with tested rollback paths
- API documentation generated from the schema
- Dashboards and alerts, with the runbook each one points to
- An on-call handover your team wrote with us
The rest of our web work
Most web engagements touch two or three of these. If you are not sure which, the consultation is the way in.
Where we have built this
Sectors where the system behind the interface carries the regulatory and operational weight.
Fintech & BFSI
Secure, reliable systems for businesses built on trust.
We build and modernize financial platforms, workflows, integrations, and customer-facing applications where reliability, data integrity, auditability, security, and performance are fundamental to the business.
Healthcare
Technology that connects complex care and operational workflows.
We help build digital healthcare platforms, operational workflows, integrations, and data-driven applications designed around reliability, secure information handling, usability, and the realities of interconnected healthcare systems.
HRMS
Workforce systems built around how organisations actually operate.
We build and improve workforce platforms spanning recruitment, onboarding, employee management, attendance, operational workflows, reporting, and integrations, reducing friction across the employee lifecycle.
Food & Travel
Digital experiences that keep customers and operations moving.
We build customer journeys and operational platforms around ordering, booking, marketplaces, partner integrations, administration, and real-time workflows where experience and operational efficiency need to work together.
Related work
Engagements where the system had to keep running while it changed.
Questions about backend work
The ones we are asked most often before a first conversation.
Should we be using microservices?
Can you work with our existing database?
Which language and framework will you use?
Will this handle our load?
Do you run the system for us afterwards?
What documentation do we actually get?
Building something that has to stay up?
Tell us what the system has to do and who will operate it. We will tell you what that means for the data model.