Enterprise Platforms
Salesforce
Engineering on Salesforce, not reselling it — custom development, integration and untangling the orgs that clicks-and-code left behind.
Overview
Salesforce is two things at once, and the distinction matters more than most vendors admit. It is the dominant cloud CRM — Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud and Experience Cloud, sold per user, per month — and it is a full application development platform underneath, with its own database model, its own programming language in Apex, a component framework in Lightning Web Components, a declarative automation engine in Flow, and a query language in SOQL. Most businesses buy the CRM and then discover, a year in, that they own a platform they never planned to develop on. That is where the trouble usually starts, and where engineering — rather than administration — is what they actually need.
We are not a Salesforce reseller and we do not make money on your licences. Our angle is the platform itself: writing Apex and Lightning Web Components where declarative tools run out, building Flows that are maintainable rather than sprawling, integrating Salesforce with the rest of your business — bespoke systems, data warehouses, ERP, billing — usually through APIs or MuleSoft, and untangling orgs that years of uncontrolled customisation have turned into something nobody dares change. Salesforce calls the messy result "technical debt" too; the industry runs on rescuing it.
Because we operate what we build, we treat a Salesforce org the way we treat any production system: with source control, a proper development-to-production pipeline, tests that respect the platform’s governor limits, and a bias toward configuration over code and toward standard features over reinvention. The failure mode of Salesforce is not that it can’t do something — it is that it can do the same thing five different ways, and a decade of admins and consultants each picked a different one. Disciplined engineering is the antidote, and it is what we bring.
Best for — Organisations already committed to Salesforce as a system of record who need real engineering — custom development, integration with the rest of their systems, or the rescue of an over-customised org — rather than more licences or another admin.
Why teams choose Salesforce
Engineering discipline on a platform that rewards it
Version-controlled metadata, a real deployment pipeline, tested Apex and deliberate automation design turn a fragile org into one you can change with confidence. The platform gives you all of this; most orgs never use it, and pay for that later.
Salesforce joined to the rest of your business
The value of Salesforce multiplies when it is properly connected to your ERP, billing, data warehouse and bespoke systems. We build those integrations to be observable and resilient, so data flows correctly instead of drifting out of sync.
A messy org made safe to change again
Rescuing an over-customised org — auditing what exists, removing what is dead, consolidating overlapping automation and adding test coverage — restores the ability to ship changes without breaking production every time.
Why businesses choose Salesforce
- You have committed to Salesforce and want it engineered properly — with source control, tests and a deployment pipeline — rather than customised by whoever is closest to the keyboard.
- You need Salesforce integrated with systems that are not Salesforce, and you want that done by people who understand both the platform’s limits and the systems on the other side.
- You have inherited an org that has become fragile and want it stabilised and documented before it causes an outage or blocks the business.
- You want an honest partner who will tell you when Salesforce is the wrong tool — or overkill — instead of billing you to force it to fit.
What we build with Salesforce
The capabilities this technology is genuinely strong at — and what we most often build with it.
Apex development within governor limits
Apex is Salesforce’s Java-like server-side language for triggers, classes and batch jobs. We write it bulkified from the start — processing collections, not single records — and mindful of governor limits on queries, DML and CPU time, with the unit-test coverage the platform requires before you can even deploy to production.
Lightning Web Components
LWC is Salesforce’s modern, standards-based component framework built on web components. We use it to build fast, maintainable custom UI on the Lightning platform and in Experience Cloud sites, rather than stretching declarative page layouts past what they were meant to do.
Flow automation, designed to last
Flow is the declarative automation engine that has replaced Workflow Rules and Process Builder. It is powerful and it is easy to abuse — a dozen overlapping Flows on one object is a common mess. We design automation deliberately, consolidating logic and documenting it so it stays maintainable.
SOQL, SOSL and the data model
Salesforce’s data lives in a relational model queried with SOQL, and searched with SOSL. Good object and relationship design, selective queries and an eye on limits are the difference between a fast org and one that times out — we design the schema, not just the fields.
The metadata and API model
Everything in Salesforce — objects, fields, code, automation, permissions — is metadata, and the Metadata and Tooling APIs let us put an org under source control and deploy changes through a real pipeline. This is the foundation of treating Salesforce as engineering rather than clicking.
Agentforce and Einstein AI
Salesforce’s AI layer — Einstein and, more recently, Agentforce for autonomous agents grounded in your CRM data — can be genuinely useful where the data supports it. We are honest about what it can and cannot do, and we ground it in real, governed data rather than shipping a demo that misleads.
Use cases
Custom development beyond the point-and-click ceiling
When declarative tools can no longer express the logic — complex validation, multi-system orchestration, bespoke UI — we build it in Apex and Lightning Web Components, tested and version-controlled.
Integrating Salesforce with the rest of the estate
Connecting Salesforce to ERP, billing, data warehouses and bespoke operational systems through APIs or MuleSoft, so records stay consistent across the business instead of being re-keyed or drifting.
Rescuing an over-customised org
Auditing a sprawling org, removing dead fields and automation, resolving conflicting triggers and Flows, adding test coverage and documentation, and restoring a safe path to production.
Automating operational processes
Building reliable, maintainable automation across Sales and Service Cloud — approvals, case routing, renewals — with the logic consolidated and observable rather than scattered across the org.
When Salesforce is the right choice
- Right when you already run Salesforce as your system of record and need genuine engineering on top of it — custom Apex and Lightning Web Components, integration with bespoke or legacy systems, or automation that has outgrown what an admin can safely build with clicks alone.
- Right when Salesforce is inheriting or feeding data from the rest of your estate — an ERP, a data warehouse, a bespoke operational system — and the integration has to be reliable, observable and correct rather than a nightly CSV import that quietly breaks.
- Right when an existing org has become an over-customised mess — hundreds of fields, overlapping automations, conflicting triggers and Flows, no test coverage — and you need someone to stabilise it, document it and make it safe to change again.
- Wrong for a small team that just needs a CRM. If you have a handful of salespeople and straightforward pipeline tracking, Salesforce is expensive and heavy for the job — a lighter CRM, or HubSpot, will cost less, onboard faster and demand no specialist to run. We will tell you this rather than bill you to implement something you’ll resent.
- Wrong as a general-purpose application platform for problems that have nothing to do with CRM. Salesforce’s governor limits, per-user pricing and opinionated data model make it a poor host for high-volume transactional systems or bespoke products — build those where they belong and integrate them with Salesforce, rather than bending the platform around them.
Salesforce: pros and cons
Strengths
- A vast, mature ecosystem: standard CRM features, a huge AppExchange marketplace, a deep talent pool and documentation for almost anything you need to build.
- A genuine platform beneath the CRM — Apex, Lightning Web Components, Flow and a well-defined metadata and API model — so custom development and integration are first-class, not bolted on.
- Strong declarative tooling in Flow means a large amount of automation can be built and maintained without code, keeping simpler changes in the hands of admins.
- Extensive, well-documented APIs (REST, SOAP, Bulk, Streaming) and MuleSoft make Salesforce one of the more integrable enterprise systems once you know its model.
Trade-offs
- It is expensive, and the sticker price understates it: licensing is per user per month, and implementation, customisation and ongoing administration often cost more than the licences themselves.
- It accumulates technical debt with alarming ease — uncontrolled clicks-and-code customisation, overlapping Flows and triggers, and forgotten fields turn into a messy org that nobody can safely change.
- Governor limits constrain Apex hard: caps on query rows, DML statements, CPU time and callouts mean code that would be trivial elsewhere has to be written carefully to run at all.
- Vendor lock-in is significant. The data model, automation, code and integrations are all Salesforce-specific, and moving off the platform later is a substantial, costly undertaking — a real strategic consideration, not a footnote.
Architecture
Salesforce is a multi-tenant platform, which shapes every architectural decision. You do not run your own instance; you share infrastructure with every other customer, and the governor limits exist precisely to stop any one tenant monopolising it. That constraint is the single most important fact about building on Salesforce, and designs that ignore it fail in production even when they pass in a sandbox with three test records.
The right architecture leans on the platform’s own model: standard and custom objects for data, a clear layering of automation so that a given change runs through one predictable path rather than several competing ones, and Apex reserved for what declarative tools genuinely cannot do. We favour a "clicks before code" rule — but with the engineering discipline that most clicks-first orgs lack, so the declarative parts stay as maintainable as the code.
Everything is metadata, and we treat it that way: the org’s configuration and code live in source control, changes flow from developer sandboxes through integration and staging environments to production, and nothing reaches production by being clicked directly into it. This is unremarkable engineering practice everywhere else, and unusually rare on Salesforce — which is exactly why so many orgs become impossible to change safely.
Performance and governor limits
Performance on Salesforce is governed less by raw speed and more by limits. Apex runs inside hard caps — on the number of SOQL queries, DML statements, rows retrieved, CPU time per transaction and callouts to external systems — enforced per execution context. Code that would be a trivial loop elsewhere throws a limit exception here if it queries or updates records one at a time inside a loop. Bulkification, where operations work on collections of records, is not an optimisation on Salesforce; it is the price of admission.
The other common performance failure is data: SOQL queries that are not selective, or that scan large objects without the right indexed fields, slow to a crawl or time out as record volumes grow. We design objects, fields and queries with volume in mind, use asynchronous processing — Batch Apex, Queueable, Platform Events — for large workloads, and keep synchronous transactions well inside their limits.
For high-volume data movement, the Bulk API and Platform Events exist precisely because record-by-record integration does not scale. We choose the right integration pattern for the volume, rather than discovering the limit in production when a nightly sync of ten thousand records fails halfway through.
Security and access
Salesforce has a mature, layered permission model — profiles, permission sets, roles, org-wide defaults, sharing rules and field-level security — and its expressiveness is both a strength and a trap. Configured well it enforces least privilege precisely; configured carelessly it becomes an unauditable tangle where nobody can say who can see what and why. We design the access model deliberately and document it, favouring permission sets over profiles for maintainability.
In code, security is not automatic. Apex runs in system context by default, bypassing the sharing and field-level security the user would normally be subject to, so we enforce it explicitly — "with sharing", stripped fields, and CRUD/FLS checks — rather than assuming the platform protects data it does not. Integrations authenticate through OAuth and connected apps with scoped, rotated credentials, never a shared admin login.
Salesforce holds regulated data by design and carries the compliance certifications to match, but the certifications cover the platform, not your configuration of it. The org’s security posture is your responsibility, and treating it as an engineering concern — reviewed, tested and documented — is how it stays trustworthy as the org grows.
Scalability
The platform itself scales — Salesforce runs some of the largest CRM deployments in the world — but your org scales only as well as it was designed. Scale problems on Salesforce are rarely about infrastructure and almost always about data volume and accumulated complexity: large objects with unselective queries, automation that fires cascades of updates, and code that was never bulkified hitting limits it never hit at launch.
We design for growth by keeping automation paths clean, queries selective, and heavy work asynchronous, and by using large-data-volume techniques — skinny tables, indexed fields, archiving strategies — before record counts make them urgent rather than after. The goal is an org where adding users, records and integrations does not mean rediscovering the governor limits the hard way.
The harder scaling challenge is organisational: as more teams customise the same org, changes collide. Source control, a proper release process and clear ownership are what let a Salesforce org grow across many teams without turning into the fragile mess we are so often called in to rescue.
Salesforce integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we deliver on Salesforce
We start by understanding the org as it actually is, not as the documentation claims. For an existing org that means an audit — what objects, fields, automation and code exist, what is live, what is dead, and where the risks are. For a new build it means designing the data model and automation architecture up front, so the org has a shape before customisation begins to erode it.
We put the org under source control from day one and work through sandboxes — developer, integration, staging — with changes promoted through a deployment pipeline rather than clicked into production. Apex is written test-first to clear the platform’s coverage requirement honestly, not with the empty assertions that technically pass and prove nothing. Declarative work is designed as deliberately as the code.
We favour configuration over code and standard features over custom, because every line of Apex and every Flow is something someone has to maintain. When code is the right answer we write it properly; when clicks are the right answer we keep them disciplined; and when the right answer is that Salesforce should not be doing this at all, we say so and integrate the system that should.
The service behind it
Delivered throughDigital TransformationWhat we build with Salesforce
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Salesforce in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Enterprise Platforms
Why teams choose us for Salesforce
We engineer, we don’t resell
We make no money on your Salesforce licences, so our advice is unconflicted. We are here for the platform work — development, integration and rescue — and we will tell you plainly when the honest answer is fewer licences, a cheaper edition, or a different tool entirely.
We treat an org as production software
Source control, a deployment pipeline, honest test coverage and deliberate automation design are standard for us and rare on Salesforce. That discipline is exactly what keeps an org safe to change as it grows.
We understand both sides of an integration
Because we build bespoke systems, data platforms and APIs as well as working on Salesforce, we understand the systems on the other side of an integration — so the connection is engineered end to end, not bolted onto a black box.
We rescue what others left behind
A great deal of our Salesforce work is untangling orgs that clicks-and-code customisation turned into something fragile. We are comfortable in that mess, and honest about how much of it needs fixing versus living with.
Typical timeline
- 01
Audit and discovery
One to two weeks. We map the org or the requirement — data model, automation, code, integrations and risks — and agree what is actually being built or fixed, and whether Salesforce is even the right place to do it.
- 02
Design
One to two weeks. Data model, automation architecture, integration patterns and access model decided deliberately, with source control and sandboxes set up, before any customisation begins to accrete.
- 03
Build and integrate
Several weeks, by scope. Apex, Lightning Web Components, Flows and integrations built and tested in sandboxes, promoted through the pipeline, with governor limits and data volume designed for rather than discovered.
- 04
Deploy and hand over
One to two weeks. Deployment to production through the pipeline, documentation of the org and its automation, and knowledge transfer so your admins can safely own what we have built.
How pricing works
- Salesforce licensing is a separate cost you pay directly to Salesforce — per user, per month, by cloud and edition. We do not resell licences and take no margin on them; our fees are for engineering, and we will happily tell you where a cheaper edition or fewer licences would serve you just as well.
- Implementation and custom development are priced by scope and seniority. The main drivers are the amount of genuine engineering — Apex and Lightning Web Components versus declarative configuration — the number and complexity of integrations, and the state of any existing org you are building on.
- Rescue and remediation work is scoped after an audit, because the cost is driven by how much accumulated complexity has to be untangled and how much test coverage and documentation has to be built to make the org safe to change again.
- Ongoing work — new automation, integrations, and keeping pace with Salesforce’s thrice-yearly releases — is typically a retainer or block of senior time, sized to how much the org changes rather than a fixed monthly fee for its own sake.
Hire Salesforce engineers
Need Salesforce capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Salesforce engineersCommon questions
Do you sell Salesforce licences or just do the engineering?
Only the engineering. We are not a Salesforce reseller and take no margin on your licences, which you buy directly from Salesforce. That keeps our advice honest — we have no incentive to recommend more seats or a pricier edition, and we will tell you when fewer of either would serve you just as well. What we charge for is custom development, integration and untangling over-customised orgs.
Our Salesforce org has become an unmanageable mess. Can it be fixed?
Usually, yes, and it is a large part of what we do. We start with an audit — cataloguing what objects, fields, automation and code exist, what is actually live, and where the risks are. From there we remove what is dead, resolve conflicting triggers and Flows, add the test coverage that lets you deploy safely, put the org under source control, and document it. Not everything always needs fixing; part of the job is being honest about what to repair and what to live with.
We are a small team — is Salesforce the right CRM for us?
Often it is not, and we would rather say so before you commit. For a small team with straightforward pipeline tracking, Salesforce is expensive, heavy and demands specialist attention to run well — a lighter CRM, or HubSpot, will usually cost less, onboard faster and need no admin. Salesforce earns its place when you need real engineering on top of it or serious integration with the rest of your systems. If you do not, we will point you at the simpler tool.
What are governor limits and why do they keep coming up?
Salesforce is multi-tenant — you share infrastructure with every other customer — and governor limits are the hard caps that stop any one tenant monopolising it: limits on how many queries, record updates and CPU seconds a single transaction can use. They are the defining constraint of building on the platform. Code that works fine on a few test records throws an exception in production if it is not written to process records in bulk, so we design for these limits from the first line rather than discovering them when a real data load fails.
Can you connect Salesforce to our other systems — ERP, billing, bespoke software?
Yes; integration is one of our core reasons for existing on this platform. Salesforce has extensive, well-documented APIs — REST, SOAP, Bulk and Streaming — and MuleSoft for heavier integration work. We choose the pattern that fits the volume and the systems involved, build it to be observable and resilient rather than a fragile nightly import, and because we also build bespoke systems and data platforms, we understand the system on the other side of the connection as well as we understand Salesforce.
Building on Salesforce?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.