Service 02
Custom Apex, custom components, custom everything.
Configuration runs out. When it does, the question is whether the code that replaces it is defensible six months later. Ours is, because 46% of it is tests.
- Shape
- Build engagement
- Duration
- 6 to 16 weeks
- Output
- Source in your repo
01Capability
What we build with
Six areas. The last one is not a technology, and it is the one that decides whether the other five survive contact with production.
- 01
Apex classes and triggers
314 classes and 32 first-party triggers shipped in one org. Vendor triggers from a managed package stay out of source control, deliberately, so the count means what it says.
- 02
Lightning Web Components
79 components, including a 3,225-line datatable and a scheduler that replaced a crew-staffing spreadsheet with in-cell typing. Data-dense surfaces, built for people who work in them all day.
- 03
Visualforce PDF engines
19 in production. Documents that go to a customer have to be exact, and the invoicing path in a real org renders a PDF and flips a flag rather than writing to an invoice object. We hook the path users actually run.
- 04
Batch, queueable and scheduled
Nightly queueable chains, batch geocoding, scheduled recomputes. Each one carries a heartbeat and a watchdog, because a job that stops silently is worse than a job that fails loudly.
- 05
Integrations through named credentials
The key is a named credential password merged into a header. It never becomes an Apex value, so it cannot be logged, cannot land in an exception, and cannot be echoed back to a caller.
- 06
The platform limits
The 120-second cumulative callout budget drives caller-supplied timeouts of 25, 45 and 60 seconds, never 120. Apex cannot sleep and cannot honour a retry-after. Knowing that before you build is the difference between a design and a rewrite.
02The record page
135 fields on one object, and the daily job still comes first.
A record page is an operational decision, not a cosmetic one. Tab order follows who opens the page and what they came to do.
- 79 Lightning Web Components in production, including a 3,225-line datatable.
- Sections and field sets driven by custom metadata, so the next change is a data row.
- Every tile that shows money states the basis it was calculated on.
- Checked on the phone as well as the laptop, signed in as the person who lives on this page.
Contract value excludes tax. Amounts are as entered, in mixed currencies, and are not converted.
Send us the build nobody wants to own.
03The board pattern · six operational surfaces
The work is in columns, not in a report
Staff stop opening a list view, filtering it, and holding the state in their head. One surface shows what is queued, what is moving and what is stuck, and moving a card is the status update. We have run the same pattern across task, work order, purchase order, order, dispatch and production records.
- Drag between columns writes the status, so there is no second step to forget
- A real Gantt view for the boards where sequence and duration are the whole problem
- A mobile-safe path, because the desktop table component does not render in the mobile app
- Card contents driven by custom metadata, so a new column is a data row
- Built once and reused across six record types rather than rewritten per object
04One surface, not five reports
Counting stock is one screen, and it will not save without a reason.
Five reports and a spreadsheet is how a discrepancy becomes permanent. One component holds the count, the bulk edit, the spot check, the history and the audit log.
- Adjustments require a reason, so the audit log is still worth reading a year later.
- Column and card contents come from custom metadata rather than a deploy.
- A mobile-safe path is built alongside it, because the desktop table component does not render in the Salesforce mobile app.
- Already carrying 2,435 inventory items and the movements behind them.
Start a physical inventory count
412 products selected. Only ticked items on the Products tab are pulled in.
05A worked example
The tax engine
A client diagnosis, disproved. Six defects quantified in dollars. Then a config engine built around one fact about formula fields.
- 01Brief
The reported problem
The client believed Salesforce was applying tax by item product rather than by the province of the customer. That was the brief, and it was specific enough to build from.
- 022,335 lines
The diagnosis, disproved
We checked all 2,335 order line items rather than a sample. Zero orders shipping outside British Columbia carried BC tax treatment. The reported problem did not exist.
- 035,182 lines exposed
The defects that did exist
31% of quote lines carried no tax code at all, 5,997 of 19,255. Of those, 5,182 sat on Canadian job sites. Forward pipeline was converting with blank codes.
- 04Each quantified
Four smaller ones, each priced
Tax not charged on open pipeline. Tax already leaked on 22 zero-rated Canadian lines. Quebec tax charged that the company is not registered to collect. And one progress claim understated through a change-request sign error.
- 05One field
The root cause
The trigger flow’s entry criterion watched a formula field whose own help text reads that it is informational only and not used in calculations. That field was running the entire order-side tax stack.
- 06Why metadata
The constraint that set the design
Five of the eight places a rate was hard-coded were formula fields. A formula field cannot query a custom object, but it can reference custom metadata. Custom metadata was therefore the only store that let those formulas drop their literals without rewriting the engine in Apex first.
- 0728 rows
The build and the switchover
A 28-record province by tax-class rate table, with the statutory rate split from the applied rate, registration status, and effective dating. Switchover ran in five phases under a numeric regression protocol: snapshot the tax sums over all order items, deploy, re-run, and treat any delta as a bug in the mapping rather than an improvement.
Ask what your hardest screen would actually cost.
Bring us the build nobody wants to own.
Send the object, the screen or the integration that keeps coming back. You get a written read on it within one business day.
- Reply within one business day
- Source ships in your repository