Apex and Lightning Web Components the next developer won’t dread.

When configuration runs out, the fix shouldn’t create a new problem. I write Apex and LWC that’s tested, documented, and readable by whoever inherits the org next — including future me.

Schedule consultation See related case studies
The problem

Common problems

Custom code in Salesforce orgs often gets written under deadline pressure by whoever was available, with no test coverage beyond the 75% Salesforce requires and no documentation beyond inline comments nobody reads. It works, until a platform release changes behavior it silently depended on, or the person who wrote it leaves.

Lightning Web Components built without attention to performance — too many wire adapters, unnecessary re-renders, poor error boundaries — degrade the exact experience they were meant to improve. And triggers without a clear framework turn into a stack of "if this, then also this" logic nobody wants to touch.

"Nobody wants to touch the Apex because nobody’s sure what it’ll break."

"Our custom components feel slower than standard Salesforce pages."

"Test coverage exists, but the tests don’t actually test anything meaningful."

Business impact

Unmaintainable code is a growing tax — every future change costs more than it should, and every Salesforce release becomes a risk instead of a routine update. Poor-performing components directly hurt the adoption they were built to drive: a slow custom page pushes users back to spreadsheets.

The approach

How I solve it

1

Requirements and edge-case review

Confirm what the automation or component actually needs to handle, including the edge cases that get skipped under deadline pressure.

2

Architecture before code

Trigger frameworks, service layer patterns, and component structure are decided up front, not discovered mid-build.

3

Build with meaningful test coverage

Tests that verify behavior, not tests written solely to clear the 75% threshold.

4

Code review and CI

Every change reviewed and run through a CI pipeline before deployment.

Varies by scope — a single component or trigger typically runs 1–3 weeks; a larger custom module runs 4–8 weeks.

What changes

Outcomes from this work

Documented, maintainable code

confirmed via handoff review

  • test coverage with meaningful assertions — not just line coverage
  • reduction in page load time for rebuilt components
  • deployment error reduction after CI adoption

Outcomes are drawn from anonymized client engagements; specific figures are shared on a consultation call.

Fit

This is the right engagement if…

  • You’ve hit the ceiling of declarative tools — a business requirement Flow genuinely can’t handle cleanly.
  • You have existing custom code that’s become a liability and needs a rebuild or serious refactor.
  • You want a second set of eyes reviewing custom code before it ships.

…and probably not if

  • The requirement can be met with Flow or standard configuration — I’ll tell you if that’s the case rather than write code you don’t need.
  • You need a quick patch with no interest in test coverage or documentation — that’s a different kind of engagement.
  • Your team has no path to maintaining custom Apex/LWC long-term and isn’t planning to retain support — worth discussing on the call first.
Questions

Before you book a call

How long does a custom development engagement typically take?
A single trigger or component runs 1–3 weeks; larger modules run 4–8 weeks, depending on scope.
What’s the starting investment?
Scope and price are fixed in a written proposal once requirements are defined.
Do you write test coverage that actually verifies behavior, not just hits 75%?
Yes — that’s a standard part of the deliverable, not an add-on.
Can you work inside our existing CI/CD pipeline (Copado, Gearset, etc.)?
Yes, or I can help set one up if you don’t have one yet.
What’s your communication cadence?
Scoped tickets or user stories, async progress updates, and a code review conversation before anything merges.
Do you take over maintenance of code someone else wrote?
Yes — auditing and stabilizing an existing custom build is common work; the first step is always an honest assessment of what’s there.

Still not sure?

A 30-minute call costs nothing and usually answers this faster than a form.

Schedule a consultation

Email instead

Have code nobody wants to touch?

Send me what you’ve got. I’ll tell you honestly whether it needs a rebuild, a refactor, or just better tests.

Schedule consultation

Send project details