Five tools that don't talk
Each solves a piece, none share data, and somebody copies between them every morning.
[ Development / Custom Business Software ]
Off-the-shelf software is cheap until you are paying for five subscriptions, exporting to spreadsheets to make them talk, and paying someone to key the same data in twice. Custom software fits the way you already work.
Fixed scope · Working version in weeks · You own the code
[ Built for businesses like these ]
[ Symptoms ]
Custom software becomes worth it at the point where the workarounds cost more than the software would.
Each solves a piece, none share data, and somebody copies between them every morning.
A file one person truly understands, emailed around in versions, with no audit trail and no real backup.
Staff spending hours on a sequence that never changes and could be a single button.
A licence per person for software where your team uses a fraction of the features and none of the ones they need most.
How many jobs are open, what is overdue, which customer is actually profitable — all answerable only by hand.
The thing you do differently from competitors is exactly the thing generic software refuses to support.
[ How it works ]
I sit with the people who do the job and write down what actually happens, including the exceptions nobody documents. You get a written scope, a fixed price and a delivery date before development starts.
The smallest version that replaces real work, shipped to a staging site you can use. You give feedback on something running, not on a wireframe.
Data migrated from whatever you use now, staff trained, documentation written. Then improvements based on what real use reveals.
[ What actually changes ]
Different industries, same underlying mechanics: a diary that must not clash, money collected reliably, and one record instead of four.
[ Example engagement ]
A services business tracking jobs in a spreadsheet, invoices in one tool and customer notes in another, with a member of staff reconciling all three daily.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
[ Free · no obligation ]
Describe how you work today. If an off-the-shelf product would serve you better and cheaper, I will name it instead of selling you a build.
[ Pricing ]
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
It depends entirely on scope, which is why the first step is mapping the work rather than quoting blind. What I will commit to is a fixed price agreed in writing before development starts, and a first scope small enough to deliver something usable in weeks rather than a year.
Very often, yes — and I will tell you so. Off-the-shelf wins when your process is ordinary. Custom wins when the workarounds, per-seat licences and manual re-keying already cost more than a build would, or when your process is the thing that makes you competitive.
Almost certainly. The list is examples, not limits. Underneath, most business software is the same handful of problems — scheduling something scarce, tracking what is owed, keeping one record instead of four, and getting the right information to the right person. The industry changes the vocabulary, not the engineering.
Handled as sensitive from the start: role-based access, full audit logging, encryption in transit and at rest, hardened servers and tested backups. My background is in security engineering as well as application development, which is exactly where that matters. For healthcare work I will also be explicit about which obligations are yours rather than the software's.
They will, because seeing something real changes what you want. The build is structured in stages so changes land between them rather than mid-flight. Genuine additions get re-quoted honestly rather than absorbed silently and resented later.
You do, completely. The code lives in your repository, uses no licence you cannot renew, and any competent developer can pick it up. There is no lock-in and no per-seat fee to me, ever.
A fair question for any solo engineer. The mitigation is that everything is version-controlled, documented and built with standard, widely-known tools, so another developer can take over without archaeology. That is a deliberate design goal, not an afterthought.
Yes, and it is common. I start with a review and an honest assessment of whether finishing it costs less than restarting, with the price of each option laid out.
[ Related services ]
[ Let's talk ]
Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.