Your New System Has to Talk to the Ones You Already Pay For
Almost no UK business is starting from nothing. There is accounting software, a carrier account, a bank, a spreadsheet somebody guards and a platform the previous supplier chose. The interesting engineering is rarely the new thing — it is making the new thing sit correctly among all of that without becoming a second, disagreeing copy of the truth.
The Systems UK Clients Actually Ask Us to Connect To
Not an exhaustive list, but it covers most of what turns up in a first scoping call. Each one has a characteristic difficulty worth knowing before you budget.
Accounting: Sage, Xero, QuickBooks
Pushing invoices, pulling payment status, keeping a customer record in step. Xero and QuickBooks Online are pleasant, modern APIs. Sage is several products wearing one name, and an older Sage 50 on a machine in the office is a different job from Sage Business Cloud.
Companies House
The public register, available through a documented API with a free key. We use it to validate a company number at signup, prefill a registered address, pull the officer and significant control lists for onboarding checks, and notice when a customer has been dissolved.
Couriers and fulfilment
Booking collections, generating labels, pulling tracking events back in, and dealing with the fact that every carrier models an address slightly differently. Expect quirks around remote postcodes, Northern Ireland consignments and anything crossing a customs border.
Banking and Open Banking
Verifying a bank account, reading transactions with the customer’s consent, or initiating a payment. You do this through a provider that already holds the FCA permissions rather than seeking them yourself, and the integration work is against that provider.
HMRC Making Tax Digital
Submitting VAT returns where your records genuinely live in the system we are building. It needs an OAuth grant from the business, a digital link back to the underlying figures and the fraud prevention headers HMRC checks. Often the better answer is to push figures to the accounting package and let it file.
Everything else in the stack
Stripe and GoCardless, transactional email and SMS, address lookup against Royal Mail data, HubSpot or a CRM, e-signature, and the document store your compliance team already approved. Individually small. Collectively, often the larger half of the estimate.
Every Third Party Gets Held at Arm’s Length
The path a piece of work takes when it has to reach a system you do not control.
A member of staff confirms an order, or a customer completes a checkout. The screen responds immediately. Nothing the user is waiting on depends on a system belonging to somebody else.
The work to be done is written down as a durable job with an idempotency key, so it survives a deployment, a restart or a crash, and so it can never be performed twice by accident.
One small piece of code per external system, and the only place that knows what that vendor calls things. Swapping carriers, or surviving a vendor renaming a field, means changing this and nothing else.
Sage, a carrier, your bank’s provider, HMRC. Sometimes fast, sometimes slow, occasionally down for four hours on a Tuesday with no notice. Every response and every failure is logged with its correlation identifier.
Success updates your records and closes the loop. Repeated failure moves the job to a queue your staff can see, with the error in plain English and a button to retry. A scheduled reconciliation compares both sides so nothing is silently lost.
Deciding the Shape Before Anyone Writes a Client
An API is a promise to somebody who will not be in the room when you change it. That is what makes the early decisions worth making slowly.
Settled before the first endpoint is written
- What the resources are called, in your business’s language rather than the database’s
- How errors are returned, in one consistent structure with a code a client can act on
- How money is represented, which is integer pence and an explicit currency, never a floating point number
- How dates and times are represented, in UTC on the wire, with British Summer Time handled at the edges
- How lists are paged, filtered and sorted, decided once rather than reinvented per endpoint
- Versioning, from the first release rather than the first breaking change
Written down as it is built
- An OpenAPI specification that lives in the repository and is generated from the code, so it cannot quietly go stale
- Browsable documentation with real request and response examples a developer can copy
- Contract tests, so a change that breaks an existing client fails the build instead of a customer
- A sandbox or test mode where a partner can integrate without touching live data
- A changelog with dates, which is the first thing an integrating developer looks for
- A stated deprecation policy: what notice a consumer gets before something is withdrawn
Choosing between REST and GraphQL, on the evidence
We default to REST and switch when a specific row below genuinely applies to you. The decision is much less important than most architecture discussions make it, and much harder to reverse once several clients depend on it.
| If this is true of your build | REST | GraphQL |
|---|---|---|
| One web app and perhaps a mobile app consume it | Ample, and simpler to operate | Overhead you will not recover |
| Many screens each need a slightly different slice of data | Either many endpoints or over-fetching | This is what it is for |
| Mobile users on poor connections, payload size matters | Manageable with care | Genuinely helps, clients ask for exactly what they render |
| External partners will integrate with it | Better understood by most integrating developers | Expect more support questions |
| You want simple caching at the edge | Straightforward, standard HTTP caching | Needs deliberate work |
| Rate limiting and abuse control matter | Per-endpoint limits are easy to reason about | Query cost analysis needed, a deep query can be expensive |
| Debugging with a support engineer looking over a shoulder | A URL you can paste into a browser | Requires tooling |
Proving Who Is Calling, and Being Able to Stop Them
Choosing a mechanism is the easy half. Being able to revoke, rotate and audit it is the half that gets skipped.
Keys for machines
A server-to-server integration or a scheduled script gets a key. Issued per integration rather than per company, so one can be revoked without breaking the others, and shown to the customer exactly once.
Delegated access for people
When a user grants your application access to their account somewhere else — their accounting package, their bank’s provider, HMRC — that is a consent flow with a token you refresh and a grant they can withdraw. Building it as if it were a password is the classic mistake.
Short-lived tokens for your own apps
Your web and mobile clients get a token that expires quickly and refreshes quietly. Long-lived tokens are convenient and impossible to withdraw before they expire, which is precisely the wrong trade for anything touching customer data.
Secrets that live somewhere sensible
In a managed secret store, injected at runtime, never in the repository and never in a shared document. Rotated on a schedule and immediately when somebody with access leaves. This is routinely the first finding when we audit an inherited codebase.
Scopes narrower than convenient
A partner who needs to read consignment status does not need permission to issue refunds. Scoping each credential to what it is genuinely for limits what a leaked key can do, and gives you a short answer for a security questionnaire.
An access log you can actually read
Who called, when, from where and what they asked for, retained for a defined period. It answers the question a client eventually asks, and it is how you find out that a partner has been polling every second since March.
Storing UK Data Without Regretting It in Two Years
The database schema is the least reversible thing we build. Code gets rewritten every few years without ceremony; a table with four million rows and six systems reading it does not. Most of the awkward decisions are unglamorous and specific to operating in the UK.
- Addresses. A UK address is not a street, a city and a postcode. There are flats, unit numbers on industrial estates, named houses with no number, BFPO addresses, and Northern Ireland. We store structured lines plus a postcode, use an address lookup for entry, and never make the postcode a required unique key.
- Company numbers. Text, never a number. Leading zeros are significant and Scottish and Northern Irish companies carry letter prefixes. Storing them as integers is a bug that surfaces the first time somebody from Glasgow signs up.
- Money. Integer pence with an explicit currency, never a decimal type someone will round differently, and certainly never a float. Store the VAT rate that applied at the time on the record itself rather than looking it up later.
- Dates and times. Stored in UTC, displayed in UK local time. British Summer Time is the reason a report run at 00:30 in late March disagrees with the one run at 00:30 in December, and it is far cheaper to handle at the boundary than to explain to a client.
- Names. One field where you can, sensible lengths, no assumptions about titles or the number of parts. Every rule you invent about what a name looks like will be wrong for somebody who is about to become a customer.
- Deletion. A right to erasure exists under UK GDPR, and an invoice you must retain for tax purposes also exists. The reconciliation is to decide per table, in advance, what is deleted, what is anonymised and what is retained, and to build that as a job rather than improvising during a live request.
- History. Anything a person will later dispute needs a record of what it was before. An append-only log of changes to critical records costs very little at design time and is the only thing that answers a question about last March.
We design the schema from a written model of your business rather than from the screens, because the screens will be redrawn twice before launch and the relationships between things will not.
Work That Should Never Happen While a User Waits
Queues, rate limits and monitoring are the difference between a system that copes with a bad afternoon and one that becomes a bad afternoon.
Background jobs and scheduled work
- Anything slow, anything external, anything that sends an email or generates a document
- Jobs are durable, so a deployment mid-afternoon does not lose the queue
- Retries use increasing backoff rather than hammering a service that is already struggling
- A failed job ends up somewhere visible with a readable error, not in a log nobody opens
- Scheduled work — nightly reconciliation, retention deletion, month-end exports — is monitored for having run at all, which is the failure people miss
- Jobs are idempotent, so running one twice does not produce two invoices
Rate limits and the partner who loops
- Limits per credential rather than per address, so one integration cannot starve the others
- Clear limit headers and a proper response code, so a competent client backs off by itself
- A different, higher limit for your own applications than for external consumers
- Protection against expensive queries as well as frequent ones, particularly on any search endpoint
- Respecting the limits of the services you consume, which have theirs too and will suspend you
- An alert when a consumer is repeatedly hitting a limit, because that is usually a bug on their side that you can point out before it becomes a complaint
The Afternoon Somebody Else’s System Stops Answering
It will happen, several times a year, and none of those times will be convenient. The design question is what your business is still able to do while it lasts.
Retry, then stop retrying
Increasing intervals, a cap on attempts, and a decision that this one needs a person. Infinite retries against a dead service generate cost and noise and fix nothing.
Fail open or fail closed, deliberately
If an address lookup is down, let the customer type the address. If a payment check is down, do not let the order through. Which way each dependency fails is a business decision we ask you for, not one a developer should quietly make.
A queue a human can work
Failed integrations land on a screen with the error, the affected record and a retry button, so your operations team clears a backlog themselves the moment the other end recovers.
Nightly reconciliation
A scheduled comparison between your records and each external system, reporting on anything that does not agree. This is how you discover the four orders that silently never reached the carrier, rather than hearing about them from customers.
Alerts that reach a person
Error rates, queue depth, job failures and response times, with thresholds agreed with you and alerts routed to a named channel rather than an inbox. Quiet dashboards nobody opens are not monitoring.
Logs without personal data in them
Structured, correlated by request, searchable, and deliberately free of names, card details and anything else that would turn your log retention into a UK GDPR problem. Identifiers, not identities.
When You Do Not Need Us to Build a Backend
The platform you already run does it. A surprising amount of what people ask us to build already exists as a configuration screen in their existing system, or as an off-the-shelf connector between two products they already pay for. We will say so. Bespoke code you did not need is the most expensive kind.
One integration, run once a week, for a small team. If the requirement is genuinely a nightly file from one system into another, a scheduled export and a small script is proportionate. A resilient queue-based integration platform is not, and quoting one would be padding.
Nobody has decided what the data means yet. If two departments disagree about what counts as an active customer, no amount of engineering resolves it. That disagreement is a half-day workshop, and it should happen before the schema, not after.
Where a build genuinely is warranted, the same honesty applies in the other direction: we will tell you when the integration you described is harder than it looks, usually because the vendor at the other end has an API in name only.
Integration Questions From First Calls
Can you connect our new system to Sage or Xero?
Yes, and which one matters more than people expect. Xero and QuickBooks Online have modern, well-documented APIs with OAuth, and integrating with them is routine work. Sage covers several very different products: Sage Business Cloud Accounting has a normal cloud API, whereas older desktop Sage 50 installations usually need a connector running on a machine at your office or a scheduled file exchange. The first thing we do is establish exactly which product and version you run, because the answer changes the estimate substantially.
What is involved in looking up a company at Companies House?
Less than most people assume. Companies House publishes a public API covering company profiles, registered addresses, officers, persons with significant control and filing history. You register for a key, and there are usage limits to respect. In practice we use it to validate a company number at signup, prefill an address rather than making someone type it, and flag when a customer has been dissolved. It is public register data rather than credit data, so it tells you a company exists and who runs it, not whether it pays its bills.
Do we need to be FCA authorised to use Open Banking data?
To access bank data yourself, yes, you would need the relevant permission from the FCA. In practice almost nobody builds that themselves. You use a regulated provider that already holds the permissions and acts as the account information or payment initiation service, and your application talks to them. That keeps you out of the authorisation process while still letting you verify a bank account, pull transactions with consent, or initiate a payment. We will build against whichever provider you choose, and we will not advise you on your own regulatory position.
Can the system file our VAT returns under Making Tax Digital?
It can submit VAT returns to HMRC if that is genuinely the right place for it, but it is worth checking whether your accounting package already does it. Making Tax Digital requires software that connects to HMRC through their API, with a digital link from the underlying records, an OAuth grant from the business and a set of fraud prevention headers that HMRC checks. Where clients already run Xero or Sage, the sensible answer is usually to push the figures there and let it file. Where the records genuinely live in the system we are building, we build the submission.
What happens if a courier API is down when an order needs a label?
The order does not fail. Anything that depends on a third party runs as a background job rather than inside the web request, so a request from your customer completes whatever the carrier is doing. The job retries on a backoff schedule, and if it keeps failing it lands in a queue a human can see, with a clear message and a button to try again. Your staff find out from a dashboard and an alert rather than from a customer ringing about a parcel that never moved.
How do you stop a duplicate payment or a duplicate order?
With idempotency keys, which is a dull answer to an expensive problem. Every operation that moves money or creates a record carries a unique key generated by the caller, and the server records that key when it succeeds. If the same request arrives twice, because a mobile connection dropped mid-request or somebody pressed the button again, the second one returns the original result instead of doing the work twice. We also reconcile against the payment provider on a schedule so that anything that slipped through gets caught.
Who owns the API keys and the integration accounts?
You do, and this matters more than it sounds. Accounts with Companies House, your payment provider, your carriers and your accounting software are registered in your company name from the start, and we work from credentials you can revoke. Secrets live in a managed secret store rather than in the codebase, they are rotated when people leave, and the handover document lists every external account the system depends on. If we part ways you change the credentials and nothing stops working.
What the Backend Usually Carries
Web Applications
Portals and internal tools that need one version of the truth rather than a second copy of your records.
Learn moreSaaS Products
Subscription billing, VAT and Direct Debit, all of which sit on top of the services described here.
Learn moreProject Rescue
If you have inherited a backend nobody understands, we start with a fixed-price audit and a straight verdict.
Learn moreSend Us the List of Systems It Has to Talk To
Names and versions where you know them — the accounting package, the carrier, the platform the last supplier chose. We will tell you which connections are routine, which are awkward, and what the whole thing costs in sterling excluding VAT.