Service

Salesforce architecture and engineering

Most Salesforce problems that surface in year three were decided in week two: an object model that fought the business, a sharing model bolted on after go-live, or automation spread across four tools with no owner. We do the architecture and the implementation as one job, so those decisions are made deliberately and by someone who has to live with them.

The work

Data model and object design, including the sharing and visibility model
Apex, Lightning Web Components, and Flow — chosen per problem, not per fashion
Technical audit of an existing org: automation inventory, limits exposure, technical debt, and a prioritised remediation backlog
Release process, environment strategy, and deployment tooling
Code review and technical leadership alongside an in-house or partner team

Where we stop

We are two senior engineers, not a staffing firm. We take work where the architecture and the build matter more than the headcount, and we say so when a programme needs a larger delivery team than we are.

The decisions this work exists to get right

Where automation lives: Flow, Apex triggers, and platform automation each have a cost at scale. We pick one owner per object and document it, so the next engineer can predict what happens on save instead of reverse-engineering four overlapping tools.
Access model alongside the data model: Visibility rules are the hardest thing to change after go-live, because they are entangled with reporting, integration users, and every portal. We settle org-wide defaults, role hierarchy, and sharing mechanics up front.
Governor limits as a design input: Bulk behaviour, query selectivity, and asynchronous boundaries get designed at the start. Retrofitting bulkification into a live org is an expensive way to learn the limits.
What the platform should not do: Some processing does not belong in Salesforce — heavy document work, large-volume reconciliation, or anything with a latency budget the platform cannot hold. Deciding that early avoids building something that has to be unwound.

Questions we get asked

Answers are here in the page rather than hidden behind a script — open or closed, the text is the same.

Can you take over an existing Salesforce org?

Yes. We normally start with a focused technical audit — automation inventory, limits exposure, integration surface, and test coverage — and produce findings with a prioritised remediation backlog. The depth and duration of that audit are agreed from the org size, complexity, and access available.

How long does an implementation take?

It depends on scope, integration dependencies, data readiness, and how quickly your side can make decisions. We will not quote a standard duration, because the honest answer comes out of discovery. Scope, responsibilities, and the commercial model are agreed before delivery starts.

Do you work alongside our internal team?

Often, yes — as technical lead, architect, or reviewer on a team you already have. That works well when you need the decisions to be right and have the hands to build.

Working on something like this?

Tell us the systems and the constraint. You will get an engineer's answer, not a capability deck.

Talk to an engineer