Small Salesforce Projects Nobody Wants to Quote

Small Salesforce projects are the hardest kind to get done. Not because they’re technically hard — most of them are a few hours of work for someone who knows the platform — but because nobody in the services market is built to sell you a few hours. You email three consultancies about a roll-up field and a routing tweak. Two never reply. The third offers a discovery call, a scoping document, and a minimum engagement many times the size of the thing you asked for. So the request goes back on the list, where it joins the other nine.

That list is the real story of Salesforce inside most companies. Not what the platform can’t do. What nobody will quote.

The job is three hours. The engagement is three weeks.

A small Salesforce build almost never arrives alone. Around it sits intake, a scoping conversation, a statement of work, a security review of the partner, provisioning org access, a kickoff, and — the expensive one — context loading. Somebody has to learn enough about your org to touch it safely: your objects, your automation, the three fields that look identical and mean different things, the trigger from 2019 nobody wants to explain.

None of that shrinks when the build shrinks. Three hours of actual work can carry ten or twelve hours of everything else. Price the whole package at market rates and the “small” job costs several times what the client thinks is reasonable — so the shop either rounds it up into something big enough to justify the wrapper, or it passes.

Why the minimum exists, and why it isn’t greed

It’s tempting to read a declined request as arrogance. It usually isn’t. Run the arithmetic from the other side of the table.

A shop that takes ten three-hour jobs in a month runs ten intakes, ten scoping calls, ten context loads, ten rounds of QA, and ten invoices — for the revenue of one modest project. Utilization is lumpy: you hire developers in whole developers, and a calendar full of fragments is harder to staff than one full engagement. There’s risk, too. Touching an unfamiliar production org for three hours is more dangerous per hour than working in an org you’ve lived in for a month, because you have less of it in your head.

Minimums, retainers, and block-hour packages are all the same defense against the same problem. They’re rational. They’re also why your four-hour fix has been on the roadmap for a year.

What actually gets declined

The pattern is easy to recognize once you’ve seen it. Small, specific, and unglamorous:

A roll-up the report builder can’t assemble because the relationship is a lookup rather than master-detail — a genuinely small build that master-detail conversion is the wrong answer to. A cleanup of forty thousand records where the rule lives in someone’s spreadsheet muscle memory and the CSV round-trip has become a monthly ritual. Lead routing with three real exception clauses that the assignment rules table can’t express. A field the process needs that would never survive a business case. The integration to the one system your operations actually run on, currently bridged by a person copying values between tabs.

I wrote a longer list of Salesforce problems worth fixing earlier this month, and the common thread across all of them is the same: none are hard. All are specific. And specific is exactly what makes them expensive to buy.

The rate card is not the problem

It’s worth being precise about where the cost actually sits, because “Salesforce work is expensive” is the wrong diagnosis.

Salesforce Ben’s 2026 salary data puts contract rates at “$75 – $135 (hourly)” for admins, “$98 – $168 (hourly)” for developers, and “$120 – $185 (hourly)” for technical consultants. Take the middle of the developer band and three hours of work is a few hundred dollars. Nobody’s budget objection is a few hundred dollars.

The same analysis notes something else worth sitting with: “Whatever disruption AI is causing, it does not yet appear to have translated into lower pay for the people building and architecting on the platform.” Skilled Salesforce people are not getting cheaper. That’s fine — they were never the obstacle. The obstacle is the minimum number of hours you have to buy before anyone will start.

What changed, and what didn’t

AI collapsed the execution half of this. Writing a batch class, a trigger, a custom object definition — the part that used to be the billable core — is now fast enough that it’s no longer the expensive step in the sequence.

The services industry is already repricing around that. TheStreet reported in May 2026 that about a quarter of McKinsey’s global fees now come from outcome-based pricing rather than hours, with Bain and BCG making similar moves toward AI-enabled revenue. That’s the top of the market and a Salesforce boutique is not McKinsey, so don’t read it as a template. Read it as a direction: when execution time falls, billing for execution time stops describing the value.

What didn’t change is the wrapper. Discovery is still human. Judgment about whether a change is safe for this org is still human. AI didn’t make scoping free — it made building cheap, which means the fixed cost around a small job is now close to the entire cost of it.

If you run the shop: stop pricing the small work individually

The instinct is to find a better price for small projects. That’s the wrong lever, because the thing that kills a four-hour job isn’t the price — it’s the per-engagement overhead. Lower the price and you lose money faster.

The lever is the engagement itself. A standing relationship where small requests don’t each require a new SOW, a new scope, and a new context load eliminates the cost that made them unprofitable. You’re charging for access and judgment, not for keystrokes — and judgment is the part that isn’t getting cheaper.

It’s the same argument I made to GoHighLevel agencies about why the snapshot can’t be the offer: when the artifact gets cheap, the durable business is the relationship and the discernment around it. The shop that can profitably say yes to the four-hour job is the one clients stop shopping around.

If you’re the client: the other option is doing it in-house

The reason “just build it internally” used to be a non-answer is that it required a developer you don’t have. That premise is the thing AI actually changed.

An admin who knows your org — which fields lie, which automation fires twice, which process the standard model doesn’t cover — is holding the expensive half of the knowledge. What they were missing was the ability to turn a decision into deployed code. That gap is now bridgeable: connect an AI to the org, describe the change, review what comes back. I’ve written up what to hand it first and what Salesforce automation without a developer actually looks like in practice.

Before you do the math on whether that beats a retainer, it’s worth reading what hiring a Salesforce developer actually costs — the comparison is usually not close, in either direction, depending on volume.

What has to be true before you let an AI do it

Speed without accountability is how you end up with a mystery in production. Four things make the in-house path defensible.

The AI needs a place to run that isn’t somebody’s laptop — a server that holds the credentials, so access doesn’t walk out with a contractor. It needs one write key at a time, so two people’s sessions can’t deploy over each other. Everything it does needs to land in a log, so “what changed and who asked for it” has an answer that isn’t a chat transcript. And a snapshot before deploys, so a change you regret is a change you can undo. Deploys go through the Metadata API, sandbox-first, with tests — the same path any professional Salesforce change takes.

That’s what Sentinel is: a dedicated server for your org with those four things wired in. What it is not is a system that stops your AI from making a change you’ll regret. Describe a routing rule badly and you’ll get a badly routed lead — accurately deployed, fully logged, and reversible. The promise is visible and recoverable, not prevented. Reviewing what was generated and testing before it ships stay your job.

The takeaway

Small Salesforce projects aren’t small because they’re trivial. They’re small relative to the smallest unit anyone will sell you, and that mismatch — not the platform, not the rate card — is why the list keeps growing. You fix it by changing the unit: a shop that absorbs small work without re-scoping it, or an internal team that no longer has to buy the build at all.

Sentinel gives your team’s AI a real place to work: a dedicated server, a proper deploy path, and a record of everything it did. It’s $2,500 one-time onboarding on your first Sentinel, then $500/month per Sentinel — and agencies running one per client is a perfectly reasonable shape.

Set up your Sentinel and clear the small-jobs list →