// How I help

Diagnose. Prioritise. Build. Prove.

Most engagements start the same way: something in the business costs more or takes longer than it should, and nobody can say exactly why. That is the question I answer first — before anyone talks about software.

Diagnose

A structured review of how work actually flows through your business — where time is lost, where cost is duplicated, and which numbers nobody trusts.

I sit with the people doing the work, not just the people describing it, and map the real process end to end. Most of what I find is not in anyone's system diagram: the spreadsheet that reconciles two systems that should talk to each other, the approval that exists because of an incident in 2019, the report three people rebuild by hand every month.

Prioritise

Not every inefficiency is worth fixing. You get a ranked list with the cost of each problem and the cost of solving it, so the decision is yours to make on the numbers.

This is where the accountancy training earns its place. Every finding gets costed — hours, error rates, cash tied up, revenue not collected — and set against what it would take to remove it. Some problems are cheaper to live with, and I will say so rather than sell you a project.

Build

Where technology is the right answer, I design and build it — automation, integration, or a system of your own. Where it is not, I will tell you that instead.

I have built or co-founded seventeen businesses, so this is not a specification handed to somebody else. Often the right answer is smaller than expected: an integration between two tools you already pay for, or a single screen that replaces a spreadsheet. Sometimes it is a system built from scratch, and I have done that too.

Prove

Every engagement ends with a measured before and after. If the change did not pay for itself, that is a finding too.

We agree the measure before the work starts — hours saved, cycle time, error rate, cash collected — and we measure it again afterwards. I would rather hand you an honest number that falls short of the forecast than a case study nobody can verify.

// Why me

Two disciplines that normally sit in different rooms.

A qualified accountant will tell you what a problem costs. A software team will tell you what a fix costs. Very few people can price both sides of the same decision.

I am an accountant by qualification and a builder by inclination, and the combination is the point. The training is what makes me sceptical about a number; the passion for technology-led solutions is what stops the answer being another spreadsheet and another person to maintain it.

That is the whole basis of how I work. The accountancy training means a problem gets costed properly — hours, error rates, cash tied up, revenue not collected — rather than described. Seventeen businesses built or co-founded mean the proposed fix gets costed just as honestly, by someone who has had to build and maintain one.

It also means I am willing to reach the unprofitable conclusion. Some problems are cheaper to live with. Some processes should be deleted rather than automated. You will hear that from me before you hear a proposal.

See what I have built

// Who this is for

Where I am most useful

—

Owner-managed businesses

Where the business has outgrown the systems it started with, and the owner is still the integration layer between them.

—

Professional practices

Accountancy and professional services firms carrying manual work that their software was supposed to have removed.

—

Scale-ups

Teams growing faster than their processes, where headcount is being used to paper over something structural.

—

Founders with an idea

Where the question is not how to build it but whether it should be built, and what the smallest version that earns money looks like.