A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Salesforce orgs rarely fail all at once. They accumulate. A request arrives that the platform can nearly handle, someone writes a trigger, and it works. Three years and forty triggers later, nobody can say with confidence what happens when a record saves.
The symptoms are consistent. Two triggers on the same object, written by different people, firing in an order nobody chose. A workflow rule updating a field that fires a trigger that updates another field that fires a Flow. A data load of ten thousand records that dies partway through because someone put a SOQL query inside a loop.
The developer worth hiring asks first whether the requirement needs code at all. A large share of what gets built in Apex is really a validation rule, a formula field, or a Flow — declarative, upgrade-safe, and editable without a deployment. Code is the right answer when the logic is genuinely too complex for clicks, when you need bulk-safe processing at volume, or when you are integrating with an external system. It is the wrong answer the rest of the time, and knowing the difference is most of the job.
Knowing when a Flow, validation rule, or formula field beats Apex. The most valuable instinct on this platform and the rarest.
Queries and DML outside loops, handlers that process 200 records as comfortably as one. The gap between code that passes testing and code that survives a data load.
One handler per object, explicit ordering, logic a stranger can read. Orgs without this become unmaintainable within about two years.
Salesforce requires 75%. Assertions that verify actual behaviour are optional, which is why so many orgs have coverage and no safety net.
REST and SOAP APIs, Platform Events, middleware, and error handling for the half of a sync that already fired. Where most real complexity now lives.
Modern UI development on the platform. Aura experience does not automatically transfer, and neither does generic front-end work.
Governor limits are where badly written Apex announces itself, and it picks its moment badly.
The pattern is predictable. Code works in a sandbox, tested a record at a time. Then someone runs an import, or a batch job touches two thousand accounts, and a query inside a loop crosses the 100-query ceiling. The transaction rolls back — but the callout to your billing system already fired for the first eight hundred records. You now have partial state across two systems and no clean way to identify what processed.
The slower cost is release velocity. An org with tangled automation cannot be changed confidently. A one-line field change means tracing the order of execution through triggers, Flows, and workflow rules just to learn what else it touches. Changes that should take an hour take a week, and eventually the team stops proposing them.
Gamed test coverage makes this worse rather than better. The 75% requirement is easy to satisfy with tests that instantiate records and assert nothing. Those tests pass whatever the code does, so deployments succeed and the org hands you the feeling of safety without the substance. Teams discover this during a failed release, and the remedy — writing real tests for code you did not write — is why rescue engagements cost more than doing it properly the first time.
Mid-level (3–5 years). Writes Apex and Lightning Web Components inside patterns someone else established. Comfortable with the platform and aware of its limits. Needs review on architecture and integration design.
Senior (5–8 years). Owns the data model and the automation architecture. Decides declarative versus code, designs integrations, and can untangle an org that grew badly. Works directly with business stakeholders on requirements rather than waiting for a spec.
Technical Architect (8+ years). Multi-cloud scope, org strategy, governance, and release management. Worth the premium when you run several orgs, are merging two after an acquisition, or have an integration estate with real complexity in it.
Sales Cloud and Service Cloud build-outs. Configuration, custom objects, and the automation around them. The most common request by a wide margin.
Org rescue and technical debt. Consolidating triggers, retiring workflow rules and Process Builder into Flow, and writing tests that assert something. Unglamorous and consistently the highest-value work we place.
Integration work. Connecting Salesforce to an ERP, a billing system, or a warehouse. Cross-system programmes usually want a solution architect holding the contracts between them. See enterprise application services.
Lightning Web Component development. Custom interfaces where the standard page layout genuinely does not fit the process.
Classic to Lightning migration. Still live at plenty of organisations, and rarely as simple as flipping the switch once custom JavaScript buttons are involved.
Week one. They read the org before they change it. Expect them to map the order of execution on your two or three busiest objects — which triggers fire, which Flows, which workflow rules are still live, and in what sequence. Expect an honest read on test coverage that ignores the percentage and counts how many tests assert anything. A one-page account of what happens when an opportunity saves beats any feature they could ship.
Weeks two to four. They fix the highest-risk item first — usually a bulkification problem waiting for the next import, or a pair of competing triggers on one object. Expect them to push back on at least one request and propose a Flow where Apex was assumed. That pushback is the clearest signal you hired well.
The warning sign is enthusiasm for building. A developer who joins an established org and starts writing new Apex in week one, without having mapped what already fires, is adding to the pile. Ask at the end of month one what they chose not to build. A good answer is specific and arrives without hesitation.
Hiring an admin and expecting a developer. Adjacent roles, genuinely different skills. A strong admin configures the platform expertly and may never write production-grade Apex; a strong developer is often slower at declarative work. Most teams with an existing org need the developer and go looking for the admin.
Treating certification as the qualification. Platform Developer I is a reasonable filter and a poor predictor. It tests knowledge of the platform rather than judgement about when to use it. Certified developers who write SOQL inside loops are common enough that the badge tells you someone studied, not that they have shipped anything at volume.
Solving every requirement in code. Faster for the developer, worse for you. Declarative automation survives the three annual platform releases and can be changed without a deployment. Apex needs a developer, a sandbox, and a release cycle every time the business changes its mind — which it will.
Using Salesforce as a general-purpose database. Large volumes of records nobody queries through the interface will eventually cost you in storage, performance, and limits. Ask early whether the data belongs in the CRM or in a warehouse.
Rates depend on seniority, cloud coverage, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.