Engineering services
Backend & APIs
This is the engine room your customers never see — where your information is kept, who is allowed to see it, and how your systems pass information to each other safely.
Part of your product’s journey
Of the eight stages we run, this service covers Build. We also run the others.
What this makes possible
The backend is the part of a product customers never see: where the data sits and the rules live. It is also where a product becomes either correct or expensively wrong. A misaligned button is a bad afternoon. A way of storing data that cannot express a real business rule is something else entirely. Fixing it means rearranging live customer records while the system is running. That is the most stressful work in software. The decisions that cost the most are made in the first fortnight, and none of them are visible from outside.
Our approach in more detail
So we spend that fortnight properly. We describe the things your business deals with: orders, patients, invoices, whatever they are. We describe them the way the business actually behaves, not the way the first feature request happened to phrase it. The rules about what is and is not allowed go into the database itself, because application code forgets and databases do not. Before anything is built, we agree in writing exactly what the website and the app can ask for and what comes back. Those teams then build against something stable, instead of whatever the system returned yesterday. How later changes get released without breaking older apps is decided at the start too, since the first such change always arrives sooner than expected.
Security is part of the build rather than a phase near the end. Logging in. Permission checked at the point the data is read, not only on the screen. Limits on how often anyone can hammer the system. Every incoming value checked. A record kept of who did what with anything sensitive. Adding all this after a security review is two to three times the work, and in the meantime you are running exposed.
What you get
- A safe way for other systems to connect to yours
- Login, and permissions so each person sees only their part
- A clear structure for the information you keep
- Scheduled and background work, such as nightly reports
- Faster repeat requests, and limits that stop misuse
- Written instructions for anyone connecting to you, kept versioned
How we get there.
- 01
Modelling the business
We describe the things the system deals with, how they relate to each other, and the stages each one moves through. Then we test that description against awkward cases. A refund on a partly delivered order. A person who belongs to two organisations. A record that must survive deletion because an auditor may ask for it. What the database will and will not permit, and how its structure will be changed later, are decided here, in writing.
- 02
Agreeing how the parts talk
An API is simply the agreed way one piece of software asks another for something. We specify each request, what comes back, and the shape of an error. We also specify how long lists are broken into pages, and the codes used to signal success or failure. All of it is reviewed with the teams that will use it before anything is built. Errors get particular attention, because an app can only recover from a failure it can tell apart from other failures. The specification generates the documentation, so the two cannot drift apart.
- 03
Logging in and permissions
Identity, sessions and how sign-in tokens are handled, then a permission model enforced where the data is read, not only where it is displayed. Roles defined against real responsibilities. We test the negative cases too: that a user in one organisation cannot read another organisation’s records simply by changing a number in the web address.
- 04
Business rules, background work and speed
The business rules are written against the model. Anything slow, or dependent on an outside service, is moved into a queue. The queue tries again, waits longer between attempts, and sets aside whatever keeps failing, so it can be inspected rather than lost. Where measurement shows it is needed, frequently requested data is kept ready in fast storage, with explicit rules for when that ready copy is thrown away. A stored copy nobody can clear is a bug waiting for a bad week.
- 05
Testing, documentation and handover
Fast tests over the business rules. Tests that run against a real database rather than a stand-in that agrees with whatever the code does. Tests that check the agreed request-and-response shapes, so a change that would break your website or app fails automatically before release. Plus a written operations guide covering how to release, how to change the database structure, how backups are taken and how to restore one. That includes a restore actually performed once, since an untested backup is a rumour.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if requirements are still moving every week. The way data is described can change, but changing it repeatedly under a fixed price is how projects sour. Settle what the system is for, or engage us on a monthly arrangement instead.
- Not for you if you need this before you know what the product does. Building against a guess produces exactly the rewrite you were trying to avoid.
- Not for you if a product you can buy covers it. Logging in, payments, notifications and content editing all have good ready-made products behind them, and we will recommend buying where the fit is close.
- Not for you if there is no appetite for automated tests. We write them as part of the work and will not strip them out to shorten a quote. A system without tests is one nobody can safely change later, including us.
- Not for you if the system has to run on servers we are not permitted to see. We can build to a specification, but we cannot be accountable for how something behaves in an environment closed to us.
A worked example
Hypothetical scenario
Illustrative: subscriptions with usage billing
Say you charge a monthly fee plus an extra amount based on how much the customer uses. The naive approach stores the plan on the customer record and keeps a running counter. It breaks the first time somebody upgrades halfway through the month, because now you owe a part-month adjustment. It breaks again when a customer disputes an invoice from four months ago, because you have a counter and not a history. The version that works records each use as a separate dated entry that is never edited. It treats a subscription as a series of dated periods rather than a single field on a record. And it issues each invoice as a snapshot that never changes afterwards. A correction becomes a credit note, not an edit. That costs perhaps a week more at the start, and it saves you rebuilding the whole thing under time pressure with the finance team watching. Systems of this shape run eight to fourteen weeks, and the payment provider’s own awkward cases account for more of that than anyone plans for.
An illustration of our approach, not a delivered client project.
How long does a backend take?
Six to ten weeks for a straightforward one: accounts, permissions, a few core record types, one or two outside services. Eight to fourteen where payments, billing or scheduled work are involved. Longer where data has to be brought across from an existing system, which is nearly always underestimated, because the old data is messier than anyone remembers.
What happens if scope changes halfway through?
We separate additions from redefinitions. One more request type against the existing structure is usually absorbed. A change to the structure itself is different. That means a new relationship, a new rule about who can see what, or a record that now needs its full history kept. We re-estimate it in writing before we touch it, because it ripples through the agreed request formats, the tests and any data already stored. You see the reasoning and the number first.
Can you build the backend for a website or app our team is already building?
Yes, and agreeing the interface first exists partly for that. In the first week we settle with your website or app developers exactly what they can ask for and what comes back. We then publish a stand-in version that returns realistic sample data, so they can build against a stable interface while the real work is in progress. Automated checks on the agreed shapes then keep both sides honest as things change.
How do you handle security?
Permissions checked where the data is read. Database queries written so a user cannot slip their own commands into them. Passwords and keys held in a dedicated store rather than in files sitting alongside the code. Automatic scanning of the outside libraries we use for known vulnerabilities. Limits on how often anyone can call the parts open to the public. And a record kept of who did what with sensitive data. If a specific regulation applies to you, tell us at the outset — adding those records and data retention rules after the structure is settled is significantly more expensive.
What documentation do we get?
A full description of every request the system accepts, generated from the code so it cannot drift out of date. A note explaining why the significant decisions were made. The data structure with its rules. And an operations guide covering releases, database changes, backups and restores. The reasoning matters as much as the description — it stops a future engineer undoing a deliberate choice they mistook for an oversight.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.