The sentence that costs the most money
“It worked in the sandbox” is the most expensive sentence in Salesforce. It is expensive because it is true — the code did work, against the five records someone hand-created while building it. Governor limits are not triggered by bad logic. They are triggered by volume meeting logic that was never designed for volume, and volume only ever arrives in production.
A trigger that runs one SOQL query is fine. The same trigger, when a data loader pushes 10,000 records through it in batches of 200, runs that query 200 times per batch and dies on the 101st. Nothing about the code changed. Only the number of records did.
This kit is the fifteen patterns we apply on every Apex review. They are not style preferences. Each one is the fix for a specific, repeatable production failure.
Bulkification is a design decision, not a refactor
The single most common cause of governor-limit failures is code written as though it will process one record. Salesforce never guarantees that. Triggers fire in batches of up to 200, and every automated path — data loader, API integration, Flow, another trigger — arrives in bulk.
Writing for 200 from the start costs nothing. Retrofitting it after an outage costs a weekend. The kit covers the two loop-based failures that account for most incidents — SOQL inside a loop and DML inside a loop — and the Map<Id, List<SObject>> pattern that eliminates both by grouping children once, before you iterate.
Move the heavy work off the transaction
Synchronous Apex gets a narrow budget: CPU time, heap, callouts. The moment your logic needs to do real work — an external callout, a large recalculation, a cascading update — that work does not belong in the triggering transaction.
The kit covers when to reach for Queueable (and why it is almost always the better choice over @future), how to structure Batchable with Stateful for genuinely large volumes, and how to keep callouts bulk-safe so one contact record does not trigger 200 HTTP requests.
Failure modes you have to design for
Three patterns in the kit exist because production is hostile in ways sandboxes are not. Recursion guards, because an after-update trigger that updates its own object will re-enter itself unless a static boolean stops it. Kill switches, because when automation misbehaves at 2am you need a custom setting you can flip without a deployment. And partial-success DML, because Database.update(records, false) lets 9,999 good rows commit while one bad row fails, instead of rolling back the entire batch.
That last one is the difference between a support ticket and an incident.
What’s inside
- Bulkify every trigger — design for 200, not 1
- Never put SOQL or DML inside a loop, and the Map pattern that replaces both
- Move heavy work and callouts to Queueable; when to prefer it over @future
- Process millions of rows with Batchable + Stateful
- Stop trigger recursion with a static guard, and ship a kill switch
- Partial-success DML so one bad row cannot roll back 9,999
- Aggregate in SOQL rather than Apex; cache reference data in Platform Cache
- Bulk-safe callouts and testing at scale
