Why I Sell Consultancy, Not Just Software

I build and sell AI products. So why do I spend most of my time on services?

As a CTO and CPO I have taken three SaaS platforms from inception to production. Building is the part I love most. And yet most of my week goes into consultancy.

Is that a failure?

Honestly, no. And the reason matters more than the answer.

The organisations I work with are not interchangeable

Most of them are sport startups, international and national federations, pro clubs and smaller academies. Different sizes, and very different operations.

A national federation administering hundreds of members with a handful of staff, and a professional club with a full performance department, will describe their problem in similar language and mean almost nothing in common by it. The words "we need better athlete data" cover two entirely different pieces of work.

Before I can drop an existing product into any of them — SportERP included — they need to understand their own problems properly. Not the surface version. The operational, day-to-day version.

So on goes the consultancy hat, and I start drilling. What do you do, how do you do it, and why is it still done that way?

The aim is simple: value

Any product has to return more value than whatever it replaces, and by a wide margin. Not marginally better. Enough that nobody has to be persuaded.

Implementing SportERP typically drives 10 to 12 times more value per person on the system. Customise it properly around their operations and that goes to 20 to 25 times, which changes the ROI conversation completely.

That gap between 10× and 25× is the entire argument for the consultancy. It is not a service tacked onto a licence — it is the difference between a system people tolerate and one they build their week around.

And it is why discovery is not billable padding. The customisation that produces the second number is only possible if the first conversation was honest about how the organisation actually runs.

Could we do this differently?

For enterprise, I do not think so.

You have to know those organisations personally. Their politics, their funding cycles, who actually decides, and who will be there in eighteen months when the decision needs defending. That knowledge does not arrive in a requirements document, and no onboarding flow extracts it.

I also rather enjoy that part, which I should admit is not a neutral position.

For the smaller clients, the answer is different: a painless self-onboarding system that drives value up and keeps cost down. Right now our clients are all enterprise level. We are also building self-onboarding, designed to keep that ROI high while taking us out of the setup — so that a single coach can feel like a small professional organisation.

Would I ever put the consultancy hat away?

No.

Processes and operations have to be clear before software can be shaped around them. Software implemented on top of an unexamined process automates the confusion and makes it faster and harder to see.

I stopped believing that one solution fits every client. I believe in adjustable, smart systems that fit around you and understand you properly — and that is exactly what we are building at SportERP.

How to tell whether the discovery was any good

There is a simple test, and it does not require you to know anything about software.

At the end of a proper discovery you should be able to name at least one thing you were doing that nobody could justify, and at least one decision that had been deferred so long it had quietly become policy. If the output is a tidy diagram of the process you described in the first meeting, the discovery has confirmed your assumptions back to you at your own expense.

The second test is who was in the room. Operations knowledge sits with the people doing the work, not with the people who commissioned the project, and any process map built without them is a description of how the work is supposed to happen.

What this means if you are buying

If a vendor can quote you an implementation timeline before asking how you currently work, they are selling you a licence and calling it a solution. The questions should be uncomfortable, and some of them should be about decisions you have been avoiding.

The reverse is also worth saying: if a consultant cannot tell you what the software will do once the process work is finished, the process work has no destination. Both halves have to be present. That is why I have not chosen between them and do not intend to.

---

Working out what your operation actually needs before committing to a platform is the substance of my business strategy and innovation work. If the decision is already made and the question is delivery, that is technology implementation — and if you need someone accountable for the whole product and engineering function while it happens, interim CTO and CPO cover.