Laravel development for Munich companies

Munich buys engineering through a process, and the process is most of the schedule. Insurers, manufacturers, industrial services and the consultancies that sell into them: procurement, vendor onboarding, a security questionnaire and an architecture board.

The engineering is rarely what makes these projects late.

What slows a Munich project down

A database credential that needs a ticket. A VPN account that needs a sponsor. A security questionnaire that asks where the queue workers run. A firewall rule that one named person signs off, and that person is on leave.

So the first week is spent finding out which approvals have the longest lead time and ordering the phases so that a blocked dependency stops one phase rather than the project. That is not engineering and it determines more about the delivery date than anything that is.

In Munich the systems are in the building

This is the Munich specific that changes architecture rather than detail.

The ERP, the warehouse system, the production scheduler - these frequently run on a machine inside the company's own network, not on a hosted service with a public endpoint. A deployed application cannot reach them, and no library changes that.

There are three honest shapes, and choosing between them is a conversation with the client's IT department rather than a technical preference. A connector installed inside their network that talks outward over HTTPS, so no inbound firewall rule is needed. A private network path, which is cleaner once it exists and exists when their team has time. Or a file exchange, which people who prefer APIs dismiss too quickly - it is observable, a failed run leaves the file sitting there, and a person can open it and see what was wrong.

Whichever it is, the consequence is the same and belongs in the first week: the data in the application is a copy with a delay, and the interface has to say so rather than presenting a stale figure as current. That is the integration question every project here starts with.

Old Laravel applications, and why not to restart

A good share of this work is an application between five and fifteen years old that the business depends on, built by people who have gone.

The instinct is to rewrite. It is almost always wrong, and the reason is not sentiment: years of business rules are encoded there and nowhere else - the exceptions for three large customers, the workaround for what a partner system does on Tuesdays, the rounding rule somebody argued about in 2019. None of it is documented, and a rewrite rediscovers it one bug report at a time from the people who depend on it.

Being several versions behind has a measurable cost, 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, and we will say so when that is the case.

A Munich on-premise deployment has no managed services

Inside the building there is no managed queue, no managed object store, no managed search and no platform that redeploys on a push. There is a virtual machine, a change window, and an operations team with their own procedures.

That is workable and it has to be designed for rather than discovered. Every managed service the application would otherwise lean on becomes a component somebody has to run, so the choice is made deliberately - Redis on the same host, or the database as the queue backend; the filesystem behind the same storage abstraction that would have pointed at object storage; full-text search in Postgres rather than a separate engine, unless the requirement genuinely justifies the second thing to operate.

Writing against abstractions rather than against a provider is what makes that a configuration choice instead of a rewrite, and it is the same discipline that keeps the application movable later. The cost is small; the alternative is an application that assumes a platform and has to be unpicked to run anywhere else.

Deployment is theirs. Which means the artefact we hand over has to be something their process can take - a documented, repeatable sequence that does not require us to be present, runs within a change window, and can be reversed by whoever is on duty. Migrations that are safe to run before the new code arrives, and a rollback that does not depend on a database restore, are what make that possible.

Backups and monitoring belong to them as well, and the handover is not complete until somebody on their side has restored from a backup once, in front of witnesses. An untested backup is a plan, not a backup.

Upgrading a Munich Laravel application that is five versions behind

The application works, it is years out of support, and the question is whether to upgrade it or replace it. Upgrading is almost always the right answer and almost always underestimated.

The order is fixed by the dependencies rather than by preference. PHP first, because the framework version you are heading for requires it and the extension ecosystem will complain. Then one framework version at a time, running the test suite between each. Skipping intermediate versions is tempting and removes the only thing telling you which change broke something.

Which presumes there is a test suite, and in an application of this vintage there usually is not. Writing one from scratch is not the task; putting a test around the handful of paths that generate the revenue is, and that is a week rather than a quarter. Without it the upgrade is a series of changes nobody can verify, and it will be abandoned halfway with the application in a worse state than it started.

Packages are where it stalls. An abandoned package with no version supporting the target framework has to be replaced, vendored or removed, and finding those before starting - rather than at version four of five - changes the estimate substantially. That audit is a day's work and it is the difference between a plan and a hope.

The thing worth saying to a sponsor who is weighing this against a rewrite is that the upgrade preserves the behaviour the business depends on, including the parts nobody has documented. A rewrite rediscovers them one complaint at a time.

The paperwork is part of it

The contracting entity is Codefacture Yazılım A.Ş., registered in Türkiye, invoicing in euros by bank transfer, with no Turkish VAT under the export-of-services exemption.

A security questionnaire will ask where data rests, who the sub-processors are and what happens at the end of the engagement. Those are answerable and faster answered before scoping than during it.

The regulatory ground sits on the Germany market page.