You Didn't Deliver Your Salesforce Work. You Deployed It.

Order a couch online and two things can happen.

The truck pulls up and leaves boxes at your curb. That's deployment. Or the crew carries it in, figures out where you want it, assembles it, hauls off the old one, and leaves while you're already sitting on it. That's delivery.

Every Salesforce team ships the first one and calls it the second.

That's the core of episode 3 of the Revenue Engineer Podcast. My guest is Jason Lantz, founder of Muse Lab. He was one of the first two product hires at what became salesforce.org back in 2013, where his opening assignment was figuring out CI/CD for managed package development in a public open source GitHub repo, before Salesforce DX, before scratch orgs, before 2GP. What came out of that is CumulusCI, along with MetaDeploy, Snowfakery, and Mantecho. All open source, all still in use.

He's been working the same problem for 14 years. Here's what he's learned.

If you build on Salesforce, you've read about two development models: the org development model and the package development model. Jason's team coined a third one internally, the product delivery model, and the distinction is not academic.

A package is an artifact. It's not the product. Almost every ISV product on the AppExchange requires a pile of post-install setup, which is why every one of them ships a post-install guide. Early on Jason realized nearly all of that could be done through the API, and set an architectural bar for his team:

That bar came from an unusual pressure. salesforce.org was pushing NPSP out to tens of thousands of nonprofits, many of them small, many of them never paying Salesforce a dime, most of them run by an accidental admin who got handed the org. Those orgs don't have the resources for an elaborate manual upgrade every release. So the automation had to carry the whole way.

Most ISVs never face that pressure, because they can just go hands-on and bill for managed services. Which is exactly why the problem stays unsolved.

Deployment assumes a known destination. Sandbox to production, one path, one shape.

Delivery has to adapt. Every org you land in is different, so the process has to bring its own dependencies and adjust to what it finds. The example Jason uses is the one every Salesforce dev has been burned by: you cannot deploy a static page layout from GitHub into multiple orgs. You'll overwrite every customization the customer made.

Back to the furniture. You could write a rigid script that says carry the boxes in 20 feet and set them down. It works in exactly one house. Everywhere else you hit a wall.

Once you set delivery as the bar instead of deployment, the effects run past dev and QA. It changes how you build demo orgs, how you enable partners to implement for your customers, how customers implement for themselves. It stops being a DevOps concern and turns into a go-to-market advantage.

Here's the part that applies whether or not you're an ISV.

That space between "it deployed" and "it's actually usable" is what Jason calls the delivery gap. Almost nobody tracks it, because we paper over it. I know spinning up a new org costs me an hour of clicking, so I quietly pad the estimate. It never shows up as a line item, never shows up in a KPI. Salesforce development just looks slow.

Two questions to find yours:

• How nervous do you get when someone asks you for a new sandbox?
• If your QA org or your trial source org broke tomorrow, how long would it take you to rebuild it?

If the honest answer is days, that's the gap, and it's shaping decisions you don't realize it's shaping. It's the reason you don't let each team provision their own fully integrated org. It's the reason everyone shares environments and steps on each other's work.

That last one matters more every month. Teams across your org are now vibe coding things and wanting to contribute. If you can't hand them their own environment, you get five people and an AI writing over each other in the same sandbox.

Jason has had the same conversation with SI partners for years. Every engagement opens with roughly 160 hours of manual point-and-click setup, work no consultant enjoys and no customer sees value in. He tells them he can turn that into an automated job that runs in four hours while they go work on something else.

He gets exactly two reactions, and it's close to a 50/50 split.

• Fear.That's 150 billable hours gone.
• Opportunity.That's 150 hours back to spend on work that actually matters.

Which one you have tells you where you sit on the shift that's coming, and it's the same split happening right now with AI-assisted development. If hours are the unit you sell, investment in your own delivery process is impossible to justify directly. The return shows up as reputation and happier customers, which is real but hard to attribute. Worth noting: the partner program is moving toward outcome-based measurement. The incentives are catching up.

The obvious move is to point a model at the whole thing and say "handle delivery."

Two problems with that. The first is cost, and it's not theoretical. Jason burned a month of enterprise GitHub Copilot credits in 24 hours, deliberately using the lightest models he could. Token costs are going up, not down.

The second is that models are very good at writing one-off scripts and very bad at obscure frameworks. Ask one for CumulusCI YAML and it hallucinates confidently. Jason knows the framework well enough to catch it. Most people don't.

The answer is a mix. You define the delivery process as composable, adaptive automation with modular named actions. Then you put that in front of a model and let it compose and adapt a declarative plan, rather than free-running a script against your org. You collaborate at the level of the plan, not the commands.

That's the layer he's been building for two years. During the episode he demos a CumulusCI MCP server that connects to a GitHub repo, reads how CumulusCI is configured, and renders the YAML as an interactive app inside Claude. It uses MCP extension apps, which let a server embed a React UI the AI host renders directly. From there you can explore the dev workflow, load Snowfakery, have the model author a plan, and write the YAML back as a feature branch.

What that really solves is a UX gap. YAML files and CLI commands are fine for developers and completely silo the work from every admin on the team. Everything behind a command-line gate is invisible to most of the people who need it. AI is the first decent bridge across that.

Automating things is easy. Automating them securely is not, and this is where Jason spends most of his attention now.

The moment you let a model author a plan, you've handed it real power. Some CumulusCI tasks amount to command injection, since a task can run a CLI command. Even a plain metadata deployment can't be risk-rated in the abstract, because the risk depends entirely on the payload. You need contextual knowledge of what 's being deployed.

So he's building risk assessment into the tooling: a knowledge base of how each task's options could be abused, pointed at the model so it can assess the actual plan against the actual org before anything runs.

Then there's access. After 12 years of working with OAuth, Jason still had to re-read the docs nearly every time until about a year ago. It's easy to get a connection working. It's just as easy to get one working insecurely, and end up with an SFDX auth URL sitting around granting perpetual access to your org. That's exactly the class of thing Salesforce is cracking down on now with connected apps and token storage.

My take on that, and I said it on the episode: don't let the chat be the only gate. Whatever you build, put a second pass in front of it. A separate review on the PR, a different model checking the first one's work, something. The review step is not optional anymore.

That's the real argument for declarative plans. A plan you can read, assess, and approve before it ever touches an org is the only version of this that's safe.

If you're an ISV, CumulusCI was built for exactly your problems and tuned over a decade of real releases. Start with the docs.

The concept to understand first is the overlay merge. CumulusCI ships a universal config full of named flows and tasks, and your project layers its own overrides on top. The payoff is that one command, cci flow run dev_org, gives you a fully configured dev org in any project running it. It's the project's job to adapt the universal config to what the project needs. Once every repo has consistently named flows, CI/CD scripting gets easy and things like an MCP server become possible.

If you're not an ISV, the question still lands. Could a new teammate get a working org from your repo with one command? If not, that distance is your delivery gap.

Copy this and answer honestly:

We turned the whole framework into a free one-page guide: the deploy-vs-deliver test, the eight-step path to closing the gap, and this audit. It goes out to the newsletter list.

Revenue Engineer Episode 3 with Jason Lantz is on the walters954 YouTube channel. This is part of an ongoing series where people building real things on Salesforce show their actual workflow on camera, with the rough edges left in.

If this format is useful to you, subscribe on YouTube and sign up for the newsletter at revenueeng.com. New episodes and written breakdowns go there first.

Revenue Engineer is the community for working Salesforce professionals leveling up on AI-augmented development and modern GTM tooling. Weekly drops, live sessions, and a founding cohort opening soon. Join the waitlist and you'll be first in line.

Connect with Jason on LinkedIn, and ask him about Busbar, the managed package he's building now. It's a secure backplane that makes GitHub a sidecar extension platform for any org, so you can run GitHub Actions in any language against your Salesforce data with zero-trust authorization per workflow. No credentials to manage, so no credentials to steal. We're doing a part two once it's ready.

If you run the self-audit on your own team, drop a comment on the YouTube video and tell me which question hurt the most. I read every one.