What this covers
There's a point where Flow stops being the right tool and Apex is. The trick is recognizing that point — neither too early (you don't need code yet) nor too late (your flows have become unreadable). I do that triage as part of the work.
- Triggers and trigger frameworks — built once, well, with bulk-safe patterns.
- Service-layer Apex — long-running batch jobs, queueable processes, scheduled work.
- Lightning Web Components when the UI needs to do something the platform can't.
- API endpoints exposed for external systems to call.
- Test coverage that's actually tests, not assertions written for the deployment to pass.
- Source control and CI — work happens in Git, deploys are repeatable, sandboxes don't drift.
How we typically engage
Apex projects are scoped against specific user stories. We write the proposal in terms of what the user can now do, not how many classes will be created. Code is delivered through pull requests so your team — or future maintainer — can read what was changed and why.
What "done" usually looks like
- Code passes the deployment with real coverage of the meaningful paths.
- Comments and naming explain the why, not the what.
- A short architecture note in the repo describing the trigger framework, error handling pattern, and why we made the calls we did.