Hire Salesforce Developers: Rates, Vetting and Engagement Models

What a Salesforce developer actually does, and where hiring goes wrong

A Salesforce developer is not a person who clicks around in Setup. Admins do declarative work: page layouts, Flows, validation rules, permission sets, reports. A developer starts where declarative hits its ceiling. That means Apex classes and triggers, SOQL and SOSL queries that behave under governor limits, Lightning Web Components, integrations through REST and SOAP endpoints, Platform Events, Salesforce Connect, and packaging and deployment through Salesforce DX, change sets or a CI pipeline.

We have opened this org more than once. A mid-market company hired an offshore contractor to build "custom quoting logic." Eighteen months later the org has fourteen triggers on the Opportunity object, each written by a different person, each calling out to its own helper class, none of them respecting a shared handler pattern. Nobody knows what order they fire in. There are two Process Builders and three Flows on the same object doing overlapping work. A sales rep updates 200 records in a list view and half of them silently fail because a trigger does a SOQL query inside a for loop and blows the 100 query limit. Test coverage sits at 76 percent because someone wrote assertion-free tests just to clear the 75 percent deploy gate. Every deployment to production is a Friday night event with a rollback plan written in a Slack thread.

That failure does not come from a developer who cannot code. It comes from hiring someone who treats Salesforce like a generic Java job instead of a multi-tenant platform with hard limits, a metadata deployment model and a release cadence you do not control. The second failure mode is the opposite: hiring a strong admin, calling them a developer, and discovering six months in that everything is a Flow, the Flows are unversioned, untestable and un-reviewable, and the org has become a black box.

The third failure is scope confusion. Companies hire a "Salesforce developer" when what they actually needed was a CPQ consultant, a Marketing Cloud specialist, or a data migration engineer. Those are different people. A brilliant Apex developer can be useless at CPQ price rule debugging, and a CPQ expert may not have written a Lightning Web Component in years.

Engagement models and the honest trade-offs

In-house hire. Right when Salesforce is your operational core and the backlog never empties: you are constantly shipping new objects, new automations, new integrations, and your revenue process changes quarterly. An in-house developer accumulates org knowledge, which on Salesforce is worth a lot, because your org's history of technical debt is not documented anywhere else. The problem is that good Salesforce developers are in short supply and know it, and a solo hire has nobody to review their code. One person plus no code review equals the fourteen-trigger org above, just slower.

Freelancer. Right for a bounded piece of work: build this integration, refactor this trigger set, migrate off Process Builder before the retirement deadline bites. Freelancers on Salesforce skew heavily toward the admin-plus end of the spectrum, and a lot of profiles that say "developer" mean "Flow builder." The real risk is not skill, it is continuity. Salesforce work leaves fingerprints. When a freelancer leaves and the next person opens the org, undocumented Apex with no handler pattern is worse than no Apex.

Agency or consultancy. Right when you need multiple skill sets at once: a developer, an architect for the data model, and someone who has done CPQ or Experience Cloud before. Agencies bring pattern libraries and a deployment pipeline you do not have to invent. The trade-off is cost and the well-known bait and switch, where the certified architect who ran your sales call disappears after week two. Insist on named people, and on meeting the developer who will write your Apex.

Staff augmentation. This is our default recommendation for most companies below the enterprise line. You get a developer, or a small pod, working in your Jira, your sandbox, your standup, but backed by a team that reviews their pull requests and can swap in a CPQ or Marketing Cloud specialist for two weeks without a new contract. You get agency depth with in-house rhythm, without the hiring cycle. The trade-off is that you still own product direction. Staff augmentation does not decide what to build. If you have no clear backlog owner, this model underperforms.

What it costs

These are Digital Heroes delivery ranges and what we observe in the market. They are not from a survey, and you should treat any precise "average Salesforce developer rate" number you see online with suspicion, because the label covers everything from a Trailhead-badged admin to a Technical Architect who designs multi-org data strategies.

• Offshore, India and South Asia: roughly $30 to $75 per hour. The low end is admin-plus work. Real Apex, LWC and integration capability starts near $40 and a genuinely senior developer with production Salesforce DX and CI experience sits at the top of that band.
• Eastern Europe and Latin America: roughly $55 to $110 per hour, with the overlap in time zones being a large part of what you are paying for.
• Onshore US, UK, Western Europe: roughly $95 to $185 per hour for contract developers. Certified Application Architects and System Architects, and CPQ or Revenue Cloud specialists, routinely price above that.

Rates move with seniority and region, and also with certification pressure. Salesforce credentials matter more to buyers here than in most stacks, which means a Platform Developer II badge adds to price whether or not it adds to skill. Pay for the code review you can see, not the badge.

The full cost of an in-house hire. Base salary is the number people plan around and it is the smallest part of the picture. Add employer taxes, health coverage, retirement contributions, equipment, software and a desk, and the loaded cost typically runs one point two five to one point four times base in the countries we hire in. Then add recruiting. Salesforce developers are a scarce specialty, the placement agencies we have dealt with charge a percentage of first-year salary, and in-house recruiting costs weeks of a hiring manager's time. Then add ramp. A Salesforce developer joining an existing org is not productive on day one no matter how senior. They have to learn your data model, your automation graph, your permission set architecture and which of your fourteen triggers is load-bearing. Two to three months to real velocity is normal in a messy org. Budget the salary, then budget the true cost, then compare that number to a contract rate before you decide.

How to vet a Salesforce developer

Ignore the certification wall on their LinkedIn for a moment and probe the platform-specific reasoning. Certifications prove they can pass a multiple-choice exam. They do not prove they have ever debugged a recursive trigger at 11pm.

Questions that separate real developers from Flow builders:

• "Walk me through how you would structure triggers on an object that already has three of them." A good answer names one trigger per object with a handler class, a static boolean or a set of processed IDs to stop recursion, and a way to control execution order. A weak answer says "add another trigger."
• "You have a batch job that needs to process 500,000 Accounts and call an external API for each one. How do you build it?" You want Batch Apex with a sensible scope size, Database.AllowsCallouts on the class, Queueable chaining, Database.Stateful only where it earns its keep, the fact that you cannot make a callout after uncommitted DML in the same transaction, and error handling that does not silently swallow failures.
• "How do you handle governor limits when the same code runs from a Flow, a trigger and a bulk data load?" Bulkification against Trigger.new and Trigger.oldMap, no SOQL or DML inside loops, maps keyed by Id, and awareness that limits are per transaction, not per record. Bonus if they mention checking Limits.getQueries during debugging.
• "When do you use a Flow instead of Apex, and when do you refuse?" The good answer is not "always Apex." It is a considered line: declarative for simple, admin-maintainable logic, Apex when you need complex branching, bulk-safe callouts, real testability or reusable logic. A developer who says everything should be Apex is as much of a problem as one who says everything should be a Flow.
• "What is your test strategy beyond hitting 75 percent?" You want meaningful assertions, Test.startTest and Test.stopTest to reset limits, a test data factory, @TestSetup, HttpCalloutMock for integrations, System.runAs for sharing behaviour, and bulk tests with 200-plus records rather than one.
• "How do you deploy?" Salesforce DX with sfdx-project.json, scratch orgs or a sandbox strategy, source-tracked metadata in Git, unlocked packages where they fit, a CI pipeline. If the answer is "change sets" and nothing else, that tells you their ceiling.
• "What is your approach to sharing and record visibility?" Org-wide defaults, role hierarchy, sharing rules, permission sets over profiles, and the "with sharing" versus "without sharing" versus "inherited sharing" decision in Apex, which is where a lot of quiet data-exposure bugs live.

The take-home that works. Do not ask for a generic coding exercise. Give them a scratch org or a dev sandbox and a real-shaped problem: an Opportunity trigger that must roll up a value to a custom object, respect an existing handler pattern you provide, be bulk-safe for a 200-record load, make an outbound callout that is properly async, and ship with tests that use HttpCalloutMock and assert real outcomes. Two to four hours of work, paid. Then review it with them live and ask why they made each choice.

What to look for in a portfolio. Salesforce work is usually behind a customer login, so you rarely get a public repo. Ask instead for a screen share walkthrough of an org they built, or a redacted architecture diagram. Ask them to describe the messiest org they inherited and what they did about it. That story reveals more than any managed package they can point to. If they have AppExchange package experience or contributed to a trigger framework, that is a strong signal, because it means they wrote code somebody else had to maintain.

Red flags

• Certifications are the whole pitch. A profile listing six badges and no story about a hard technical decision usually means exam prep, not delivery. Ask instead: "Tell me about a time you hit a governor limit in production. What was the fix?"
• "We got test coverage to 85 percent" with no mention of assertions. Coverage is a deploy gate, not a quality measure. You can hit it with empty tests. Ask instead: "Show me a test class you are proud of, and tell me what it would catch."
• Everything is a Flow, or everything is Apex. Both are ideology, not engineering. Ask instead: "Give me an example of a requirement where you started building it in Apex and moved it to a Flow, or the reverse."
• Deployment story is change sets only. This means no version control, no code review, no rollback and no repeatable release. It is the single strongest predictor of an org that becomes unmaintainable. Ask instead: "How does your code get from your machine to production, and what happens if it breaks?"
• Cannot distinguish Sales Cloud, Service Cloud, CPQ and Marketing Cloud work. Someone who claims all of them equally has usually done none of them deeply. CPQ in particular is its own discipline, with quote line editor behaviour and price rules that break in ways nothing else does. Ask instead: "Which cloud have you shipped the most in, and what is the thing about it that most people get wrong?"

When to hire a Salesforce developer at all, and how Digital Heroes staffs it

Do not hire a developer if your problem is that nobody has configured your org properly. That is an admin, and a good admin is cheaper, faster and more appropriate for permission sets, page layouts, reports and straightforward Flows. Roughly, if what you need can be done in Setup by a competent admin, hiring a developer is expensive and they will be bored inside a quarter.

Do not hire a developer if what you actually need is architecture. If your question is "should this live in Salesforce at all, or in a service alongside it," or "how do we support three business units in one org," that is a Salesforce architect for a few weeks, not a developer for a year. Getting that wrong builds the wrong thing very efficiently.

Do hire a developer, or engage one, when you have real Apex and integration work: syncing Salesforce with your ERP (Enterprise Resource Planning) or billing system, building Lightning Web Components your reps actually live in, replacing Process Builder before it goes away, or untangling an org where nobody can safely deploy on a Tuesday.

The way we staff it at Digital Heroes: we start by reading the org, not by writing code. A developer plus a reviewer spend the first stretch mapping the automation graph, the trigger inventory, the permission model and the deployment path, and hand you a short list of what is load-bearing and what is dead. Then we put the metadata in Git with a sandbox strategy and a pipeline, so every subsequent change is reviewable and revertible. Then we build. Every piece of Apex gets a second pair of eyes before it merges, which is the thing solo hires and most freelancers structurally cannot give you. When a scope turns out to need CPQ depth or a Marketing Cloud specialist for a fortnight, we rotate that person in rather than letting your generalist guess. And we write things down, because the whole point is that when we step back, the next person to open your org can understand it without a séance.