The part of the job we were worried about losing

We spent a while worried that AI would commoditise what we do, and six months in I've come to think that fear was more or less exactly backwards.

We run a Salesforce consultancy, and we've always billed by the hour. Fixed-fee work has a quiet insurance premium baked into it, a margin added on top of the estimate to cover the risk of an overrun, and that never sat well with us; hourly felt more honest, because the client pays for what they actually use and nothing more.

But hourly billing came with a cost of its own, and it tended to land on the client rather than on us. The layer of a project that stops it hurting, the requirements gathering, the documentation, the testing, the mapping of what depends on what, all takes real time, and on a modest budget that time competes directly with the build itself. So for smaller clients we would quietly strip it back, not to protect our own margin but to protect theirs, and the sort of care that every client ought to get became, if we're honest, something only the bigger budgets could afford.

Since October 2025 we haven't really stopped building. The firm now runs on more than 250 tools we've made ourselves, sitting on top of Salesforce and the other systems we work with, though the number itself isn't the interesting part. What matters is that we can act on all of it from wherever we happen to be working, whether that's inside Salesforce, in our own portal, in Slack, or in the tools we write code in, which means the administrative work that used to eat into a client's budget is now, for the most part, handled quietly in the background.

The upshot is that the layer we used to leave out has simply become part of the work. Requirements written down properly, documentation, testing thorough enough that what we hand over holds together, dependencies mapped, dates that move when circumstances actually move, and a sensible view of when a project might finish. This is the sort of attention that used to be reserved for clients who could pay for it as a separate line, and it now arrives without that particular bill attached.

The building itself has changed along the way. Work we would once have delivered as a simple automation we can now build properly, which makes it clearer for the people using it and rather steadier under the bonnet, and because more of it is written as actual code it can be tested, which means it lets clients down less often. The integrations we used to treat warily are perhaps the best illustration: the open-ended ones, where we'd been caught out before and couldn't put a reliable figure on the work, were things we would gently steer a client away from, whereas now we can mostly just take them on. A client wanting their leads to arrive automatically from Facebook or Google Ads was once a slightly nervous conversation, and is now a couple of hours' work that we can commit to without crossing our fingers, and the same goes for Companies House, e-signatures, maps, data enrichment and a growing list of things besides.

A good deal of the documentation and the progress updates we send out are written by AI, and I'm not going to pretend otherwise. The documentation is drawn from the code we've actually built, so it tends to be more complete and more accurate than anything one of us would reconstruct from memory, and a written update that might once have taken the better part of an hour now takes a minute to produce and a couple of minutes to read. Charging a client for the slower version, so that the whole thing feels a little more artisanal, would simply be a waste of their money.

None of this comes for free, though, and this is where I think a lot of people are currently going wrong. When a tool this capable costs almost nothing to experiment with, it becomes remarkably easy to set off in every direction at once and build clever things that nobody will ever use, and we have certainly done our share of that. The scarce resource now isn't the building, it's the judgement about what's worth building, and the problem worth solving tends to be the one it always was: an administrative process that adds nothing to anyone's job, that people find frustrating and easy to get wrong, and that quietly swallows time, especially when the time being swallowed belongs to senior people, whose hours are the last ones a business wants spent on it. Having this technology is a little like being handed the keys to a much faster car, which is marvellous provided you have some idea of where you're going.

What's changed most of all, though, more than any single capability, is the character of the work. When we take a client on, it has never really been for the implementation fee; it's because we want them for the long term, to get properly to grips with Salesforce, to see what it can genuinely do for their business, and to have us alongside them while that happens. That's what a good client relationship looks like from where we sit, and for the most part we managed to deliver it. Not always, though, and when things did go wrong it was rarely the configuration that was at fault. It was the softer things, communication that ran too thin, documentation there was never quite the budget to write, testing we couldn't support in the way we now can, or simply a gap between what a client hoped for and what the money would stretch to. Those are precisely the gaps that have now closed.

We built all of this because it seemed fairly obvious that the technology was going to reshape a great deal, and a technology business that isn't paying attention to that isn't much of a technology business. What has genuinely surprised me is how much of the benefit has ended up with the client rather than with us. The part of the job we were most worried about losing to the machines has turned out to be the part we're perfectly happy to hand over.