Why we built on Salesforce, and what list views could never do

A list view is a way of looking at records. It is not a way of running a business.

That sentence is not a criticism of Salesforce. Salesforce list views do exactly what they were designed to do, which is show you a filtered set of records quickly. The mistake is treating that as an operating surface for professional services work, and then concluding — when it fails — that the platform was the wrong choice.

The misdiagnosis

Firms that have outgrown their list views usually describe the problem as a reporting problem. They cannot see utilisation clearly, WIP is hard to read, the pipeline view does not tie to the delivery view. So they build more views, more reports, more dashboards.

The problem is not that the records are hard to see. It is that the records do not relate to each other in a way that makes an answer possible.

A list view can show you fifty projects. It cannot tell you whether the time on project thirty-one was approved, whether the contract permits billing it, or which version of the scope delivery is actually working to. Those answers require the objects to be joined by governed relationships and rules — and if they are not, no view over the top will produce them. Reporting on top of disagreement is not control.

Why we built on Salesforce anyway

Before DAY ONE, we ran a Salesforce consultancy called Cludo — founded in 2016, grown to more than fifty people over roughly seven years. In the gaps between client projects we built an internal operating system inside Salesforce: win the work, deliver the work, process the work, all on one connected model.

It was, candidly, not elegant. Mark has called it a “hacky operational platform” and he is right. It was built incrementally over seven years, so the data model was piecemeal and in places fragile.

But it worked. One person kept the books for a fifty-person firm, about four hours a week, and that was very nearly the whole administrative overhead. Sales and delivery sat on the same record, so nobody had to reinterpret a proposal or reconstruct what had been agreed. Forecasting fell out of the process rather than being assembled monthly in a spreadsheet.

What that experience settled was which layer the value lives in. Not the view. The model.

What the platform gives us that we would otherwise have to build

Building on Salesforce means the governance layer is not ours to invent. Role-based access, permissions, multi-factor authentication, audit history, uptime and scale are platform properties — the specifics are set out on our security and governance page.

That matters more for a two-founder product company than it sounds. Every hour not spent rebuilding an identity model is an hour spent on the commercial spine, which is where the actual difficulty is.

It also means integrations do not create a second truth. If a tool connects to Salesforce, it can generally connect to DAY ONE, and the operating record stays governed rather than forking into a parallel copy. The patterns for that — replace, coexist, or phase — are described on the integrations page.

And it means firms already on Salesforce are not asked to abandon a platform they have invested years in. On Salesforce; works with your Salesforce org, or available as a bundled edition if you don’t use Salesforce.

What a governed model does that a view cannot

The difference is concrete rather than philosophical.

An engagement carries its billing rules from the point it is quoted. Time entered against it inherits those rules, and approval is a state on the record, not an email. Change orders attach to the same engagement rather than living in a revised Word document. WIP is composed of entries that each link back to the work, the approval and the contract clause that permits billing.

So when someone asks where a number came from, the answer is a traversal, not an investigation. The piece of the product Mark is proudest of is exactly this: the invoicing engine, with traceability running back to an individual timesheet record.

None of that is a view. All of it is structure the view then makes legible.

The counterweight

This approach has a real cost and it is worth naming plainly.

Building on Salesforce means you inherit Salesforce — its licensing model, its administration burden, and its learning curve for anyone who has not used it. A firm that wants a lightweight standalone tool and has no interest in a platform will find this heavier than it wants, and should say so early rather than halfway through an implementation.

There is a second cost. Carrying commercial rules through the chain means agreeing those rules before delivery starts — what is billable, who approves, what happens when scope moves. That is genuine up-front work, and some firms will prefer to keep the flexibility of deciding later. That is a legitimate choice; it just means the reconciliation gets paid for at month end instead.

Where this leaves list views

We still use them. A well-built list view over a governed model is genuinely useful — you can filter, sort, drill into an engagement and see its financial position without leaving the page.

The order of operations is the point. The view is worth building once the model underneath it can answer questions. Built first, over records that do not relate, it produces a faster way to look at a disagreement.

If your reporting keeps improving while trust in the numbers does not, the problem is one layer down. Our scoping and quoting page covers where the commercial rules get set, which is where the chain either holds or starts to fray.