What modern Salesforce development actually looks like

Most Salesforce projects don’t slow down because teams lack tools or knowledge. They slow down because the tools get applied in the wrong order, the wrong context, or without enough understanding of how they behave at production scale.

A Flow that works perfectly in UAT fails silently on 50,000 records. Apex code that clears governor limit checks in a developer org hits limits when three triggers fire in the same transaction. A deployment that looked straightforward in a sandbox requires rollback, manual cleanup, and an unplanned Friday evening.

This article covers what modern Salesforce development actually involves: the current toolkit, the architectural decisions, and the points where technical knowledge and real-world application tend to diverge.

What modern Salesforce development actually means

In practice, it covers:

• Tooling: VS Code with the Salesforce Extension Pack, Salesforce CLI, and Git for source control
• Declarative and programmatic balance: Flows, validation rules, and formula fields handle most automation; Apex handles what they can’t
• UI standard: Lightning Web Components, LWC, is the current framework for custom interfaces
• Governor limits: Salesforce’s execution limits define how Apex must be written; working around them produces code that breaks at scale
• DevOps: Source-driven development, scratch orgs, and deployment pipelines replace manual change sets on modern teams

Where teams struggle in practice

Understanding the tools doesn’t automatically translate to using them correctly. These are the points where Salesforce projects most commonly run into problems.

Flow vs Apex boundary

Teams that default to Flow for everything eventually build automation that’s fragile and hard to debug. Teams that default to Apex write code for things the platform handles natively. Both create unnecessary complexity, and neither feels obviously wrong until the problems surface.

Governor limit failures under real data volumes

Code that runs cleanly in a developer org with a handful of records frequently fails when real transaction volumes hit. SOQL inside loops, non-bulkified triggers, and synchronous processing of large datasets are patterns that don’t surface until production.

Data model decisions that compound over time

Object relationships and field architecture set early constrain everything that follows. Many performance issues and governor limit violations trace back to data model choices that seemed reasonable before the org matured.

Manual deployments with no visibility

Teams relying on change sets for every release move slowly and take on compounding risk. Without source control, there’s no audit trail and no clean path back when something breaks in production.

No shared environment standard

When developers work in different sandboxes with different configuration, differences accumulate quietly. Code that works in one environment fails in another, and the cause isn’t always obvious.

Modern Salesforce development environment

Five years ago, many Salesforce developers worked almost entirely through the browser: editing classes in the Developer Console, deploying via change sets, keeping track of changes with a spreadsheet or a prayer. That approach still works in small orgs. It doesn’t scale, and it makes collaboration genuinely painful.

The standard setup today is VS Code with the Salesforce Extension Pack, connected to a scratch org or sandbox via Salesforce CLI. Your code lives in a Git repository. You push and pull changes from source control like you would on any other software project.

It means Salesforce development now fits into normal software engineering workflows; teams can do code reviews, track history, run CI/CD pipelines, and deploy with confidence. It also means the skills transfer. A developer comfortable with Git, branch strategies, and deployment pipelines is useful on Salesforce projects and on almost anything else they might work on.

If you’re learning Salesforce development now, getting comfortable in VS Code and the CLI early is worth the effort. The Setup menu isn’t going away, but serious development work happens in the IDE.

The table below shows how development approaches compare. The difference is not theoretical. It shows up in how quickly teams can ship, how safely they can deploy, and how much time they spend recovering from avoidable problems.

Declarative tools first, and they’re better than you might expect

Salesforce has always promoted the “clicks not code” philosophy. For a long time, that was a bit aspirational. Early Workflow Rules and Process Builder had real limitations, and complex logic often needed Apex whether you wanted it to or not.

Flows changed that. Flow Builder now handles branching logic, loops, subflows, scheduled actions, and record operations. An experienced admin can build automation today that would have required custom code three years ago. That’s not a problem for developers; it means Apex gets used where it actually adds value, and the codebase stays leaner.

The general principle behind Salesforce development best practices: before writing Apex, exhaust the declarative options. Validation rules, formula fields, Flows, and standard automation cover a wide range of use cases without any code. Apex makes sense when you need:

• Integrations with external systems, HTTP callouts, OAuth, complex API response parsing
• Logic that would hit governor limits in a Flow
• Large-scale data processing, where Batch Apex or Queueable classes are more appropriate
• Server-side processing for Lightning Web Components

The decision isn’t always obvious. Part of what separates a capable Salesforce developer from a shaky one is knowing where that line sits, and not defaulting to code just because it feels familiar.

Lightning Web Components: what changed and why

Salesforce has two UI component frameworks: Aura, introduced in 2015, and Lightning Web Components, introduced in 2019. New builds use LWC. If you’re maintaining an existing Aura app, you’ll probably stay with Aura for consistency, though the two can coexist in the same org.

LWC is built on the Web Components standard, a set of browser-native APIs for building reusable components. That means LWC code looks much closer to standard HTML and JavaScript than Aura did. The component lifecycle, event handling, and data binding follow web platform conventions rather than Salesforce-specific abstractions. Developers coming from a web background find it significantly easier to pick up.

What this means in practice: you need to know JavaScript. Not advanced JavaScript, but a solid understanding of the DOM, promises, and ES6+ syntax is necessary to build and debug components effectively. Developers who treat Salesforce as a purely backend platform get stuck here. This is a consistent gap on teams where Apex has been the primary skill; the JavaScript debugging workflow, component state management, and browser tooling require a different mental model from server-side development, and the gap shows up during code review and debugging.

Visualforce still exists. You’ll encounter it in orgs that have been on Salesforce for more than five years. New development rarely uses it, but knowing what it is and how to read it is useful when maintaining older codebases.

Apex best practices: what writing it well actually requires

Apex is Salesforce’s server-side language. The syntax is close to Java, so developers with Java or C# experience pick it up quickly. But the syntax is the easy part. Writing Apex that works correctly inside Salesforce’s execution environment is where it gets interesting.

Governor limits are the defining constraint. Salesforce is a multi-tenant platform, many orgs run on the same infrastructure, so it enforces strict limits on what any single transaction can do. You can’t run more than 100 SOQL queries in a transaction. You can’t process more than 10,000 records with DML in one go. Exceed a limit and you get a runtime exception that fails the entire transaction.

This shapes how you write code. Apex best practices, including bulkification, separating logic from triggers, and avoiding SOQL inside loops, all exist because governor limits make certain patterns dangerous. Learning the syntax without learning the limits produces code that works in unit tests and breaks in production under real data volumes. It’s a pattern that shows up repeatedly in orgs that have had developer turnover: code that passed every test, deployed cleanly, and failed its first week in production.

Testing is mandatory: Salesforce requires 75% code coverage to deploy to production. But coverage percentages are a floor, not a goal. Tests that exist purely to hit 75% and don’t actually assert behavior are a common problem in inherited orgs; they don’t protect anything, and they give a false sense of stability. Tests that verify your logic works correctly, including edge cases and error conditions, are what keep a codebase maintainable.

Asynchronous Apex is worth understanding early. Salesforce applies different, usually higher, governor limits to async operations. Queueable Apex, Batch Apex, and Scheduled Apex each have different use cases. Batch Apex processes large record sets in chunks. Queueable classes let you chain async jobs and pass complex data. Scheduled Apex runs on a timetable. Knowing which to reach for when is a regular decision on real projects.

Salesforce DevOps and deployment practices

In a traditional Salesforce setup, you make changes in a sandbox and deploy to production via a change set. Change sets work. They’re also slow, brittle on complex deployments, and opaque; it’s hard to see what changed, and rolling back is painful.

Teams that skip a proper Salesforce DevOps setup don’t hit problems immediately. Deployments start requiring manual intervention. Environment drift makes bugs hard to diagnose. When something breaks in production, there’s no reliable way to trace what changed or roll it back cleanly. By the time it becomes urgent, the org is in a state that’s expensive to untangle.

The modern approach is source-driven development. Your org’s metadata, page layouts, Apex classes, LWC components, custom objects, lives in a Git repository. Changes go through branches and pull requests. Deployments use Salesforce CLI to push metadata from the source. Some teams set up CI/CD pipelines so that merging into main automatically triggers a deployment.

Scratch orgs fit into this workflow. A scratch org is a temporary, configurable Salesforce environment you spin up using a definition file. You do development work there, push to source control when it’s done, and discard the org. This keeps development environments clean and reproducible, and eliminates the “works in my sandbox, breaks in yours” problem caused by config drift.

If you’re new to Salesforce development, this part of the job surprises most people. It’s not just writing code. It’s understanding how changes move through environments and deploying them safely. Salesforce treats that as a developer concern, not just an admin one.

A structured approach to building modern Salesforce development capability

The gap most developers underestimate is not knowledge. It’s application. Knowing what governor limits are is different from consistently writing code that respects them across a full deployment. The same applies to declarative versus programmatic judgment, LWC debugging, and DevOps setup. Each area requires practice on real problems, not just documentation. Here is how to build the capability in the right order.

Step 1: Start with the platform model, not the language

Understanding how Salesforce is structured, how data flows through the org, and how the execution model works gives you the context to make good decisions. Developers who learn Apex before learning the org model frequently write code that works in isolation and fails in a real deployment.

Step 2: Learn the declarative layer properly

Most Salesforce problems can be solved without code if you understand Flows, formula fields, and standard automation tools. Knowing this before you write Apex tells you when Apex is actually needed, and keeps your codebase lean.

Step 3: Write Apex with governor limits in mind from the start

Not as an afterthought when code breaks in production. Bulkification, trigger patterns, and asynchronous processing are not advanced topics; they’re the baseline for Apex that works at scale. Learn them as part of the language, not after.

Step 4: Treat deployment as part of the development skill

VS Code, Salesforce CLI, and Git are the development environment. Understanding how metadata moves between environments, how to use scratch orgs, and how to deploy without breaking things is part of what it means to be a modern Salesforce developer.

The Salesforce Platform Developer I certification is a reasonable marker for foundational knowledge. It tests Apex, data querying, and the basics of LWC and deployment. If you’re working toward a developer role, the certification scope gives you a clear target to learn toward.

Build the Salesforce development capability your projects require

Modern Salesforce development is a blend of platform knowledge, programming skills, and deployment practice. The current baseline includes VS Code, Salesforce CLI, Lightning Web Components, and source-driven development.

The real challenge is not access to tools. It is applying them correctly under real conditions, with production data, unclear requirements, and years of accumulated configuration.

Teams that build this capability deploy more safely, maintain cleaner orgs, and spend less time fixing avoidable issues.

Frequently asked questions