Our last London developer left and nobody knows the codebase. Where do you start?

With an audit rather than an estimate. Dependency versions, the test suite if there is one, the slow queries, the jobs that fail silently, and where money is calculated. That produces a list with sizes attached, which is the thing you actually need before deciding what to do. Estimating from a conversation is how both sides end up disappointed.

Can you take over hosting and deployment too?

Usually the better arrangement is that you own the infrastructure accounts and we work inside them, so nothing is hostage to a supplier relationship. We will set up the deployment, the queue workers and the monitoring, and hand over credentials you already hold.

Is it worth upgrading or should we rewrite?

Almost always upgrade, and we will show the arithmetic rather than assert it. A rewrite throws away years of encoded business rules that nobody has written down, and the second system usually rediscovers them one bug report at a time. The honest exception is when the data model itself is wrong rather than the code around it.

Do you invoice in pounds?

Yes, from Codefacture Yazılım A.Ş. in Türkiye, by bank transfer to an IBAN. Exported services carry no Turkish VAT, so none appears on the invoice.

Laravel in London

Laravel development for London companies

A Laravel development company working with London teams. Five hours of overlap, an application that usually predates the people running it, and money rules that stopped matching the EU's.

Updated November 4, 2026

Three hours separate London from Ankara, so roughly five hours of the working day are shared. Our afternoon is your morning, so the reliable window for anything synchronous sits late morning to mid-afternoon your time.

That is enough for everything that genuinely needs two people, and the rest is written down - which a Laravel engagement benefits from anyway, because most of the important decisions here are about data rather than screens.

What usually arrives from London

A London Laravel brief is rarely greenfield. It is an application between three and eight years old that the business runs on, built by people who have moved on, with a dependency list that stopped at whatever was current when the last person left.

That shapes the first phase completely. Before anything is built there is reading: which version, what the upgrade path costs, whether there is a test suite and whether it passes, which queries are slow, which queued jobs fail without telling anyone, and - the one that matters most - where money is calculated and in what type it is stored.

An estimate produced from a call is a guess. An estimate produced from reading the codebase has sizes attached to real findings, and it is usually the first time anyone has told the business what it owns.

The money is the interesting part of a London Laravel build

London work concentrates in fintech, insurance, media billing and marketplaces. What those share is that the application moves money, and that changes which bugs matter.

A rendering bug is embarrassing. A rounding bug is a reconciliation that does not balance and an accountant who no longer trusts the system. So the questions we ask early are narrow and specific: is money stored as an integer in minor units or as a float; is the currency a separate column; are the captured, refunded and fee amounts three fields or one; and does the schema allow an invoice to be corrected without being edited.

Those are the decisions that are hard to undo, and inherited applications get them wrong often enough that checking is worth the hour.

The second recurring finding is the queue. Jobs that are not safe to repeat, in a system that retries by design, which means somewhere there is a duplicate charge or a double-sent email that nobody has traced yet.

Upgrade before rewrite, with the arithmetic shown

The instinct with an old codebase is to start again. It is almost always wrong, and the reason is not sentiment.

Years of business rules are encoded in that application and nowhere else - the edge cases, the exceptions for three large customers, the workaround for the thing the payment provider does on Tuesdays. None of it is documented. A rewrite rediscovers it through bug reports from the people who depend on it.

An upgrade is dull and it preserves that knowledge. Being several versions behind has a cost that can be measured and quoted, and the comparison between that number and a rewrite is usually not close.

The honest exception is a data model that is wrong rather than code that is old. That is a different conversation and we will say so when it is the case.

The integrations a London build tends to need

Two UK specifics reach the code rather than the policy page.

HMRC is a genuine integration with requirements that surprise teams expecting a REST endpoint and a token. And Companies House publishes data that is worth reading directly rather than having customers retype, which removes an entire class of onboarding error.

Both belong on the United Kingdom market page, where the country-level ground lives.

A London codebase with no tests and a deploy nobody understands

The most common London engagement starts with an application that works, earns money, and cannot safely be changed. There is no test suite, the deployment is a sequence of steps in somebody's head, and the last person who understood it left.

The order of operations matters more than anything else here, and the instinct to start fixing is wrong.

First, make it buildable by somebody new. A documented path from a clean machine to a running application, with the environment variables listed and the undocumented ones found. Until that exists, nothing can be verified and every change is a gamble.

Second, put a test around the money. Not a suite - a handful of tests over the paths where a payment is taken, an invoice is produced or stock moves. That is usually a day of work and it converts the whole engagement from careful guessing into ordinary engineering.

Third, make the deployment repeatable, so a change can be reversed. A system that can be rolled back can be improved; one that cannot has to be perfect first time, which is why nobody has touched it.

Only then the actual work. Teams that reverse this order spend their first month on improvements nobody can deploy. Inheriting a Laravel codebase is the longer version.

Queues on a London project, and the jobs nobody is watching

Almost every inherited London application has a failed_jobs table with years in it, and nobody has looked.

That table is the most useful diagnostic artefact on the system. The failures cluster, and the clusters name the problems: an integration whose credentials expired in 2023, a job that throws on a specific record shape, a mail send that has been failing silently since a provider changed an endpoint. Customers have been affected by all three and nobody connected the complaints to the cause.

Reading it is the first hour of the engagement. What is in there, how long it has been, and - the question that decides the repair - whether retrying any of it would be safe. Frequently it would not, because the jobs were never written to be safe to run twice, which is also why they were abandoned rather than replayed.

The fix has two halves. The jobs become idempotent so a retry is harmless, and something watches the table so a failure is noticed in hours rather than years. A queue nobody monitors is not a queue; it is a place work goes to be lost quietly.

Commercially

The invoice comes from Codefacture Yazılım A.Ş., registered in Türkiye, in pounds by bank transfer, with no Turkish VAT under the export-of-services exemption. Scope fixed in writing before work starts, priced per project rather than as a day rate.