If you have engineers who know Salesforce metadata inside out, time to let a pipeline mature, and a real reason to own the tooling, building can work. If you need results this quarter, need audit evidence on request, or would rather your team worked on the org than on the pipeline, buy.
Flosum's build-or-buy white paper boils the decision down to five factors: time to value, expertise, cost over time, security and compliance, and strategic focus.
Below you'll find what a homegrown pipeline involves across the Salesforce DevOps lifecycle, the Salesforce quirks that make it harder than it looks, and a decision matrix to fill in with your team.
What are you actually building?
A homegrown Salesforce DevOps setup usually means stitching general-purpose tools around the Salesforce CLI. In practice, there are six moving parts:
- Source control for metadata and code. Usually a Git repository, with a branching model you design and then have to enforce, whether you run two-week sprints or waterfall development.
- A CI server or runner for continuous integration and continuous delivery. It picks up commits and calls the Salesforce CLI to validate and deploy.
- Custom scripts for manifests, deletions, and deciding what ships.
- Automated testing: Apex test runs, quality gates that stop a release on failing tests or poor code quality, and any UI or integration tests you add later.
- Approvals and audit evidence. Often that's a ticket, a sign-off from business users, and screenshots that release managers pull together the week before the audit.
- Monitoring tools that flag a failed deploy, plus backup and rollback so a bad release can be undone quickly.
None of these is exotic; they're standard DevOps best practices. Our guide to building a CI/CD pipeline for Salesforce walks through each step.
Salesforce gives you decent raw material, too. Salesforce DX is built for source-driven development, where your version control system, not the org, is the source of truth. Salesforce describes it as managing apps across their entire lifecycle with modern DevOps best practices.
Scratch orgs make package-based development easier, and your team keeps the developer tools it already uses while everyone works from the same source.
Getting it running is a project. Keeping it running through three Salesforce releases a year is a job.
Where do homegrown Salesforce pipelines run into trouble?
General-purpose CI tools assume deploying software means shipping files. Much of the Salesforce platform is low-code configuration stored as metadata, and that metadata has habits a generic pipeline doesn't expect.
Start with what you can't deploy. Salesforce says some metadata types aren't available in Metadata API, so changes to them have to be made by hand in every org.
Some are missing from Salesforce DX source tracking, packaging, and change sets too, so your pipeline ships with a checklist of manual steps taped to it, and every one is a chance for human error.
Profiles come next, and they cause the most confusion. A retrieved profile only holds what you asked for in the same request (field-level security, for example, only comes back for fields on the objects you pulled with it).
On deploy, the profile is laid over the target org's settings, and a permission you switched off isn't exported unless you write it out as false.
Picture an admin who removes a permission in a sandbox before a release. The deploy succeeds, and the permission is still on in the production environment.
Merges are their own headache. Two people editing the same object or its page layouts can get false merge conflicts from a plain Git merge, just because of how the XML is ordered.
Someone sorts those out by hand, sprint after sprint, and larger teams hit them more often.
Then there are the limits. A Metadata API deploy tops out at roughly 39 MB compressed, production deploys have to be all-or-nothing, and Apex won't go live unless tests cover at least 75% of your code and pass.
And the Salesforce platform doesn't sit still. Salesforce ships new features in three major releases a year, with some products now updating monthly.
Old API versions retire on a schedule as well: 31.0 through 40.0 are deprecated from Summer '27 and retired from Summer '28, so any script pinned to one of them needs work before then.
You can still build. Just plan for the pipeline to become a product with an owner and a backlog, in effect a small DevOps team of its own.
The cost that never shows up on an invoice
Building looks cheap because the license line is close to zero. The money goes into engineering hours instead, and those keep coming long after go-live.
Engineering time is the line finance never sees, and every hour spent fixing the release pipeline is an hour not spent on the org.
Our guide to total cost of ownership lays out every cost category, and the hidden costs of manual deployments shows what your current process is costing you.
Want rough numbers for your own team? The DevOps ROI calculator asks 12 quick questions.
When building makes sense
We'd only build if all five of these are true for you:
- You have people who know CI/CD, Salesforce DX, and Salesforce metadata, and you expect them to stay.
- You run one or two production orgs, mostly code, with few profile-heavy changes.
- No audit deadline is looming, so hand-assembled evidence will do for now.
- Owning the tooling is part of your strategy, say because you sell Salesforce delivery as a service.
- Leadership is happy to wait while the pipeline matures.
Tick all five and a homegrown pipeline can serve you well. Give it a named owner and protected time every sprint, though, or it'll quietly fall behind.
When buying makes more sense
Mostly, when the pipeline isn't what you compete on. Look hard at buying if any of these sound familiar:
- You need to show results in a quarter or two.
- Auditors ask who changed what and who signed it off (SOX, HIPAA, and the like).
- Several teams release in parallel across production orgs, so merge conflicts and drifting environments are a weekly fight.
- Admins make a big share of low-code changes and need a way into the development process that doesn't require Git skills.
- Development and operations teams hand releases back and forth by email or spreadsheet.
- Release managers spend release night on manual steps, and nobody else could run it if one engineer left.
You still have to design a good DevOps process when you buy. What you skip is building and babysitting the tool underneath it.
Build vs buy decision matrix
Go row by row with your team. If most of your answers land in the right-hand column, buying is probably the better fit.
The first five rows come from Flosum's build-or-buy white paper. It digs into each factor and deliberately doesn't push one answer.
What about Lifecycle Center and change sets?
There's a third option people forget: the tools Salesforce already gives you. Salesforce says Lifecycle Center (formerly DevOps Center) is free and included with most editions, and change sets come with the platform.
For small Salesforce teams just beginning to implement DevOps, that's a reasonable first step. The catch with change sets is that a completed deployment can't be rolled back, so undoing a bad release means redeploying the old version yourself.
Outgrow them and you're back at the build-or-buy question, just later. If that's where you are, here's how to move off change sets.
One team that built first, then bought
Cushman & Wakefield ran its Salesforce releases on open-source tools before switching to Flosum.
It had SOX controls to meet, and according to the case study, that setup was hard to inspect for SOX and took a lot of technical expertise to run.
The case study puts it bluntly: low throughput, higher costs, and compliance gaps. After the move, the company reported a 3x jump in development and deployment velocity and 50% less time spent on release-to-production audits.
The pressure points in that story were audit evidence and how few people could run the pipeline. Check both in your own setup, because if you judge DevOps success by release speed alone, you'll miss them.
How to run the evaluation
Give it two or three weeks, not one meeting. Start by mapping your current Salesforce DevOps process from sandbox to production, then work through these steps in order:
- Count real capacity. Who would build the pipeline and who would maintain it? How well do they know Salesforce metadata, and what would they stop doing to make the time?
- List what you deploy. Check the metadata types your team changes most against Salesforce's unsupported types. Each manual step you find stays manual whichever way you go.
- Take a baseline. Measure deployment frequency, change fail rate, and how long it takes to restore service, using DORA metrics for Salesforce. Keep tracking the same performance metrics after go-live, so you can see whether continuous improvement is really happening.
- Ask vendors the awkward questions. Is the product a managed package inside your org, or does it run outside it? How do they handle version control, profile deployments, metadata merges, and rollback, and what audit evidence comes out?
- Pilot one real release. Run it through a vendor trial or a prototype pipeline built on the Salesforce CLI, test with realistic data, and time every step.
For step four, start with our roundup of Salesforce DevOps tools. One question sorts the right tools from the rest: will your admins and developers both use them?
Where Flosum fits
If buying wins, Flosum DevOps is built around Salesforce metadata and release management.
It merges each metadata type with its own logic, checks every change against a dependency graph of your org before deploying, and rolls back in one click with impact analysis.
Git is optional, because Flosum's metadata-aware version control can be your single source of truth. Changes from admins, developers, and AI agents all go through the same quality gates, approvals, and audit trail.
You can run Flosum Salesforce-native, in the Flosum-hosted cloud, or customer-hosted, whichever deployment model gets through your security review.
It's designed for enterprise Salesforce teams with many orgs and parallel release trains, where release management is a job in itself. And if Git is the sticking point for your admins, read our guide to version control without Git.
FAQs
Weighing build against buy for your own release process? Book a personalized demo to see how Flosum handles your metadata, approvals, and rollback.
Thank you for subscribing
