Laravel & PHP applications
Laravel applications built to be handed over.
Customer portals, subscription billing, internal tools and the APIs that join them to everything else you run. Typed, tested where it matters, and documented well enough that you could replace me without drama — which is the only honest definition of a finished project.
01ScopeWhat I build
The kinds of application this usually means.
Customer and partner portals
Somewhere your customers log in to see their own data — orders, invoices, documents, usage, entitlements. The hard parts are rarely the screens. They are the permission model, the audit trail, and what happens when one account needs six users with different access.
Subscription and invoice billing
Plans, proration, credit terms, dunning, tax, PDF invoices and the reconciliation report your finance team actually trusts. I build billing against a double-entry ledger rather than a running total, because a running total is impossible to audit the day somebody disputes a charge.
Internal tools that replace a spreadsheet
The workflow currently living in a shared spreadsheet, with the version conflicts and the one person who understands it. Turning that into an application is often the highest-return work a business can commission, and usually the smallest.
APIs and integrations
REST or GraphQL endpoints for your own front end, your mobile app, or a partner. Plus the integration work joining Laravel to whatever else you run — an ERP, a CRM, a payment provider, a warehouse system.
Taking over someone else's codebase
I start these with a read-only week: run the tests if they exist, map the domain models, and write up what I find — including the parts that worry me. You get that assessment whether or not you continue, so you are never paying just to be told the code is fine.
02MethodWhere the money goes
What I spend your budget on.
Most application budgets are lost in the same three places, so this is where the care goes rather than on the parts that demo well.
The data model, before anything else
Schema decisions are the ones you cannot cheaply reverse. A migration that splits one table into three, eighteen months in, with live customer data and a reporting suite pointed at it, is the most expensive day in a project's life. I would rather spend two extra days on the schema than two extra weeks on that migration.
Anything that touches money or permissions
Billing, roles and anything writing to a ledger get tests. Not for a coverage badge — so that the next person can change your pricing logic without silently breaking last quarter's invoices. Everywhere else I test the awkward paths and leave the obvious ones alone.
What happens when something else breaks
An integration is not finished when it works. It is finished when it behaves sensibly while the other system is timing out. That means queued jobs, bounded retries, idempotency keys, and a failure log a human can read — so a supplier's bad afternoon delays your data instead of losing it.
None of this is exotic. It is ordinary, careful Laravel. The difference it makes shows up in year two, which is exactly when most agencies have moved on and you find out what you actually bought.
03HandoverWhat you own at the end
The deliverable is not just the running app.
- 01
The repository
- In your organisation, not mine, from the first commit. History intact, with commit messages that explain why, not just what.
- 02
An architecture write-up
- A few pages covering the domain models, the decisions I made and the alternatives I rejected and why. This is the document that saves your next developer a fortnight.
- 03
A runnable local environment
- A new developer should get from clone to working application in under an hour, with seeders producing realistic data. If that takes a day, the project is not finished.
- 04
Deployment and rollback notes
- How it deploys, what the environment variables are, where the backups go, and how to roll back at two in the morning without calling me.
04QuestionsAsked often, answered plainly
Things people ask before hiring me.
Should this be a Laravel app or a WordPress site?
If the main job is publishing pages that non-technical people edit, WordPress is usually cheaper and faster. If the main job is users logging in and doing something — ordering, booking, approving, reporting — that is an application. Forcing an application into WordPress generally costs more across two years than building it properly once.
Can you take over an existing codebase?
Yes, and it is a good chunk of my work. It starts with a read-only week producing a written assessment: what is there, what is risky, and what I would do first. You keep that document whatever you decide next.
Do you write tests?
On anything involving money, permissions or data integrity, yes. I do not chase a coverage percentage — a suite full of tests asserting that getters return values is a maintenance cost pretending to be quality. The suite exists so somebody can change your billing without breaking it.
How do you handle deployment and hosting?
Whatever you already have — a VPS, Forge, Ploi, Vapor, containers. If you have nothing yet, I will recommend the simplest thing that fits your traffic. For most business applications that is one well-configured server with managed database backups, not a cluster.
Can you integrate with our ERP or CRM?
Usually. The real question is never whether it is possible but how it behaves when the other system is slow or down. Queued jobs with bounded retries and a readable failure log, so their outage delays your data rather than losing it.
What if I need changes after launch?
You own the repository and the documentation, so you can hire anyone. If you would rather keep me, I offer a monthly block of hours. What I try to avoid is being structurally necessary — an application only I can maintain is a liability for you, not a moat for me.
Next step
Describe the workflow you want to replace.
Even a rough description is enough for me to tell you whether it is a two-week job or a two-quarter one — and which parts you could skip in version one.