Backend & API Development Services
We build the part nobody sees and everything depends on. Data models, APIs, authentication, the jobs that run at three in the morning, and the integrations between systems that were never designed to talk to each other.
This is the work we are known for internally. A lot of what we do arrives as "the frontend is fine, the problem is underneath" — a product that works until it has real data in it, a reporting layer that disagrees with the system it reports on, an integration that someone built once and nobody has touched since.
We write backends to be handed over. Documented, tested, and structured so that the next developer can find their way around without an archaeology phase. That is not a courtesy. It is the difference between a backend you own and a backend that owns you.
What We Build
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
APIs
REST and GraphQL, designed before they are written. Versioning, consistent error handling, pagination that still works at a million rows, and documentation generated from the code rather than written beside it and left to drift.
-
Data modelling
The schema is the decision that is hardest to reverse. We spend real time here — relationships, constraints, indexing, and what happens when the shape of the business changes in two years. Most performance problems we are called in to fix are schema problems wearing a different hat.
-
Authentication and access control
OAuth 2.0 and JWT, session and token lifecycle, refresh handling, and role-based access where different kinds of user need different views of the same data. We have built a single account working across two separate mobile apps on one shared backend.
-
Integration between systems
The work that looks small in a brief and is never small. Payment providers, CRMs, ERPs, mapping and scheduling services, and in-house systems with no documentation and a contact who left. We build the translation layer, handle the failure cases the vendor’s docs do not mention, and make the whole thing observable so you can see what went wrong without guessing.
-
Background and scheduled work
Queues, workers, scheduled jobs, event-driven processing. Anything that has to happen reliably when nobody is watching, with retries that are safe to repeat and a record of what ran.
-
Performance and scaling
Query optimisation, caching strategy, connection pooling, and knowing which of those will actually help before changing anything. We profile first. Most backends do not need more servers; they need three queries fixed.
-
Mobile and frontend integration
Most of our backend work exists to serve something. We build with the client in mind — payload shapes that suit how the app actually renders, and offline-tolerant endpoints where the product needs them. See mobile app development.
When Teams
Come to Us
-
A strong frontend team and no backend depth
You have designers and frontend engineers and a product that now needs a real server behind it. We build it, and we build it so your team can read it.
-
One system has to talk to three others
The integration work nobody wants to own. We take it, including the parts where the other system is undocumented and behaves differently in production than in its sandbox.
-
It worked until there was real data in it
Pages that time out, reports that take minutes, a database that was fine at ten thousand rows and is not fine at ten million. We profile before we prescribe.
-
The data is trapped in a format nothing reads
SeeProprietary files, legacy exports, formats with no public specification. Getting structured data out of them is work we have done. See data engineering and integrations.
-
Someone else built it and nobody understands it
SeeAn inherited backend with no documentation and no original developer. We audit before committing to anything.
Do You Have a Project Idea?
Tell us what you want to build. We come back with a rough estimate and an honest view of what it takes, before anyone signs anything.
How We Work
What the system has to do, what it has to talk to, and what the data actually looks like. The output is a scope you can price and argue with.
Data model, API surface and integration points agreed on paper before anything is built. This is the stage that saves the most money and the one clients most often want to skip.
Sprints, with something running and callable at the end of each one.
Automated tests on the API, plus load testing where the product will see real volume.
Deployment pipeline, monitoring and alerting in place before go-live rather than after the first incident.
Every project includes one month of bug fixing after launch at no extra cost.
Stack
- PHP: Laravel
- Node.js: NestJS
- Python: Django
- Databases: relational by default, with the schema designed rather than inherited from an ORM tutorial
- APIs: REST and GraphQL, documented from source
- Auth: OAuth 2.0, JWT, Supabase, Firebase Auth
- Async: queues, workers, scheduled and event-driven jobs
- Delivery: CI pipelines, staged deployment, error and performance monitoring
Which of the three we reach for depends on what you already run and who will maintain it. If your team writes PHP, we will not hand you a Node service because we felt like it.
Performance and Quality
We set numeric targets during scoping and test against them, rather than describing the system as fast and hoping.
That usually means response time budgets on the endpoints that matter, a load profile the system has to hold, and a ceiling on database time per request. Yours will be different. The point is that they exist, they are written into the estimate, and QA checks them before release.
Accessibility works the same way on the products these backends serve. WCAG 2.1 AA is a line in our estimates, not an aspiration.
Selected Work
- Planit. Construction planning and scheduling platform, with 4D scheduling and structured data extracted out of building models. The downstream users are among the largest contractors and architecture practices in the industry.
- Vision Care Patient Platform. One backend and one account system serving two separate apps in the stores, with distinct patient and practitioner roles over the same data.
- Compliance Auditing Tool. Multi-role auditing platform with structured reporting over a configurable rule set.
Industries We Build For
Construction and the built environment is where our backend and data work goes deepest. We also build for healthcare platforms, booking and scheduling systems, and travel and mobility.
How We
Work Together
-
Fixed scope
A defined build, priced per module, with a timeline. Suits a clear brief. -
Ongoing team
Backend developers and QA working to your roadmap, alongside your own people. Suits platforms that will keep changing. -
Architecture and audit
A shorter engagement: we review what exists, model what it should be, and give you a written plan you can execute with your own team or with us. -
Support retainer
After the first month of free bug fixing runs out. SeeA typical backend build runs with two developers and a QA engineer. Larger platforms scale from there.We price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
Work with it, in almost every case. A rewrite is the most expensive option available and it is right far less often than it is proposed. We audit first and tell you honestly which parts are worth keeping. Where a rewrite genuinely is the answer, we do it in phases with the old system running, not as a single switch.
-
Usually the one your team can maintain. We work in PHP with Laravel, Node.js with NestJS, and Python with Django, and for most business systems the choice between them matters far less than the data model and the API design. If one of them is clearly right for your case, we will say which and why during scoping.
-
We give you a rough estimate as soon as we understand what the system has to do. The detailed number comes after we have agreed the scope with you, once the goals and the functionality are settled. At that point we break the estimate into modules and price each one, so you can see what an integration or a reporting layer actually costs and decide what belongs in version one.
-
Yes, and it is a large share of what we do. It takes longer than an integration with a documented API, and we scope it with that in mind rather than discovering it halfway through.
-
Every project includes one month of bug fixing at no extra cost. After that, ongoing work runs as a support retainer with agreed response times. See application support.
-
That is what we build for. Documentation, tests, a readable structure and no clever tricks that only make sense to the person who wrote them. If you ever move the work elsewhere, the handover should be uneventful.