Development
Laravel development for business systems
A lot of Danish business systems run on Laravel: customer portals, booking, invoicing, and internal tools that outgrew a spreadsheet. I build them, extend them, and take them over when the person who wrote them has moved on.
When this makes sense
- A Laravel system runs part of the business and exactly one person understands it
- You need a feature that touches the database, the queue and the billing at the same time
- The framework upgrade has been postponed long enough that upgrading is now its own project
- A background job fails silently and you find out from a customer rather than from an alert
- You have in-house developers and need senior capacity without adding a permanent head
How it works
- 01
Map it
I read the codebase, the schema and the jobs before touching anything, and tell you what I found — including the parts you did not ask about.
- 02
Build it
Feature work or upgrade work, in small pieces that can go live on their own. You see it running on staging rather than in a status report.
- 03
Hand it over
Migrations, environment variables and deployment written down. The alerts point at you, not at me, so nothing depends on my staying.
What the work covers
- New features, refactoring, and paying down the parts that slow every change
- Framework and PHP version upgrades, done incrementally rather than as one jump
- Queues, scheduled jobs, and the background work that fails quietly
- Tests around the parts where a mistake costs money
- Integrations to accounting, payment and CRM systems, with retries and alerting
- Database work: indexing, schema changes and the queries that were fine at a tenth of the data
- Deployment and environment setup written down, so a release is not a person
- Code review and a second senior opinion alongside your own developers
- The public pages server-rendered with markup, so prices and services can be found in Google and quoted in an AI answer
The situation this page is written for
A Laravel application that runs part of a business almost never arrives on my desk because somebody wants a new feature. It arrives because the person who built it has left, or gone freelance and stopped answering quickly, and the company has discovered that a system it depends on daily is understood by nobody currently on the payroll. The immediate need is a feature or a fix; the actual need is for a second person to be able to read the thing.
That shapes how the first weeks run. Before I quote feature work I read the schema, the migrations, the queued jobs and the scheduled commands, and I write down how the application actually fits together. Clients are sometimes surprised that this is billable, and it is the part with the longest payback: every estimate after it is based on the system as it is rather than on the system as it was described.
Upgrades, and why they get postponed
The most common state I find a Laravel codebase in is several major versions behind, with a composer.lock nobody has dared touch. It is a rational place to end up. Upgrading has no visible benefit to anyone outside the engineering conversation, it carries real risk when there are no tests, and there is always something more urgent. Then a security advisory lands on a dependency that cannot be patched without the upgrade, and it becomes urgent on somebody else’s schedule.
The way through is boring and it works: one major version at a time, with the application deployed and running between each. Where there is no test suite, a thin one around the paths that move money or lose data comes first, because it is what makes the rest of the upgrade checkable rather than hopeful. PHP version and framework version are separate steps, done separately, so a failure has one obvious cause.
This is slower than the single-jump approach and cheaper than it, because the expensive part of an upgrade is never the code change. It is the fortnight afterwards where nobody can tell which of forty changes broke the invoice run.
Working with the developers you already have
A good share of Laravel work is not a takeover at all. There is a team, or one in-house developer, and what is missing is capacity or a second senior opinion. That arrangement suits me: pull request review, taking the pieces nobody has time for, or pairing on the part of the system everybody has been avoiding.
It is priced the same way as everything else. Hourly work is DKK 600 an hour ex. VAT with no minimum retainer, and where the need is steady rather than occasional, the development partnership at DKK 12,000 a month for 20 hours is the easier shape. The hourly rate is the same — the difference is that the hours are set aside in advance, and each task does not have to be quoted and scheduled from scratch. There is no lock-in on it, because a retainer that has to be enforced by contract is one nobody wants to be in.
Common questions
- What does Laravel development cost?
- Hourly work is DKK 600 an hour ex. VAT. A defined build starts at DKK 30,000, which is 50 hours, at an agreed scope and delivery date. Danish agencies typically quote from around DKK 150,000 for an MVP and DKK 250,000 to 600,000 for a mid-sized web application — scope drives that far more than the hourly rate does.
- Can you upgrade an old Laravel version?
- Yes, and it is worth doing before it becomes urgent. I upgrade in steps with the test suite and staging in between, rather than jumping several majors at once and spending the savings on debugging. If there is no test suite, writing a thin one around the critical paths comes first.
- Can you work alongside our existing developer?
- Yes. Reviewing pull requests, taking the pieces nobody has time for, or being the second senior opinion is a normal arrangement. I am not trying to become the only person who understands your system — that is the situation most clients call me about.
- What about the database?
- It is usually where the real problem is. Missing indexes, a schema that fit the original idea and not the current one, and queries that were fine at a tenth of the data. I work in Postgres and MySQL and will tell you when a slow page is a database problem wearing a frontend costume.
- Can you work on a Laravel project with no tests at all?
- Yes, and it is common. What changes is the order of work rather than whether it is possible: a thin suite around the paths that move money or lose data comes first, because without it neither of us can tell whether a change was safe. That is usually a few days, not a project, and it is the thing that makes every later estimate worth believing.
- How do you handle deployment and hosting?
- Whatever you already run, if it works — a VPS, a managed platform, or a container setup somebody configured once. Where there is nothing, I set up a deployment that runs from a git push with migrations and a rollback path, and I write down how it works. I also build and operate a hosting platform of my own, and I will say plainly when yours is fine and moving would just be churn.
- What if the system needs a rewrite rather than repairs?
- Then I say so, with the reasoning and the cost, and it is your decision rather than mine. Rewrites are recommended far more often than they are warranted, usually because reading someone else’s code is harder than writing your own. A technical review at DKK 6,000 is the honest way to settle that question before either of us commits to a number, and it is often the answer that a targeted fix buys another three years.
- Do you sign an NDA and work with production data?
- An NDA is fine and normal. Production data is handled differently: I work against anonymised or reduced copies wherever the work allows it, because the safest way to avoid mishandling personal data is not to hold it. Where production access is genuinely needed, it is time-limited, logged and named, and the GDPR side of that gets written down rather than assumed.
- Does a Laravel application need to be findable in Google and in AI answers?
- What sits behind the login should never be seen by a crawler, and no hours should go on it. What sits in front — the front page, the services, the prices, a catalogue, a help section — is often all a future customer and an AI assistant ever see, and it is usually the part built last and measured least. Blade serves finished HTML, so the starting point is good: what is normally missing is markup carrying the real figures, titles and canonicals per page, a robots.txt written on purpose, and a sitemap that matches what actually exists.
- Laravel or WordPress for my project?
- If the main job is publishing content you want to edit yourself, WordPress. If the main job is logic — users, permissions, calculations, a workflow with states — Laravel, and you will spend less over three years than you would forcing the other one. I will give you the honest answer even when it is the cheaper one.
Other stacks I work in
Not sure which one to pick?
Send a couple of lines about what you are trying to achieve. You get a reply within 24 hours, and an honest yes or no.