Salesforce DevOps Lessons From Web Summit Lisbon 2025

Web Summit Lisbon 2025 was not a Salesforce event, but Salesforce came up in nearly every serious conversation I had with founders and RevOps leads running their business on the platform. The pattern was consistent: teams still deploy metadata by hand, still dread Friday releases, and still do not have a real rollback plan. That is the exact gap Serpent exists to close.

I was not there to pitch a booth line. I was there talking to people between talks, in the investor lounge, and at Night Summit, and Salesforce DevOps kept surfacing as a problem nobody had solved cleanly.

Why did Salesforce release management come up at a general tech conference?

Web Summit skews broad, startups, investors, fintech, AI. But a surprising number of the people I met were running growth-stage companies on Salesforce, either as their CRM of record or as the backbone of a partner ISV product. Once the conversation moved past "what do you build," release pain came up almost every time, usually unprompted.

The common thread was that Salesforce admins and developers had outgrown change sets years ago but were still stitching together sandboxes, spreadsheets, and Slack threads to coordinate a release. Nobody I spoke with described their deployment process as something they trusted.

What deployment pain did founders and teams describe?

A few specific complaints repeated across unrelated companies:

• No reliable way to see what is actually different between a sandbox and production before deploying.
• Merge conflicts in metadata that only surface after a deployment fails, not before.
• Manual profile and permission set updates that get forgotten between environments.
• Release windows that depend on one person being available, because they are the only one who understands the deployment order.
• Rollbacks that mean restoring from a backup rather than reverting a single change.

None of this is exotic. It is the same short list of problems Salesforce DevOps tooling has been chipping away at for a decade. What stood out was how many teams, some well past Series A, were still solving it with discipline and tribal knowledge instead of a platform.

How does this validate Serpent's direction?

Serpent was built around the idea that Salesforce release management should look like modern software delivery: version-controlled metadata, environment diffing you can trust, and a deployment pipeline that catches conflicts before they hit production, not after. Every conversation in Lisbon reinforced that this is still the gap, not a solved problem.

What changed my view slightly is how many of these teams were not Salesforce-only shops. They were comparing Salesforce release discipline to the CI/CD they already run for their web stack, and finding Salesforce lagging badly. That is a useful framing when you are showing someone what Serpent actually does, because you are not explaining DevOps from scratch, you are explaining why Salesforce has been behind.

A few people asked directly how Serpent differs from tools they already knew, Gearset especially. Worth reading our Serpent versus Gearset comparison if that is where you are starting your evaluation.

What should you take away if you are evaluating a Salesforce DevOps tool?

If any of the pain points above sound familiar, the fix is rarely more process. It is tooling that removes the manual steps: automated diffing, a pipeline that blocks bad merges, and a rollback path that does not require a full backup restore. Salesforce's own application lifecycle management guidance makes the same point, ALM only works when the tooling enforces it consistently.

If you want to see how that looks in practice, our pricing page breaks down what it takes to get a team off manual deployments, and there is more detail on setup in our Salesforce DevOps guides.

FAQ

Why does Salesforce DevOps matter outside of Salesforce-specific events?

Because most growth-stage companies now run Salesforce alongside a modern software stack, and founders increasingly expect the same delivery discipline from both.

What is the most common Salesforce deployment mistake founders described?

Relying on one person's tribal knowledge of deployment order instead of a repeatable, version-controlled pipeline.

Is Salesforce release management different from general CI/CD?

The principles are the same, but Salesforce metadata dependencies and org-specific configuration make generic CI/CD tools a poor fit without Salesforce-aware tooling.

How is Serpent different from manual change sets?

Serpent replaces manual change set assembly with automated diffing, conflict detection, and a pipeline built specifically for Salesforce metadata.