We Delivered the Same Salesforce Project Twice — Once Without AI, Once With
The short answer: build work compressed 4.68x. Everything else compressed 1.70x. In 2024 we delivered a Sales Cloud data-model project for a US airport advertising company using three people and no AI. In 2026 we delivered the follow-on phase for the same client, on the same data model, with Claude in the loop. 83.00 hours of hands-on build work became 17.75. Meetings, discovery and refinement went from 52.25 hours to 30.75.
Almost everything published about AI and consulting is a projection. This is not. It is the same firm delivering to the same client in the same org, with both sides measured from the same timesheet system.
We are publishing it because the interesting number is not the headline. It is the gap between the two ratios.
Key Takeaways
- Hands-on build work compressed 4.68x (83.00 hours to 17.75)
- Non-build work — meetings, discovery, refinement, coordination — compressed only 1.70x (52.25 to 30.75)
- Blended across the whole engagement, the figure is 2.79x, and that blended number is the one most likely to mislead you
- Calendar time went from 42 working days to 15
- The 2026 phase deployed to production with 17 of 17 schema components, 297 of 297 records migrated with zero failures, and 177 of 177 records reconciling with zero mismatches
- If a vendor offers you a flat percentage discount “because AI”, they are averaging across two very different kinds of work
The project, both times
The client sells advertising across US airports. Their Salesforce org tracks locations, the advertising inventory in each one, and the contracts against that inventory.
2024. A Sales Cloud data model and profile build. Three people, no AI assistance of any kind. Delivered 25 April to 12 July 2024 across 42 logged working days. 135.25 human hours.
2026. The follow-on phase against the same objects, extending the model and migrating the historical data onto it. Claude in the loop throughout. Delivered 23 July to 17 August 2026 across 15 logged working days. 48.50 human hours.
Same firm. Same client. Same data model. Same timesheet system on both sides, which is the part that makes the comparison worth anything.
The numbers
| 2024 · human only | 2026 · AI-assisted | Change | |
|---|---|---|---|
| Build work | 83.00 hrs | 17.75 hrs | 4.68x |
| Everything else | 52.25 hrs | 30.75 hrs | 1.70x |
| Total | 135.25 hrs | 48.50 hrs | 2.79x |
| Logged working days | 42 | 15 | 2.80x |
“Build work” means hands on the org: schema, automation, deployment, migration, testing. “Everything else” means meetings, discovery, refinement, documentation and coordination — the work that happens with other people rather than in the org.
On the machine side, the 2026 phase ran across 22 working sessions and 113 delegated agent runs, totalling roughly 47 hours of serial machine time. It executed 302 deployments and 1,123 org queries. That machine time is not free, but it is not a person’s time either, and it ran unattended for long stretches.
The gap is the finding
A 4.68x on build and a 1.70x on everything else are not the same story told twice. They are two different stories, and averaging them into “2.79x” destroys the useful part.
Build work compresses hard because it is the part with a specification. Once the decision is made, writing the metadata, generating the deployment, building the migration and checking the result is mechanical, verifiable work — exactly the shape of task that an AI agent does well under supervision.
Non-build work barely compresses because it is the part where the decision gets made. A stakeholder call takes as long as it takes. Refining a requirement with somebody who has not yet decided what they want takes as long as it takes. Nobody has automated the meeting.
This has a direct consequence for anyone buying Salesforce work:
The savings land where the specification is clear, and nowhere else. A project that arrives with a tight, agreed scope compresses toward the 4.68x end. A project that arrives as “we need to fix Salesforce” sits closer to 1.70x, because most of its hours are in working out what to build rather than building it.
That is also why a flat “AI discount” across a whole statement of work should make you suspicious. A vendor offering 40% off everything is either wrong about their own delivery mix, or they have padded the parts that do not compress to fund the discount on the parts that do.
Did quality hold?
That is the obvious next question, and it is a fair one, because a faster number means nothing if the work is worse.
The 2026 phase went to production on 12 August 2026. On go-live:
- 17 of 17 schema components deployed
- 297 of 297 records migrated, zero failures
- 177 of 177 records reconciled against the source, zero mismatches
- Zero errored automation runs
That is not a claim that AI-assisted delivery is inherently safer. It is a claim that on this project, at this compression, the verification numbers came back clean — and that we checked them rather than assuming.
What we are not claiming
We would rather state the limits than have you find them.
This is one project. One client, one org, two phases. It is a control group, which is rare and useful, but it is a sample of one and we are not going to pretend otherwise.
The two phases were not identical in scope. They were the same data model and the same kind of work, but a follow-on phase is never a rerun of the original. Some of the 2026 speed is genuine familiarity with an org we already knew.
Our human hours are a floor, so the ratios are if anything overstated. Nine days in the 2026 phase had machine activity with no matching timesheet entry. Real human hours were therefore somewhat higher than 48.50, which makes the true compression somewhat lower than 4.68x. We are publishing the number that makes us look worse rather than the one that makes us look better, because the alternative is a figure that falls apart the first time somebody checks it.
We are not publishing the commercial figures. What we charged for each phase, and what the margin was, are our business. The hours and the method are the part that is useful to you.
The compression is not free. Machine time has a cost, supervision is a real skill, and an agent pointed at a badly-understood org produces confident nonsense faster than a person does. The 4.68x is what the tooling does in the hands of somebody who already knew how to do the work.
Frequently asked questions
Does this mean Salesforce projects should cost 4.68x less? No, and that is the most common misreading. Build work compressed 4.68x; the whole engagement compressed 2.79x, and the non-build half only 1.70x. What a project should cost depends on its mix. A tightly specified build is mostly the compressible kind of work. A discovery-heavy transformation is mostly not.
Why did the meetings not compress? Because they are meetings. AI can prepare for one, summarise one and write up the actions from one, and that is where the 1.70x came from. It cannot shorten the part where two people work out what the business actually needs.
Is this Agentforce? No. This is Claude used as a delivery tool by the consultancy — writing metadata, building deployments and migrations, querying the org, drafting documentation. It is about how the work gets done, not about AI features shipped to the client’s users. Those are separate questions and they get confused constantly.
How were the machine hours measured? From the session transcripts, reconstructed into serial and elapsed time and classified by what each run actually did rather than by what it was asked to do. Human hours come from the same time-tracking system used on both engagements, which is what makes the two sides comparable.
Would you do this on a regulated or validated org? With more control, yes, and more slowly. The compression comes from doing mechanical work fast under supervision, and a validated environment adds verification steps that do not compress. We would expect a much smaller multiple there, and we would rather say so upfront than discover it mid-project.
Can we see the underlying data? Not the client’s, no. We are happy to walk through the method and the categories on a call, and to run the same measurement on an engagement of yours so you have your own number rather than ours.
Estarei implements and manages Salesforce for mid-market companies. We have been building with Claude since 2025 and running it against client Salesforce orgs since January 2026. If you want to know where the compressible work actually is in your own backlog, book a free consultation.
James Moore
Head of Delivery & AI Automation · Estarei
James leads delivery and AI strategy at Estarei. A Salesforce-certified architect and developer, he has designed and delivered implementations across Sales Cloud, Service Cloud, Health Cloud, and Agentforce for mid-market and enterprise clients.
Ready to talk Salesforce?
Get a free 30-minute consultation with a certified Salesforce architect.
Book a Free Consultation