Built by operators, not technologists

DAY ONE’s design constraints came from running services businesses, not from building software. That is a claim worth stating carefully, because the honest version includes what the first attempt got wrong.

Most platforms in this category are built by technologists who studied the problem. Ours was built by two people who had the problem, solved it badly for themselves first, and then spent years working out which parts of that solution were transferable and which were only true of us.

What we built for ourselves

Before DAY ONE I ran a Salesforce consultancy called Cludo. We founded it in 2016 and grew it past fifty people over about seven years.

In the early days, before client work filled every hour, I started building an operating system for ourselves inside Salesforce. The concept was simple and it has not changed since: the whole value chain lives in one connected model. You win the work, you deliver the work, you process the work — same model throughout. Nothing re-keyed, nothing reconciled after the fact.

What that prototype did for Cludo is the part of the story I still value most. It ran a fifty-person firm on almost no administration. One person kept the books, roughly four hours a week, and that was the entire administrative overhead of the business. Sales and delivery sat on the same record. Forecasting was not a monthly spreadsheet ritual — it fell out of the process.

And what was wrong with it

It was, admittedly, not elegant. Mark has called it my hacky operational platform, and he is not wrong.

It was built incrementally over seven years, in gaps between client projects, which meant the data model was piecemeal and in places fragile. Decisions made in year two constrained year five. Things worked because I knew where the bodies were buried, not because the design was sound.

More importantly: it worked because one person built it for one firm he understood completely. Every assumption it made about how work was sold, staffed and billed was an assumption about Cludo specifically. The hard part of turning that into a product was everything those assumptions did not survive — other firms bill differently, structure engagements differently, approve differently, and have opinions about all of it.

That is the honest version. A founder story with no failure in it is a brochure.

What each of us brought

Mark Layzelle and I first worked together at GE, decades ago. He went out on his own about ten years back, consulting in operating-model design and transformation advisory, and came into Cludo as our transformation programme manager. He was with us on and off for around five years, so he came to know the prototype intimately — and being a lean six sigma practitioner by instinct, he understood exactly what it was doing and why it mattered.

We divide the work cleanly. I own product and technology. Mark owns operations and experience, and carries the financial governance — the controls, the internal checks, and the piece he is proudest of: the invoicing engine, with traceability running back to an individual timesheet record.

Mark had watched the same fracture repeat from his side of the table: sales sell something captured in a Word document or a standalone deck, delivery inherits it and reinterprets it, and finance inherits that and reconstructs what was sold, what was delivered and what may legitimately be billed. I had watched it from inside a firm that had accidentally solved it. Same diagnosis, arrived at from opposite directions.

Why the difference shows up in the product

Operators and technologists optimise for different things, and you can usually tell which built a platform within a week of using it.

A technologist-built system asks what the software should be able to do. An operator-built one asks what has to be true on the last working day of the month. Those produce different designs. The second one treats the invoice as the point of the exercise and works backwards from it, which is why our budget model holds at contract, milestone and task level rather than at whichever level was easiest to build.

It also changes what we do after the sale. Some vendors optimise for the contract and leave the client to extract value from another tool. We came out of consulting, so the instinct is to argue with the operating model rather than just configure around it — which occasionally means telling a firm that the thing they have asked us to automate should not exist.

Our first customer was Rowland, a communications firm of around seventy people who knew what we had built at Cludo. They backed the vision and became customer one, and have run on DAY ONE since. What happened there is the evidence that the idea travels beyond our own walls: time-to-cash 29 per cent faster, administrative time down 46 per cent, a 2.5 per cent improvement in margin, and a return on investment inside roughly three months, live in four weeks. The full account, including the parts that were not straightforward, is in the Rowland case study.

What this costs you, not us

An operator-built platform has opinions, and opinions are a constraint. If your firm wants a blank canvas that will model any commercial structure you can imagine, we are the wrong choice — the structure is the product, and a good deal of the value comes from what it will not let you do.

It also means we are a small company with a deliberate scope. We have done the hard, slow, expensive part — building a governed product — and we are honest that the work ahead of us is distribution. A firm that needs a global support footprint and a decade of vendor track record should weigh that seriously rather than take our word for it.

And the founder story is not a guarantee. Having run a services firm makes us better at understanding yours; it does not make us right about yours. The useful test is not our history. It is whether the specific commercial decisions your firm makes — how you price, gate, approve and bill — can be held as data in the system, and that is worth checking against your own edge cases before anything else. Our about page covers the rest of the background, and the quickstart page sets out how we sequence the first engagement.