What I build, and when it is the right thing to build.
The detail you would want before committing to a piece of work: what each kind of project involves, what it typically includes, and what is true of all of them regardless.
Line-of-business applications
The system the work actually happens in — jobs, orders, cases, stock, scheduling, approvals. Modelled on how the business really operates rather than how a SaaS product assumes it does, which is usually why the spreadsheet is still open alongside the software. What you end up with is one place where the state of the business is true.
Internal tools and automation
The repetitive admin that quietly consumes a day a week: invoicing, reconciliation, report generation, data entry, chasing. Automated where the rules are clear, and deliberately left alone where somebody’s judgement is doing real work. Removed rather than reorganised.
Customer-facing portals
Booking, accounts, orders, documents, support. Somewhere your customers can serve themselves at the moment they would otherwise ring you, with the awkward cases — cancellations, part payments, refunds — designed rather than left to an email thread.
Integration and data plumbing
Making the systems you already pay for talk to each other properly: payment providers, accounting, CRMs, logistics. Most of the work is in the failure cases — retries, duplicates, partial writes, and what happens when the other end is down for an afternoon. Done properly, nobody notices it exists.
AI where it earns its place
Drafting, triage, extraction, summarising — the steps in a workflow where a good-enough first pass saves real time. It goes in with a person able to check the result, a record of what it did, and a system underneath that still works if it is switched off. Where a rule would do the job, a rule does the job.
Rescue and rebuild
A system nobody left can maintain, or a half-finished build the last developer walked away from. It gets stabilised and understood first — deploys, backups, the tests that should have existed — then modernised in pieces you can keep using while the work goes on. Starting again from zero is the last resort, not the opening position.
Whatever shape the work takes, these are the same — and they are the parts that decide whether it is still worth having in two years.
Scope in writing, before anything is built
A written plan in plain English: what is included, what is not, and what it costs. It is the thing we both refer back to when something changes mid-build — and something usually does.
One engineer, answerable for the outcome
The person who scopes the work writes it and deploys it. There is no account layer to translate through, and no second team to re-explain the business to halfway through.
Deployed by pipeline, not by hand
Builds run automatically, environments are reproducible, and releases repeat. Nothing lives only on my machine, and nothing goes live because somebody remembered the right sequence of steps.
Everything in your name from the start
Unless we agree otherwise up front, repositories, hosting, domains and third-party accounts are set up in your own name as the work goes, rather than transferred at the end as a favour. Leaving is a decision, not a negotiation.
Not sure which of these you need?
Describe the problem in plain words. If it is not something I should take on, I will say so and point you at who should.