HireHiring the right Salesforce developer saves months of rework. Hiring the wrong one costs you a rebuild later, at a worse time and a worse price. This guide covers what to look for, what to pay, and how to start fast without skipping the steps that matter.
1. Define the work clearly
Before you hire, write down: which clouds you use (Sales, Service, Experience, etc.), whether you need Apex, LWC, Flows, or integrations, and if the org is new or existing. Note what's already automated — Flows, Process Builder relics, triggers — and any third-party tools already connected (billing, ERP, marketing platforms). If the org has years of undocumented customization, say so up front; it changes who you should hire and how the engagement should be scoped. Vague briefs attract the wrong talent — a one-page brief covering current state, desired outcome, and any hard constraints gets a faster, more honest quote than "we need a Salesforce dev."
2. Look for the right certifications
- Platform Developer I (PD I) — baseline for custom development
- Platform Developer II (PD II) — complex Apex, triggers, async patterns
- Administrator cert — helpful for declarative-heavy work
Each certification signals a different level of readiness, not a guarantee of skill. PD I means someone can write a working Apex class or trigger and build unit tests that pass — the entry point for real custom development, not proof of production judgment. PD II signals comfort with asynchronous Apex (batch, queueable, future), larger data volumes, and integration design — this is who you want on non-trivial logic. The Administrator cert is worth more than people assume on declarative-heavy orgs: it tests real fluency in Flow and permission models. If the work leans toward process redesign rather than custom code, it's worth reading our comparison of a Salesforce architect vs consultant first — sometimes the role you need isn't "developer" at all.
Certifications alone are not enough. Ask for production org experience and references to similar projects. A candidate who has only worked in sandboxes or trailhead playgrounds hasn't dealt with real data volumes or the politics of changing a process people depend on daily.
3. Choose hourly or dedicated
Hourly suits fixes, small features, and audits. Dedicated suits ongoing roadmaps and teams that need someone embedded daily. The core tradeoff is ramp-up time: an hourly developer needs to be efficient from hour one, while a dedicated developer front-loads a couple of weeks learning your org for lower long-run cost per feature shipped. Final pricing depends on role and scope — see our hourly vs dedicated comparison.
4. Interview for real skills
Ask candidates to walk through: a trigger or Flow they built, how they handle governor limits, sandbox-to-production process, and an integration they shipped. Avoid pure theory questions. Two more prompts that separate real experience from memorized answers: ask them to describe a deployment that broke something in production and how they fixed it — everyone who's shipped real Salesforce work has a story here, and the absence of one is telling. Also ask them to explain why they chose specific object relationships (lookup vs master-detail) on a data model they built. Listen for tradeoffs, not textbook definitions.
5. Start with a paid discovery
A short discovery call (we offer this free) aligns scope, timeline, and budget before anyone writes code. You get a clear quote — hourly cap or fixed price. For anything beyond a small fix, a short paid discovery phase is worth it too: it lets the developer actually look at your org and flag risks before you commit to a larger engagement.
Red flags to watch for
- No production org experience — only sandbox, demo, or trailhead work
- Can't explain governor limits in plain language, or dismisses them as "not a big deal"
- No references, no portfolio, and reluctance to point to any real project
- Quotes a price or timeline without asking a single question about your org
- Vague or evasive about their sandbox-to-production deployment process
Any one of these on its own isn't disqualifying, but two or more together is a pattern worth taking seriously.
What a good hire actually costs
Rates vary by role, seniority, and region — a junior developer doing straightforward configuration costs meaningfully less than a senior developer handling complex integrations, and a dedicated architect costs more again. Hourly engagements typically carry a premium over dedicated/retainer rates because you're paying for flexibility and zero ramp-up commitment. The honest framing: the cheapest hourly rate is rarely the cheapest total cost, since rework from an underqualified hire usually costs more than paying properly the first time. Scope the work, check references, and treat the quote as one input among several — not the deciding factor.