You already have a Laravel application. Just not the people behind it any more.
The builder left, the agency stopped, or the work is growing faster than your team. We take over existing Laravel applications and keep working on them — even if the previous developer left no documentation.
- There is nobody left who knows the application from the inside.
- You don't dare to update because you don't know what will break.
- Your Laravel version no longer gets security updates.
- There are no tests, so every change is a gamble.
- There is no environment to try things out: changes go straight to production.
- The previous developer is gone and the handover consisted of a password.
- A small change now takes weeks, when it used to take a day.
- Nobody can tell you where the application runs and who has access to it.
Recognise any of this? Then we start by reading, not by building.
When taking over is sensible — and when to rebuild
Many agencies reflexively rebuild, because new code is nicer to work in. That is rarely in your interest. We start by reading and then tell you honestly which of the two is cheaper.
Take over when the foundation is sound
The application does what it should, and the complaints are about speed, updates or missing features. That can be fixed without starting over.
It contains years of business rules that nobody can fully recount any more. Rediscovering them costs more than fixing up the code.
You want to keep going, not stand still. A rebuild means months in which nothing new is added.
Rebuild when the base won't hold
The application runs on a PHP or Laravel version so old that updating effectively means rewriting. Then that is also the honest name for it.
The database is set up so that every new feature becomes an exception. Better programming doesn't solve that.
The company now works very differently from when the application was built. Then you are repairing something that no longer fits anyway.
What you get, and what we need from you
- A code review before you commit to anything — what is there, what the risk is and what it costs to bring it up to date.
- An update plan with an order: security first, then versions, then features.
- Tests on the parts that matter most, so the next change is no longer a gamble.
- A developer you can talk to, not a ticket system.
- Documentation of what we found — including the part you'd rather not hear.
- Access to the code and to the server it runs on.
- Someone who can tell us what the application is supposed to do, even if nobody knows how any more.
- Room to deal with overdue maintenance first. Building new features straight away on a shaky base is how it went wrong last time.
- Honesty about what happened before. A failed project is nothing to be ashamed of and it helps us.
We are clear about this up front, because afterwards it is always an awkward conversation. Part of what we build is custom work for you. Another part consists of components we developed ourselves and use for more clients — and that is exactly why you don't pay again for every part. What falls under which agreement is in the contract before we start, not in an appendix you get at delivery.
If you want certainty in case we disappear, we arrange source code escrow: an independent third party holds the code and releases it to you when needed. For larger assignments that is a normal procurement requirement, and we cooperate with it.
How a takeover runs
We never start by building. The first weeks are reading, running and measuring — otherwise you promise things based on what you hope is there.
-
01
Code review
We read the code, run it locally and look at versions, dependencies, tests and security. You get a report, even if you don't continue with us afterwards.
-
02
Taking over the environment
Access, backups, deployment process and monitoring. Only once we can run it and restore it is it really taken over.
-
03
Overdue maintenance
Security updates and versions first. This visibly delivers nothing, and that is exactly why it is the part that always got left.
-
04
Tests on the core
Not everything, but the parts where a mistake costs money. After that, changes can be made with confidence again.
-
05
Every 2 weeks
Further development
From here on like any other project: two-week blocks with a demo.
What a takeover costs
The code review has a fixed price, because we know what it costs us to read an application. What follows doesn't, because it depends on what we find — and we only know that after step 01.
Expect the first months to be mostly overdue maintenance. That feels like spending money without results, but it is why everything moves forward again afterwards.
The report is yours, even if you give it to another agency. We would rather earn an assignment than hold on to one with a report you are not allowed to take with you.
How far behind
Two Laravel versions behind is a few days. Six versions behind, with packages that no longer exist, is a project.
What isn't there
Without tests every change means checking by hand. Writing the first tests takes time and pays for itself by the third change.
What is attached to it
A standalone application is manageable. One that hangs off five systems, two of them undocumented, is not.
What we look at in a review
This is the list your current developer or IT partner can read along with. The report follows this structure.
What still gets updates
PHP and Laravel version, and which packages are no longer maintained. An unmaintained package is a leak waiting to happen.
What the code itself says
PHPStan across the whole codebase, test coverage, and the places where the same logic lives in three spots.
Can you go back
Backups that can demonstrably be restored, a deployment process without manual steps, and logging that shows what went wrong.
The report also names what is good. That saves you money in the next step.
What that looked like in practice
14
hours of retyping saved per week
Packing slips that book themselves
Technical wholesaler, 140 employees — PDFs from the mailbox are read, checked and created as orders in the ERP.
Laravel · RAG · ERP integration
6
weeks until the first integration went live
A core system from 2012, opened up again
Manufacturer in the Brainport region, 320 employees — an API layer next to the existing system, without production downtime.
Laravel · API · migration path
38.000
documents searchable with their source
The archive gives answers
Engineering firm, 85 employees — staff ask a question and get the answer with its source.
Laravel · embeddings · SSO
Half an hour costs you nothing
Tell us which process takes the most manual work. We will tell you honestly whether AI is the right answer — and sometimes the answer is: fix your integration first. Then you have that too, without an invoice.