Web App Development

Software that fits
how you actually work.

I build custom web applications that take an awkward manual process and turn it into something people are happy to use. That might be managing stock, automating a job that currently eats a day a week, or getting two systems that have never spoken to talk to each other. The aim is the same every time. Something intuitive enough that nobody needs training on it, built to cope with where the business is going rather than only where it is now.

This tends to be for businesses running something on a spreadsheet that outgrew a spreadsheet a while ago. Or juggling three tools that don't talk to each other. Or paying for software that does eighty per cent of what you need and charges extra for the rest.

If you can describe the problem, I can usually tell you fairly quickly whether it's worth building something. I also work with agencies and consultancies who've scoped a project and need somebody to build the back end of it.

I start with questions, not code. Before anything gets built I want to understand the process as it works today, including the bits people do in their heads and the workarounds nobody has written down. That's usually where the useful stuff hides, and it often turns out one build can solve two problems at once.

From there you get regular check-ins and review points rather than a long silence and a big reveal. On bigger systems I'll break the work into phases so you've got something usable early instead of waiting for the whole thing.

I build on Laravel. You may well not have heard of it, and that's absolutely fine. It powers well over a million sites and it's the most widely used framework of its kind, for good reasons. Solid security, a huge ecosystem of tested tools, and enough popularity that finding another developer later is never a problem.

Where a project needs to talk to things you already run, payment providers, stock systems, accounting, that all gets worked out at the design stage rather than discovered halfway through the build.

How a build runs

The exact shape depends on what you need, and bigger systems get broken into phases, but every project I take on runs roughly like this.

01. Discovery

We sit down, in person or over a call, and go through what you're trying to fix, where the current process falls over, and what you'd want the system doing in a year or two. This is also where I'll point out the opportunities you might not have spotted.

02. Design

This covers the interface, but just as importantly the data. How information gets stored, how it moves from one place to another, and which external services need to be part of it. Get this right and everything after it is easier.

03. Development

Depending on the size of the job this happens in one sweep or across several phases. Either way you get regular check-in points and review cycles, so what's being built is what you're expecting and nothing goes quiet for weeks at a time.

04. Testing

Testing runs throughout, but this is your window to put the system in front of the people who'll be using it every day. They'll find things nobody else would, which is exactly the point of it.

05. Launch

More a moment than a phase, and one I've done hundreds of times, so downtime stays at the absolute minimum. Also a fair excuse for a small celebration.

06. Support

Bespoke systems tend to need more of an ongoing relationship than a website does. Some people take it from here, some want me on hand as the business shifts and the system needs to shift with it. Whatever suits.

Proof

Here's one I built earlier:

Woodpecker Trade

Woodpecker Trade: Bespoke Trade Portal

A bespoke Laravel trade portal for sample enquiries, ordering and order fulfilment. Built with StationRd so trade customers could request samples, check minimum order quantities and place orders themselves, with a calculator that turns a room size into a pack quantity and live stock feeds behind it.

Read the full story →

"Alex is that rare type of person who is a full stack dev that can work well with clients, and bridge the gap between business function teams, UX and design teams and delivery, with ease, professionalism and attention to detail."
Martyn Kelly, Founder, MK/A
Frequently Asked Questions

Some things people often ask me:

How much does a web app cost?
More than a website, and probably less than you're fearing, but it genuinely depends on scope. I'd rather scope it properly and give you a real number than guess at one now and be wrong in either direction.
Can it connect to the systems we already use?
Usually. Accounting, stock, CRM, payment providers, most things have a way in. Working out which and how is part of the design phase, before anything gets built on top of it.
What if we need it changed later?
That's expected, and it's why I build on standard tools. It's your system, so I can change it or another developer can pick it up. Nothing is locked away.
Who owns the code?
You do. Once the final invoice is paid, the code and the intellectual property are yours.
Do we have to build the whole thing at once?
No, and often you shouldn't. Building the part that hurts most first gets you value early and teaches us both a lot before the rest is committed to.
Next Step

Got a process that needs fixing?
Leave me a message and tell me what you're working on, and I'll tell you honestly whether I'm the right fit.

People who trust me