Laravel development services for UK businesses

The UK is an easy market to underestimate. Same language, familiar business culture, no localisation project - and then the first invoice run meets a tax year that starts on the sixth of April, and the first integration meets a government API that wants twenty HTTP headers describing the machine the request came from.

HMRC is a real integration, not a form

Making Tax Digital turned tax filing into an API call, and the API has requirements that surprise teams expecting a REST endpoint with a token.

Authentication is OAuth 2, with tokens that expire and a consent flow the user has to pass through - which means token storage, refresh handling, and a plan for what the application does when a refresh fails at the moment a return is due.

The part nobody expects is the fraud prevention headers. HMRC requires the submitting software to describe its environment on every call: the originating IP, the device's screen dimensions, the local timestamp with its offset, the user agent, whether the request came through a proxy. There are around twenty of them, they differ depending on whether your software is a server-side web app or something else, and HMRC validates them - a submission with headers that do not add up is rejected or flagged.

For a Laravel application that means the values have to be collected in the browser, carried to the server, and attached to a call that may be made hours later by a queued job. It is a design problem rather than a mapping exercise, and it is where MTD projects lose their schedule.

Most businesses never reach that problem, because the accounting product they already keep their VAT records in submits on their behalf. Where that product is Sage, the work is getting accurate figures into it before the deadline, and building a second submission path alongside it is how a company ends up filing twice.

Records have to survive longer than your schema will

VAT records are generally kept for six years. That is longer than most applications keep their own structure, so "we can always query it" is not a plan - the table will have been split by then.

Two decisions follow, and both are cheap at the start:

An issued financial document is immutable. A correction is a new record that references the old one, never an update. This is how accountants already think and it removes an entire category of dispute about what was sent and when.

Figures are stored, not derived. A VAT return recalculated from today's rates against a period from four years ago is a different number, and the one that matters is the one that was filed.

Companies House is free, and worth using

The register has an open API. For anything business-to-business, that means company number, registered name, address and status can be verified at the point of signup instead of typed in by a customer who may be guessing.

The catch is that the API is rate limited and the register changes - companies are dissolved, names change, addresses move. Treat it as a source to synchronise from on a schedule rather than a lookup to call inline, and keep the number rather than the name as your key.

Payments, and the gap between them

Card payments behave the way card payments behave anywhere. Two UK-specific things reach the backend.

Direct Debit under the Bacs scheme is not a card charge - it settles over several working days, it can be returned after it appears to have succeeded, and the mandate itself is a stored object with its own lifecycle. An application that treats a Direct Debit as a synchronous payment will report revenue it has not received.

Faster Payments are close to instant and are push rather than pull, so reconciliation is a matching problem: an amount and a reference arriving with no relationship to the invoice except the reference somebody typed.

Both are queue-and-webhook work, which is where most of the interesting engineering on a UK build actually sits.

Working with us from the UK

We work remotely from Ankara, in English, two hours ahead of London - which in practice means a full overlapping working day rather than a handover window.

The engineering is the same application development and API work we do anywhere. What a UK engagement adds is that the tax year, the retention obligations and the government integrations are treated as schema decisions at the start, rather than as a discovery in the quarter the first return is due.

A lot of the UK work that reaches us is an application somebody else built and then left. The first fortnight of that has a shape of its own: what to read, in what order, before changing anything. Where the handover was not clean, an audit is the cheaper way to find out what you have.

Invoicing and payment. In pounds, by bank transfer to an IBAN. Codefacture Yazılım A.Ş. is a Turkish company, so no Turkish VAT appears on the invoice under the export-of-services exemption. We sit outside the Making Tax Digital chain too. What arrives is a PDF, and your bookkeeping takes it from there.