Custom web applications
When the spreadsheet stops coping and off-the-shelf doesn't fit.
Booking systems, internal tools, customer portals, payment handling. Built for how your business actually works, hosted in the UK, and supported by the person who wrote it.
Be honest with yourself first
Custom software is the right answer less often than people selling it suggest.
If there is a well-established product that does ninety per cent of what you need, buy it. It will be cheaper, it will be maintained by a company larger than mine, and you will not be the only person who knows how it works. I will tell you when that is the situation, and I would rather lose the work than build you something you did not need.
Custom is worth it when the thing you do is genuinely yours — a process no product models properly, a workflow the business has grown around, or a job where the off-the-shelf option would mean changing how you work to suit the software. That is when building pays, and it usually pays quickly.
Recent build
A ticketing and booking system for a 400-guest charity gala.
BNI Dorset run a cross-chapter black-tie fundraiser at The Cumberland Hotel in Bournemouth. Selling the tickets by email and spreadsheet was not going to survive the first busy week.
The result is a full booking platform rather than a payment button. It handles individual seats and sponsored tables of ten, tracks remaining capacity live so the page can say how many seats are genuinely left, and takes card payments through Stripe.
The parts that matter to the organisers are the unglamorous ones:
- Dietary requirements and allergies per guest, collected at booking rather than chased by email in the final fortnight
- Guest names can be left until later. Book ten seats now, fill in who is sitting in them when you know — which is how table sponsors actually buy
- Self-service booking management, so changes do not arrive as a committee member's inbox problem
- Bank transfer as well as card, with a reference issued per booking so payments reconcile without detective work
- Invoices for sponsored tables, so a business can treat the table as a marketing cost
None of that is technically difficult. All of it is the difference between a system that sells tickets and one that also saves the organisers their evenings.
Taking on what you already have
You don't have to have started with me.
More businesses than you would expect are now running on something built in-house — often with an AI assistant, often by somebody whose job is not software. It works, which is exactly why it becomes a problem: people start depending on it before anybody asks where it lives or who can get into it.
An electrical engineering company had built two applications themselves and were running them locally on a machine in the office. They did not need rewriting. They needed a proper security layer, somewhere sensible to live, and somebody responsible for them. I added the first, built the second, and now provide the third.
If something in your business sounds like that, it is worth a conversation before it becomes an incident. The work is usually smaller than people fear.
What it's built with
Deliberately unfashionable choices.
The stack
PHP and Laravel, on MySQL or PostgreSQL, with Python where a job genuinely suits it. Mature, heavily documented, and known by a large number of developers who are not me.
Why that matters to you
If you ever want to move this work elsewhere, you will be able to. Nothing here depends on a framework that might be abandoned, or on knowledge that only exists in my head.
How it works
Fixed price, agreed before anything starts.
Development is quoted as a fixed price, the same as every other project I take on. You know what it costs before it begins, and it does not change because the work took me longer than I estimated. That is my risk to carry, not yours.
Hosting and ongoing support are separate and ongoing, and draw from the same monthly arrangement as everything else I do — no separate retainer, no annual fee attached to the application.
Development standards
The test I build to: could somebody else pick this up?
When you commission software from a small supplier, there is a question you are entitled to ask and most people are too polite to say out loud. What happens if you are not here?
It is the right question, and it is the reason a lot of businesses settle for a product that does not fit rather than one that does. So here is the answer, in the form of how the work is actually done rather than a reassurance.
- Every project lives in a private GitHub repository that you have access to — from the first commit, not handed over at the end. You can see the work as it happens, and the entire history of it is yours to take.
- Documentation is written as part of the work, not promised for later and quietly dropped when the deadline arrives. How it is built, how it is deployed, what it depends on, and why the decisions were made.
- The standard is a handover test. Could another developer take this repository, read it, and carry on? If the answer is no, it is not finished, whatever the application appears to do.
That is a deliberately uncomfortable standard to hold yourself to, because it removes every advantage a developer gets from being the only person who understands something. I think that advantage is a bad thing to build a business on. If you ever want to take the work elsewhere, you should be able to do it in an afternoon, without a negotiation and without reverse-engineering anything.
It is the same principle as the deliberately unfashionable technology choices above, and as the servers being documented as part of the build. Three different decisions, all of them answering the same question: can you leave?
Start by describing the problem.
Not the system you think you need — the thing that is taking too long, going wrong, or being held together by one person who knows the spreadsheet. No charge for the first conversation.