Laravel Support UK — Rescue, Upgrade and Maintain Live Applications

On this practice it means owning a Laravel application as a product: domain logic, APIs, queues, billing, integrations, deploys and the unglamorous operational work that keeps it supportable. It is not u201cbuilding a website in PHPu201d.

Yes. Takeover is a large part of the work: access inventory, local reproducibility, production stabilisation, then a written risk map. See Laravel Rescue.

That is the default. Inherited, abandoned, agency-built, freelance-built and AI-rushed codebases are all in scope, provided we can get enough access to run the app.

Yes, as a senior counterpart: pairing on upgrades, reviewing PRs, owning a bounded workstream, or covering production while they hire. I will not pretend to be a ten-person bench.

Yes, for applications that are already in production and need a named engineer. See Laravel Support and Laravel Maintenance.

Yes, including multi-version jumps, with tests first and package compatibility as the usual bottleneck. See Laravel Upgrades.

Where the integration is a real data-flow problem (webhooks, queues, idempotency, failure modes), yes. I do not mass-produce connector pages for products I have not implemented.

It depends on whether you are buying a bounded piece of work, a takeover, or a retainer u2014 not a day-rate from a comparison table. There is no fake price list on this site.

Yes when the edge of the work is knowable (an upgrade path, an audit, a defined integration). Takeovers often start as a time-boxed discovery because the repo is the specification.

Yes. Those codebases often boot and even look tidy while missing characterisation tests, webhook verification, and an upgrade story. An audit is usually the right first engagement.

Remote is the default, in UK working hours. Occasional on-site is possible when a kickoff, warehouse floor, or a handover with the last person who still has the keys actually needs it. Written record first; a call when it unblocks something.

Yes, where the product already uses them or they are the honest fit. I also inherit React and Angular front-ends that already talk to a Laravel API. The constraint is the live application, not a stack fashion list.

Yes. Support and deploys follow the hosting you already have u2014 Forge, Envoyer, GitHub Actions, a VPS, AWS u2014 rather than a mandatory platform move. Hosting migrations are a project, not a silent extra on a retainer.

For a genuine business-to-business engagement with a written scope, this is typically outside IR35. Status still depends on how the work actually runs (control, substitution, mutuality). It is confirmed in writing per engagement, not as a website badge.

Yes u2014 billing, portals, operations tools, reporting, and the admin staff actually use. Many of those start as a spreadsheet or a half-finished Filament/Nova screen. If production is already live and unowned, start with rescue rather than a feature list.

It depends on current retainers and whether production is on fire. A takeover or incident can start as soon as access exists. A defined build is usually booked, not started the afternoon of the first email. Ask.

Yes, on the paths that lose money, lock users out, or talk to Stripe/ERP webhooks. Pest or PHPUnit, whichever the repo already uses. A green suite that never hits HTTP is not coverage.