Custom software · UK-based · Small scopes
Most businesses have one process that never quite fits the system they bought. The spreadsheet that shadows the real software. The folder of exports someone reassembles by hand every month. Too particular for a SaaS vendor to build, too repetitive to keep doing manually. That gap is what I work in.
Not every job is a fit. These are the signals that one usually is.
The same manual work comes round every week, month or quarter. A one-off problem is rarely worth building for; a recurring one usually is.
The payroll, accounting or management software does most of the job, then stops just short. The work happens in the gap between systems, not inside any one of them.
A spreadsheet, a shared inbox, a manual journal, a naming convention only one person understands. The workaround is the specification: it shows exactly what the software failed to do.
Records that have to be reconstructed months or years afterwards for an audit, a client query, a dispute or a tribunal. Getting the answer right is one problem; evidencing how you got it is another.
A few hundred businesses share the problem, not a few hundred thousand. That's too narrow to attract a funded product team, which is precisely why it stays unsolved.
Being clear about the boundaries saves us both a call.
Deliberately slow at the start. Most of the risk in bespoke software is building the wrong thing quickly.
Not the process in theory — one actual instance, with the awkward parts left in. This is where the requirements really come from.
Before anything is built, I work through a small number of genuine cases by hand and produce the output you'd want. It's the cheapest way to find out whether the idea holds.
Whatever proved genuinely repetitive gets built. Imports, exports and human review first; integrations and dashboards only if they turn out to matter.
Source data, calculations and exceptions stay visible, so anything the system produces can be checked by a person who's accountable for it.
Live commercial products, built and maintained end to end.
CV analysis, document processing and matching inside a commercial HR product. Structured data pulled out of unstructured files, with the handling of edge cases and failures that real operational use demands.
Next.js · TypeScript · Supabase pgvector
Live · jobspaceai.com ↗A consumer platform used by UK school children, covering personalised content generation, subscription billing and the reporting behind them. Built and run as a production service, not a prototype.
Next.js · Supabase · Azure OpenAI · Stripe
primary-story.com ↗It depends entirely on the workflow, so I won't put a number here that turns out to be wrong. Smaller pieces of work are usually fixed-scope; anything larger gets priced once the first manual cases have shown what's actually involved. My day rates are set out on the AI consulting cost page.
That's the assumption I start from. Most of this work sits alongside an existing payroll, accounting or management system rather than replacing it, and usually begins with imports and exports rather than a direct integration. Simpler to build, and far easier to abandon if it turns out not to help.
I can build the workflow and the records around it, but I don't give legal, tax, employment or accounting advice, and the software doesn't either. Anything affecting statutory pay, tax or enforcement gets reviewed by a qualified professional in that field before it's automated, and the output is always something a person checks.
Sometimes, genuinely. If the work happens twice a year, or the time is billable to a client anyway, building software is usually the wrong answer and I'll say so. It's worth doing when the work is frequent, absorbed rather than billed, or when not being able to evidence something carries a real cost.
You do. Code and data are handed over, with a walkthrough so someone else could pick it up. No lock-in to me as a single supplier.
Yes. I'm looking at UK compliance and record-keeping workflows where recent rule changes have moved faster than the software — particularly around evidence trails and audit records. If you handle something like that day to day, I'd genuinely like to hear how you do it, whether or not there's ever a product in it.
Describe the workflow and the workaround. I'll tell you honestly whether it's worth building for.