Custom software and internal tools
Software built around how your organisation actually works, from internal tools and APIs to data pipelines. AI only where it earns its place.
The problem
Some processes live in spreadsheets, email threads and one person’s memory because no product fits them. The usual options are bending the process to a SaaS tool that almost fits, or paying a large agency for a large project. For many problems, a small, well-built piece of software is the better option.
What gets built
- Internal tools: admin panels, review queues, dashboards and workflow tools for a specific team.
- Data pipelines: moving, cleaning and reconciling data between systems on a schedule or on events, with checks that fail loudly.
- APIs and integrations: connecting systems that were never designed to talk to each other.
- Specialised software: calculation engines, scientific or signal-processing tools, and domain-specific applications.
How it is built
Boring, well-understood technology by default. Tests for the parts that matter, documentation that someone else can follow, and deployment you can run without me. You own the code. Where a language model genuinely helps with one step, it is used for that step and nowhere else.
When this is the wrong tool
If an existing product covers 90% of the need at a reasonable price, buy it and adapt the process. Custom software has an ongoing maintenance cost, and it should only be built when the fit or the economics justify it. That judgement is part of the first conversation.
How an engagement starts
With a short scoping exercise: what the process is today, what must change, and the smallest version that would be useful. That version gets built first.
Have a project like this?
- I read your message and reply personally, normally within two working days.
- Any questions are clarified by email. A short call only if required.
- A written proposal for a fixed-scope first step, with a fixed price.
Evidence and further reading
When not to use an LLM
A practical test for deciding whether a step in your system should be a language model, ordinary code, a search index, or a person.
How an engagement works
Every project starts small and fixed in scope, so you see evidence before you commit to more.
Feasibility assessment
A short, fixed-scope look at your problem, your data and the options.
A written assessment and a clear recommendation, including "don't build this" when that is the honest answer.
Prototype
A working system on your real data, not a demo on someone else's.
The prototype plus an evaluation report with measured results.
Build
The production system, integrated with what you already run.
Tested, documented code that you own, with a proper handover.
Support
Monitoring, evaluation reruns and improvements as your data changes.
Agreed scope and response times, no lock-in.