The Real Cost of Salesforce Consulting Services

There is a question that every business owner or technical manager will face one day. Should I hire expert-level expensive specialists or choose a cost-effective agency with a less experienced team?

I’m going to dive into this in the context of Salesforce consulting, but most of it applies to any tech outsourcing.

TL;DR

Short summary for people who don’t have time (or will) to read the whole post:

hourly rate is not the cost. A cheaper team often shifts planning, review, rework, coordination, and risk onto your internal people – and that bill shows up later, usually bigger.

The list of risks to consider can be found in the Hidden Costs of Relying on Cheap Agencies section.

It doesn’t mean that you should just throw loads of money on the table and hire the most expensive team.

We prepared a cost calculator to help you compare the costs of different staffing models.
You can find it in the Costs Comparison – Calculator section.

Common Narrative

An obvious take is that you should hire an expensive expert for difficult tasks (architecture, large features, etc.) and a cheap resource for smaller tasks or admin work.
As logical as it sounds, we at Beyond the Cloud strongly disagree with this approach – not because cheap resources cannot write a flow, but because the expensive part of the work is rarely the click-work.

AI Makes the Common Narrative Outdated

The factor that really ages the "seniors for hard stuff, juniors for easy stuff" split is AI.

Easy tasks used to need cheap hands. Now they mostly need cheap compute – plus expensive judgment.

Nowadays, understanding of the work, the project, good practices, and business context matters more than the ability to create a custom field on an object. Most of the "easy" tasks can be done by a matter of a prompt. The real value comes from:

1. Deciding which "easy tasks" are actually needed – architectural planning, foresight about consequences, knowledge of the available choices.
2. Reviewing the work produced by AI.
3. Identifying and structuring the good practices and foundations of the project.

A simple admin task – two staffing models options

Take a typical admin task: add a custom field and adjust a flow. Before LLMs, that often meant a few hours of hands-on work. One experienced person identified the need, planned it, and delegated the final piece to a junior who spent those hours implementing it. That is the common narrative split: seniors plan (and do the hard parts), juniors (often many of them) execute, and sometimes an army of QA validates the result.

With AI, the execution part can go to an agent. You still explain the requirement – but you explain it once, get the work back immediately, and review it the same way you would review a junior (or even faster, because you made sure agent understood you, while preparing the requirements). Testing for the simple cases can be assisted by AI too (note: complex work is a different story; here we are talking about the stuff that used to be delegated to less experienced folks).

So the practical question for agency choice becomes: if agents can cover a large part of the junior slice, why pay for an army of entry-level specialists who still need planning, explaining, monitoring, and babysitting – when one experienced architect can run an "army" of agents, with fewer communication gaps and less double work?

Cost vs Skills, Experience, and Attitude

The most obvious factor when choosing a specialist is the relation between cost and hard skills.
Fair enough, but a few facts complicate that:

1. It is hard to evaluate the real skills of a person or company before you start working with them.
2. An equally important factor is attitude – of the person and of the company as a whole. Do they want to help you succeed, or fulfill the requirements 1:1 and get paid? Will they advise you on best practices beyond implementing the ticket?
3. It is very difficult to compare cost vs skills before the project is done and you can compare what was actually delivered – including the rework.

So when a proposal sells a "very experienced top professional" at $40/h, treat that as a claim to verify – not as a great deal guarantee. It is sometimes a painful surprise when the offer’s claims don’t survive contact with the project.

"But 10 cheaper people still beat 3 expensive ones on paper"

I hear this very often: "Bart, you’re theorizing. I will not hire an agency proposing 3 people at $500/hour total cost if another proposes 10 for the same price or less."

Fair. The second option looks great in a spreadsheet. The only thing I ask is that you price the risks and the productivity math, which later will be clearly visible in the total project cost – not only the rate card. If after that the cheap option still wins for your situation, go for it.

Hidden Costs of Relying on Cheap Agencies

These are the costs that rarely appear on the proposal. Grouped so you can scan them; none of them are theoretical for me.

1. Architecture and platform decisions

• Bad architectural decisions

This one is pretty obvious, but let’s make it concrete.

You have a custom sales process with potential changes in the future. Your cheap agency tells you to use Salesforce record-triggered flows to handle the custom business logic. They tell you this will be faster, cheaper, and easy to configure by non-technical folks. They do not ask questions about the post-MVP phase, potential process changes, or the context of other teams’ work.

So it begins – they configure the flows and fulfill the current requirements by creating pretty big record-triggered flows for opportunities, opp products, quotes, and orders.

Then you add a different product type that requires different business logic. The agency adds separate branches in the flows.

Then you add a different customer type that also requires different business logic for their deals.
Then you need ramp deals support.

The flows are now so big that you need a minute to scroll through them. Every new feature risks breaking existing logic or hitting platform limits (SOQL, CPU time).

Your agency says it’s fine and starts adding async paths.
You start seeing row-lock exceptions, and you cannot do proper retries in the flows.
New requirements keep coming; bug fixes eat 80% of development time.

Then they tell you that you need to move to triggers – six months of work for a five-person team. Until that is done, let’s not add new customizations.

That was one bad decision: lack of knowledge, or lack of proactive questions about the future of the project.
How much would a more expensive agency of top-level experts have saved you here? Often: the rework itself – months of a multi-person team, plus frozen product changes while you dig out of the hole.

• Platform knowledge gaps leading to overkill solutions

Same family of problem, smaller scale. Say you need rollup functionality the platform does not support natively. Or a custom query builder. Or PDF generation.
It would be reasonable to expect your consultant to know open-source options that cut the work from two weeks of custom build to a couple of days.
But if you rely on a cheap agency, there is a high chance that they will miss at least some of the options.

• Increased technical debt over time

This is related to bad architecture, but it is not the same thing. Architecture is often one wrong bet (e.g. flows everywhere). Technical debt is the slow pile-up: clean-code violations, missing patterns, copy-paste "just make it work" solutions, no shared foundations, tests that only cover the happy path. Each ticket still "works". The invoice still looks fine. The system gets harder to change.

At first, things get delivered quickly and cheaply. Then the tax shows up in the cost model – usually in four places managers underprice:

1. Feature velocity tax. What used to take 2 days starts taking a week, because every change touches fragile code and needs extra discovery. You are still paying the same team rate, but you buy fewer features per sprint.
2. Bug / firefighting tax. Business reports more defects. Sales hits unexplained errors. Fixes create new bugs. It is common to see 50–80% of capacity disappear into maintenance. That is not a "support overhead" – that is you paying again for work that was already marked done.
3. Coordination tax on your best people. Seniors (yours or the agency’s) spend more time reviewing, unblocking, and redoing. Their expensive hours become glue for debt they did not create.
4. Rewrite premium. Eventually someone proposes a rework. Now you pay for: understanding the mess, rebuilding it properly, migrating data/behavior, and freezing or slowing product changes while you dig out. That rewrite almost always costs more than building it right enough the first time – and you already paid for the original delivery.

A rough way to think about it in money terms (even before looking at the calculator section):

Month 1–3: cheap team looks like a win – more tickets closed, lower blended rate.
Month 6–12: the same backlog item costs 2–3× what it would on a cleaner codebase.
Month 12+: you either keep paying the velocity tax forever, or you fund a multi-month refactoring while the business waits.

So the "savings" on the rate card often get eaten twice: once as slower delivery, and again as a remediation project. The dangerous part is timing – the cheap phase is visible in the first quarterly review; the expensive phase shows up when nobody wants to reopen the vendor decision.

Note: controlled technical debt is sometimes justified. Shipping fast to protect an MVP budget, then coming back to refactor, can be a conscious call – with a named owner, a timeline, and acceptance that you are borrowing against future capacity. The problem is accumulating debt because the team did not know better, and nobody priced the interest.

• Only one person knows how to extend a component without breaking it

You’ve seen this. A piece of functionality that only one person is confident to touch. Usually it started with weak foundations, no patterns, everything in one file. The first requirements worked. New ones kept landing without conscious refactoring. Now only the author can untangle the behavior.
What if they leave? Or a bug shows up while they’re on vacation?
You will pay – in time and money – to understand and rewrite it.

2. Delivery quality and accountability

• Blind task-doing

How many times have you seen this?

You ask the agency to implement something. You drafted a solution design and asked them to build it.
They deliver quickly. You test it. It only works for the happy path. You ask why they did not test further. They say they did what was in the requirements – and maybe there should be a separate ticket for corrections.

What if the consultant challenged the design, tested the real scenarios, and placed the change in a larger context?
That is a huge time-saver over the life of a project.

Funny note for technical folks: it gets worse when the consultant also does not fully understand an already-flawed design and implements it 1:1 on incorrect assumptions.
I’ve been in a situation where someone was asked to create two custom objects with a permission-set-per-object approach (already a flawed design) – and implemented a separate permission set for every field.

• Bugs and functionality gaps

The more "cost-effective" the team, the higher the risk of bugs and gaps.

Implementing a requirement quickly is one thing. Reviewing the solution, guarding it with tests, understanding business context, and owning the outcome is another.

How many times have you seen this: the consultant finishes the ticket fast; a few days later you find a bug; they ask for a bug ticket; the fix causes another bug; another ticket; by sprint end they "completed" five tickets – three of which were bugs from their own work.

That is not effective delivery. That is a quick implementation with hidden costs.

• Lack of proactiveness and responsibility

How many times was there a minor blocker, while another unblocked slice of work could still move – and the consultant waited anyway? What exactly were you paying for during that idle time?

Example: they have read access to the repo, but are waiting for write access and a personal sandbox.
A proactive developer would ask a teammate to create them a user in an existing sandbox and start locally, without needing push access on day one.
It would be great to know they are not waiting for "push" rights before even reading the requirements.
The question is whether you can trust that this will be the case.

• AI-generated code submitted without understanding

I’ve seen this so many times – in review, I feel like the first human looking at the code after AI.
In the AI era, review is often more than half the job: you tell the agent what to do, then you review and iterate.
When a cheap resource just forwards review comments back to the model, the reviewer is doing the real work.
So what value did that developer bring to the table?

3. The coordination tax (time your internal team burns)

• Code review taking 3x longer than for senior work

Common pattern: cheap-agency developer implements a feature; a senior (internal or agency) reviews. The code is full of smells and risks. Without clean structure, the reviewer must read every line. Then corrections. Then re-review. Repeat.

That senior time is real money – whether or not it appears on the agency invoice.

• Lack of understanding of the CI/CD process – babysitting from the in-house team

You hire an agency to reduce load on your internal team. Then every merge conflict needs your help. Some people cannot commit without Gearset or Copado.
Your internal team (or another agency) babysits them. That time is usually invisible in the "savings" story.

Personal note: I cannot count the situations when we (Beyond the Cloud) were hired as an external agency together with some other agency and this other agency needed our help with unblocking them with CI issues they were facing, because of their misunderstanding of the process. In the end, we were babysitting our competitors. Auch! 😀

• Minimal trust → more internal testing and burnout

This one is easy to miss on the reports, because it is not "another bug ticket." It is what happens to your operating model after enough of them.

After the tenth defect found in "cost-effective" delivery, your internal people stop trusting the work. Not dramatically – practically. Every PR gets a second full pass. Every UAT round becomes an ultra-detailed review. Edge cases that the agency "already tested" get retested anyway, because nobody believes the first pass.

You hired the agency to reduce load. You now pay twice for the same verification:

1. Agency hours to build and "test" the change.
2. Internal senior hours as a permanent shadow QA / release gate.

That second line rarely appears next to the vendor rate card – but it is real capacity. Your best people spend evenings and sprint time checking someone else’s work instead of delivering theirs. Over a quarter, that can erase the hourly "savings" entirely.

Then comes the soft cost that finance notices late: burnout and attrition risk. Babysitting unreliable consultants is not the job your seniors signed up for. Good people start leaving or burning out – and replacing them is more expensive than the original savings on the agency rate card.

• Extra project manager to coordinate a team that cannot self-organize or manage stakeholders

If the team is juniors (sold as juniors, mids, or seniors – never mind) who only implement 1:1, they often cannot coordinate work or talk to stakeholders without a non-technical PM in the middle.

There is real savings in staffing consultants who can do the technical work and own coordination and communication. PM work is rarely full-time. An architect with a technical context oftentimes can cover that (by dedicating just a part of their day) – especially when the rest of the team is senior and self-organizing.

• Coordinating a small senior team is easier than coordinating 15 mixed-level developers

Four seniors vs six juniors, two mids, and one senior. The second team needs more coordination by default: more status sync, more clarification/reiteration loops, more "who owns this dependency?", more overlapping changes on the same objects/metadata, more merge conflicts to untangle.

A small senior team has fewer handoffs and fewer communication gaps. Decisions happen in the same conversation that implements them. Less process, less waiting on each other, and fewer of the risks in this post get a chance to grow.

4. Consulting gap and reputation risk

• Lack of consulting between business and technology

Companies hire agencies because they lack internal expertise on a subject. The hope is that if your business assumptions are wrong, or the process you described is technically not feasible, someone tells you before you spend the money.

When you optimize only for rate, you often get ticket-takers instead. They implement exactly what you asked. They do not challenge a flawed process design. They do not say "this requirement will hurt sales ops in six months." No real consulting included.

That gap has a cost. You become the analyst and the risk owner – while still paying for "consultants." Wrong requirements get built correctly. Misalignment between sales, ops, and how the org should work stays invisible until go-live. By then you are paying for rework, not advice.

The question to ask before signing a contract: if my business ask is wrong, will this team tell me – or just estimate the ticket?

• Reputation risk when they join calls with your stakeholders

You own the outcome for a sales-process extension on Salesforce. You brought in a "cost-effective" agency. Something breaks, or a requirement needs a feasibility check. Ideally the consultants join the stakeholder call, ask the right questions, and assess what is possible.
But if they ask basic process questions and cannot answer technical ones, everyone notices – and your team’s reputation gets negatively affected.

So maybe you keep them off the call and act as a proxy?
That works – but it puts the work back on your plate.

It is much more cost-effective when you trust the agency enough to put them on the call, or even let them run it.
That is why you hired them: to take work off your plate, not to invent a new layer of proxy work.

When a "Cheaper" Setup Can Still Be Reasonable

After outlining so many risks and so many arguments against the "cheaper" setup, I must say a few honest words about when it can still be a reasonable choice.

Obviously, not every project needs teams composed of CTAs only, and budget constraints are definitely not imaginary.

Is Hiring Juniors Always a Bad Idea?

BtC’s narrative so far is clear, but we still believe there is room for less-experienced people – just not in the way most proposals are built.

Experience vs accountability and proactiveness

The main problem with "cost-effective" specialists is not experience alone – even a strong senior is a junior in some areas.
A Salesforce CTA will not know every tool in your landscape. Maybe you use Workato and they never have. What lets them catch up quickly is proactiveness (and obviously, the overall experience in technology/business).
It is easier when they must learn one puzzle piece, not five at once.
Proactive, accountable juniors simply have more pieces to learn (sometimes the important ones: clean code, design patterns). With the right proportions and help from seniors, they can catch up and deliver real value.

The right proportions

Most agencies propose an incorrect ratio: one senior for many juniors.
We think it should be the opposite – more seniors than juniors, or at most 1:1 (more seniors is better).
Juniors learn from seniors, contribute smaller slices, and do not consume the seniors’ entire calendar.
Bad proportions turn seniors into full-time babysitters.

When does this make sense?

Mixing seniors and juniors in the right proportions can be a very good idea if you have less-experienced people internally and want them to learn from the agency – while still getting strong delivery. That way, your team’s self-sufficiency increases, and the agency’s ability to massively deliver is not heavily affected.
But remember, keep the proportions in check!

Generally, I would not recommend to hire an agency with juniors to learn on your project. You are not getting any additional value from this and you need to accept some additional risks.
However, if you still want that (e.g. because your cost calculations show it is a good idea), then go for it – just remember about the right proportions 🙂

How to Decide (a checklist you can forward internally)

Before you pick the "10 for the price of 3" option, ask:

1. What is the real cost? (You can use our cost calculator to help you with that).
2. Will we get truly expertise-based consulting or just 1:1 ticket implementation?
3. Who owns architecture decisions – and can we trust they will proactively challenge a flawed solution design?
4. How much senior review time will our (or their) people spend per junior/mid delivered ticket?
5. Can we trust them to deliver quality work that will not require constant bug fixes and rework?
6. What happens when this process changes in six months – rework after technical debt, or painless extend after strong foundations?
7. Can these consultants join a stakeholder call without risking our reputation or proxying?
8. Are we buying execution under our standards, or hoping they advise and shape the standards?
9. In an AI-assisted delivery model, are we paying for judgment and architectural decisions – or for a human proxy between us and a model?

Costs Comparison – Calculator

Enough talking. Let’s look at numbers. When I decide on outsourcing, I want to see what I pay and what I get back – not only the rate card.

We have prepared a cost calculator that you can use to compare the costs of different staffing models.
You can find it here: Salesforce Consulting Agency Cost Calculator.

The comparison is always the same shape:

• Scenario A – "cost-effective" team: more people, lower blended rate, more coordination and quality tax.
• Scenario B – senior-heavy team: fewer people, higher rate, less tax, stronger AI leverage.

Both scenarios use the same configuration schema (same knobs). Only the defaults / presets differ. That way a skeptical reader can move every slider and still see which story wins under their assumptions.

We measure delivery in abstract points (not your Jira story points – a neutral unit so productivity assumptions stay explicit).

How the model works

1. Effective scope = projectSize × (1 + extraScopeFromGaps%) for that scenario.
2. Each month, compute gross points from delivery roles:
   • Seniors/leads and juniors produce points.
   • PMs produce $ burn only (0 points).
   • Seniors/leads lose delivery time to supervising when juniors are present.
3. Apply AI multiplier to that scenario’s delivery roles (seniors/juniors).
4. Apply rework tax for that month → net points. Cheap preset: tax grows over time. Senior preset: low and flat (growth = 0).
5. Accumulate net points until effective scope is covered → duration (months).
6. Agency cost = duration × monthly agency burn.
7. True cost = agency cost × (1 + internalShadow%) (your people’s dual-QA / babysitting load).

Play with the sliders until you get your assumptions that you agree with. Observe which team is cheaper after taking hidden costs into account.

Conclusion

I hope this post has helped you broaden your perspective on the topic of agency choice and pricing.
The main idea was to show that the hourly rate presented by an agency is not the only and not the most important factor influencing the final cost of the project. Especially now, in the AI era, the classic assumptions for the staffing models are outdated and need to be reevaluated.

Need help with your Salesforce implementation?

If the idea of hiring an expert-only team is resonating with you and you need help with Salesforce implementation, I encourage you to contact us at contact@beyondthecloud.dev or via LinkedIn.
We’ll be happy to give you guidance and top quality delivery.
You can also message me directly.