Custom web applications, built to still make sense in five years.
Some businesses need a website. Others need software that happens to live at a web address — accounts, payments, scheduling, dashboards, things talking to other things. That second one is an application, and it's a different job. I build those in Laravel.
Do you need an application or a website?
It's worth being honest about this early, because the answer changes the budget by an order of magnitude. A website presents information — who you are, what you do, how to reach you. If that's what you need, you should not be paying for an application, and I'll tell you so.
You're looking at an application when your site needs to remember things and act on them: someone logs in and sees data that belongs only to them, money changes hands, a booking reserves a slot nobody else can take, a form kicks off a process rather than sending an email. Once state and permissions are involved, you've crossed the line.
Plenty of projects are mostly website with one application-shaped corner. That's fine, and it's usually the cheapest thing to build — a fast static site with one small piece that does real work. I'd rather scope it that way than sell you a platform you don't need.
Why Laravel, specifically
I've been writing software for 30 years, which mostly means I've watched a lot of frameworks arrive as the obvious future and leave as somebody's maintenance problem. That experience has made me conservative in a way I think benefits clients: I pick tools that will still be boring and well-supported when you need a change three years from now.
Laravel clears that bar. It's mature, it's genuinely well documented, it has a large enough community that hiring someone else is realistic, and it handles the unglamorous parts — authentication, permissions, queues, scheduled jobs, database migrations, payments — as solved problems rather than things I invent from scratch on your budget.
That last point is the commercial argument. Every hour I don't spend rebuilding a login system is an hour spent on the part of your application that's actually specific to your business.
The kind of work this covers
Most projects are some combination of these.
Client & member portals
People log in and see only what belongs to them — documents, history, invoices, status. Permissions are the hard part here, and they're worth getting right the first time.
Scheduling & booking
Availability, reservations, reminders, cancellations. Deceptively difficult — the edge cases around double-booking and time zones are where off-the-shelf tools usually give up.
Payments & subscriptions
One-off charges, recurring billing, invoices, failed-payment handling. Card data stays with the processor — that's not a corner worth cutting.
Dashboards & reporting
The numbers you currently rebuild by hand every month. Pulled from the system that already has them, and current whenever you look.
Integrations
Talking to the software you already run — CRM, accounting, email, payment processors, whatever the industry-specific thing is. Usually the highest-value, least visible work.
APIs
A documented interface so a mobile app, a partner, or a future system can use your data without someone copying it into a spreadsheet first.
How I can help
A new application, from scratch
We start with what the thing has to do, not with a feature list. You get a working link early and it stays current, so you're reacting to real software the whole way through rather than to a description of it.
Taking over an existing Laravel app
Your developer moved on, or the agency stopped returning calls. I can pick up an existing codebase, tell you honestly what shape it's in, and keep it running. Sometimes the report is "this is fine, it just needs updating" — that's a good outcome and I'll say it.
Adding to something that works
You don't need a rebuild to get one new capability. If the foundation is sound, the right answer is usually to extend it — and rebuilds proposed by whoever didn't write the original are worth a second opinion.
If you're running the business on spreadsheets, read this part
This is the most common shape a first application takes. A spreadsheet grew into the system of record, then sprouted a second sheet, then a shared folder, then a rule that only one person is allowed to edit it on Tuesdays. It works right up until it doesn't — and the failure is usually someone overwriting a column nobody notices for a month.
The good news is that a spreadsheet is a remarkably clear specification. It tells me what data you actually keep, which fields matter, and where the manual steps are. Those projects tend to go well precisely because you've already worked out the logic — it just needs to live somewhere that enforces it.
You also don't have to move all of it at once. Often the right first step is replacing the one sheet causing the most pain and leaving the rest alone until it earns its turn.
Not sure this is what you need? If your site is mostly pages of information, a fast static site will be cheaper to build, cheaper to host, and faster for your visitors. There's no reason to run a database you don't have a use for.
Tell me what it needs to do
You don't need a spec or a technical vocabulary — describe the problem in your own words and I'll tell you what building it involves. If it's smaller than you think, that's the answer you'll get.
Start a Conversation