How we work
Six steps. You see the price before any code, and the rehearsal before any release.
The same sequence runs for an upgrade, a rescue or a new piece of operations software. The only thing that changes is the length of step four.
- 1
Audit
You paste composer.json into the free audit. We read the PHP and Laravel versions against their end-of-life dates, name the abandoned packages, count the majors between you and current, and say which package fits.
You get
- A one-page report within 24 hours
- The package that fits, with the price attached
- No email wall, no follow-up sequence
- 2
Fixed quote
A one-page scope: what moves, what gets replaced, what we will not touch and why. The price on it is fixed. If we underestimated, the overrun is ours.
You get
- Scope and exclusions in writing
- A named engineer and a start date
- Half the price invoiced now, half on hand-over
- 3
Access and baseline
Repository access, a database copy and the deployment details. We take a baseline — versions, tests, open vulnerabilities — so the hand-over can show exactly what changed.
You get
- Work in your repository from the first commit
- A written baseline of the application
- Credentials in your vault, never ours
- 4
Staging rehearsal
The whole upgrade or build runs on a staging copy first. Tests go green, the deploy is rehearsed, the rollback is written down. Nothing reaches production untested.
You get
- A staging environment that mirrors production
- The test suite passing, with gaps backfilled
- A rehearsed deploy and a written rollback
- 5
Production release
Deployed in a window you choose, with us watching logs, queues and error rates afterwards. Downtime is minutes, and usually none.
You get
- A release window you pick
- Monitoring during and after the release
- A same-day summary of what went out
- 6
Hand-over
Notes your next developer can read: what changed, why each package was replaced, what we left alone and why, and the risks we found but did not touch.
You get
- Hand-over notes in your repository
- A risk register for anything deferred
- The second half of the invoice, and nothing after it unless you choose
After hand-over
Three honest options. None of them is required.
Stop here
Everything is in your repository with notes. Many clients stop after the upgrade and come back when the next end-of-life date approaches.
A care plan
A block of hours a month with a named engineer, a written SLA and a monthly health report, so the application never drifts back. Three-month minimum, then month to month.
More software
The operations software around the app — portals, quoting, stock — scoped and priced the same way: one page, fixed, before work starts.
Questions about the process
How long does the whole thing take?
The audit comes back within 24 hours. An Upgrade Sprint runs seven to ten working days; a Full Upgrade two to three weeks. Custom software is scoped per project, and the scope document states the duration before you commit.
How much of my time does it need?
Repository access and a database copy at the start, a release window you choose, and someone who can answer questions about how the business uses the application — usually an hour or two across the engagement.
What if we find something unexpected mid-way?
We tell you the day we find it, with options. If it is inside the scope, it is our cost. If it is genuinely new work, it goes on a separate line and you decide whether it is in or out.
Do you need the previous developer?
No. We take over abandoned applications regularly. The baseline step exists precisely so we never depend on someone else’s memory.
Step one is free
Paste your composer.json. The audit comes back within 24 hours with the state of the app and the price for step two.
Run the free Laravel audit