Custom Salesforce Development: What You Need to Know

Executive summary

Custom Salesforce development is the work of extending the platform with code – Apex, Lightning Web Components, integrations and a data model shaped around how your business actually operates – when configuration and Flow cannot do the job. It matters because every line of custom code is an asset and a liability at the same time: it does something the platform cannot, and you own it through three Salesforce releases a year for as long as the org lives.

This guide covers the decision that should come before any build (configure, click, or code), what custom work costs and what drives the price, how a build should be run, how to keep it fast as data volumes grow, what Agentforce changes, and the seven questions worth asking any partner before you sign.

The main takeaway for a buyer: most teams need less custom development than they think, and the money is lost in the first week before anyone writes code when nobody separates what must be built from what could simply be configured.

TL;DR

• Custom Salesforce development earns its place when a process is genuinely specific to how your business makes money and no configuration or Flow can express it.
• It is a poor investment when it recreates something Salesforce already ships, or automates a broken process instead of fixing it.
• Flow now covers a large share of what used to require Apex. If a partner reaches for code on something Flow can do, ask why.
• Total cost of ownership – build, plus licences, plus ongoing release testing and maintenance – is the number that matters, not the build quote.
• In our experience the clearest signal in a partner conversation is whether they talk you out of anything.

Introduction

Salesforce works well out of the box for a large share of what companies need. The trouble starts at the edges a pricing rule nobody else has, an approval chain crossing four systems, a data model that reflects how your industry actually operates rather than how a generic CRM assumes it does.

That is where custom development earns its place, and also where a great deal of money gets spent badly. The difference between the two comes down to a decision made in the first week.

Configure, click, or code: the decision that comes first

Salesforce gives you three ways to change how it behaves, and they carry very different long-term costs.

	Configuration	Flow	Apex / LWC
What it is	Fields, objects, page layouts, record types, validation rules, permissions, reports	Declarative automation: record-triggered logic, screen flows, approvals, scheduled jobs	Server-side code and custom interface components
Who maintains it	Any admin	Any admin	A developer
Upgrade risk	Salesforce maintains it	Low	You own it — every release
Visible without a developer	Yes	Yes	No
Right for	What data you capture and who sees it	Most process automation	Volume, complexity, testability
Ongoing cost	Effectively none	Low	Real and permanent

When standard configuration is enough

If you are describing what data you want to capture and who should see it, you are describing configuration. Custom fields, objects, page layouts, record types, validation rules, permission sets, reports and dashboards all sit here. Salesforce upgrades them, any admin you hire understands them, and they cost nothing to maintain.

Do not write code for this. In our experience it is one of the most common and most expensive category errors in Salesforce projects.

When Flow is the right answer

Flow handles most process automation: record-triggered logic, screen-based guided processes, scheduled jobs, approvals, and callouts to other systems. It is maintainable by an admin, inspectable without a developer, and — importantly, and it surfaces errors instead of hiding them.

Flow’s capability has grown enormously. In our experience, a large share of the Apex written five years ago would be Flow today. If a partner reaches for code on a requirement Flow can express, ask them to justify it.

When you genuinely need Apex

Apex is Salesforce’s server-side programming language, and it is the right tool when logic is too complex, too high-volume, or too tightly coupled for declarative tools:

• Bulk processing of large record volumes, where Flow would hit platform limits
• Complex or interdependent calculations — pricing engines, multi-variable eligibility rules
• Integrations requiring custom authentication, payload transformation or retry and error handling
• Custom Lightning Web Components, where the interface itself is the requirement rather than a preference
• Logic that must be unit-tested and version-controlled as part of a wider release process

One test before you commit: if Salesforce shipped this natively next release, would we throw our version away? If yes, wait, or build the thinnest possible version. Salesforce CPQ is a useful cautionary example of how platform direction can change under work you have already paid for we cover that in our guide to Salesforce CPQ.

What custom Salesforce development actually covers

“Custom development” means building functionality with code rather than assembling it from what Salesforce already provides. In practice that is six things:

• Apex: Server-side logic, triggers, batch and queueable jobs, custom classes.
• Lightning Web Components: Custom interfaces where the standard UI genuinely cannot express the work. Visualforce still exists in older orgs but is not where new work should go.
• Custom objects, fields and data model design: The part that most determines whether the org still works in three years.
• Integrations: Connecting Salesforce to ERP, billing, data warehouse, marketing and product systems, by API, middleware or iPaaS. This is a discipline of its own; see our guide to Salesforce integration.
• Custom reporting and analytics: Where standard reports cannot express the metric the business actually manages by.
• Packaging and deployment tooling: The unglamorous scaffolding that determines whether releases are safe.

What custom Salesforce development costs

This is the question every buyer has and almost no page on this topic answers, so here is how the work is actually priced.

How firms price this work

Model	How it works	Best when	Watch for
Time and materials	Hourly or daily rate against agreed scope	Requirements are still moving	Requires trust and genuinely detailed reporting
Fixed price per deliverable	One price for a defined outcome	Scope is bounded and well understood	The risk premium is inside the number; change requests are where it goes wrong
Retained capacity	A set number of developer days per month	You already have custom code in production	Under-use is waste; agree how unused days roll over

Once custom code is live, retained capacity is usually the right shape, because the work genuinely never stops releases keep coming whether or not you have a project running.

What drives the number up

Driver	Why it costs
Number of integrations	Each system is an authentication model, an error path and a data-mapping negotiation.
Data volume	Logic that works on 10,000 records and logic that works on 10 million are different builds.
Data quality going in	Cleaning and migrating messy data routinely costs more than building the feature.
Number of stakeholders	Approval chains lengthen timelines more reliably than technical complexity does.
Existing technical debt	Building on five years of undocumented triggers is slower than building on a clean org.

The most expensive projects are rarely the most technically difficult ones. They are the ones where nobody agreed what the process was before development started.

How a custom Salesforce build should run

1. Define the outcome, not the feature. “Reduce quote turnaround from three days to four hours” is a brief. “Build a quoting tool” is not.
2. Separate what must be built from what can be configured: Explicitly, in writing, before estimating.
3. Design the data model first. Objects and relationships are the decisions you cannot cheaply unwind.
4. Build in phases and release small. One working capability in production beats four in a staging org.
5. Involve the people who will use it, in the design not in a demo at the end.
6. Write tests as you go. Salesforce requires code coverage to deploy; treating it as a box to tick at the end is how orgs end up with tests that assert nothing.
7. Plan the handover. Who owns this in six months, and what do they need to know?

If you are standing up or reshaping the org itself alongside the custom work, that is a wider exercise, see CRM implementation and enhancement.

Designing for scale: governor limits and performance

Salesforce enforces governor limits to protect shared infrastructure. They are not obstacles to work around; they are the platform’s design constraints, and code that ignores them works in a sandbox and fails in production once volumes grow.

Tactics that hold up at scale:

• Bulkify everything. Apex should assume it will receive 200 records, not one. Querying or updating inside a loop is one of the most common causes of production failure.
• Move long-running work off the synchronous path. Batch, Queueable and Scheduled Apex exist so heavy processing does not block the user or blow a limit at peak.
• One trigger per object, with logic in handler classes. Multiple triggers on one object produce execution-order problems nobody can debug later.
• Watch query selectivity. Non-selective SOQL against large objects fails once data passes a threshold and it fails suddenly, not gradually.
• Cache what does not change rather than re-querying it every execution.

Designing against these limits from day one is considerably cheaper than re-architecting after the org has grown into them.

Custom development in the Agentforce era

Salesforce’s platform has shifted meaningfully toward AI agents, and that changes what is worth building by hand.

Some of what teams historically built as custom screens and guided flows is better expressed now as agent actions with well-defined inputs and outputs. The custom development work moves rather than disappears: instead of writing the interface, you are writing the Apex actions the agent invokes, the data model it reasons over, and the guardrails deciding what it is permitted to do.

Two consequences worth planning around:

• Data model quality matters more, not less. An agent is only as good as the objects and fields it can read. Orgs with inconsistent data models get inconsistent agents.
• Permissions and audit become design features. Anything an agent can do on a user’s behalf needs an explicit boundary and a record of what it did.

If Agentforce is on your roadmap, it should influence the custom build you are scoping now, not be bolted on afterwards. Our Agentforce and AI agents service page covers the delivery side, and we compare the partner landscape in our guide to Agentforce implementation consultants.

The maintenance bill nobody budgets for

Custom code is not finished at deployment. Salesforce ships three major releases a year, and each one is a moment where custom logic can break, deprecate, or be quietly superseded by a native feature.

Ongoing ownership means:

• Regression-testing custom code against every release, in a sandbox first
• Monitoring scheduled and asynchronous jobs, which fail silently by default
• Retiring custom features the platform has since made redundant — a genuine saving that almost nobody claims
• Keeping documentation current enough that a new developer can work without archaeologyTotal cost of ownership is build cost plus licences plus all of the above. A build that comes in cheap and leaves a maintenance burden you cannot staff is not cheap.

How to vet a Salesforce development partner

Certifications and a portfolio are table stakes. These seven questions separate the good ones from the rest:

1. “What should we not build?” A partner who cannot name a single requirement that Flow or configuration could handle is either not listening or not incentivised to say so.
2. “Show me a project where the data model changed mid-build.” How they handled it tells you more than a polished case study.
3. “Who maintains this after go-live, and what does that cost?” Vagueness here gets expensive later.
4. “How do you handle Salesforce release testing?” If there is no answer, you are the release testing.
5. “What is your deployment process?” Hand-built change sets versus source-controlled, automated deployment is a real difference in risk.
6. “Which of your developers will actually be on this?” Certification counts belong to firms; work is done by named people.
7. “What happens if we bring this in-house in two years?” A partner confident in their work has a clean answer.

More on this in our guide to choosing a Salesforce partner.

Working with Mountainise

Mountainise builds and maintains custom Salesforce solutions as part of a wider revenue-operations practice, which means CRM work is scoped against how the business actually generates revenue rather than as an isolated technical project.

Our Salesforce work spans Sales Cloud implementation, Marketing Cloud, Data Cloud, Agentforce and AI agents, and CRM implementation and enhancement. Full detail is on our Salesforce consulting services page.

The short version

Custom Salesforce development is a good investment when it encodes something genuinely specific about how your business operates, and a poor one when it recreates what the platform already does or automates a process that should have been fixed first. Decide configure-versus-code deliberately, design the data model before the features, budget for ownership rather than just the build, and choose a partner willing to talk you out of things.

If you are weighing a custom Salesforce build, book a free working session with our team. Bring your requirements list and we will go through it with you and tell you which parts we would not build, which Flow can handle, and what the parts that genuinely need code are likely to involve.

Frequently asked questions