The per-org margin problem in Salesforce DevOps pricing

TL;DR: Most Salesforce DevOps tools meter by seat or by connected org. That is reasonable for an end customer with one production org, and quietly punitive for a consultancy carrying ten or twenty client orgs, because every new logo adds licence cost before it adds a billable hour. Standardising on one pipeline whose price does not move with org count turns tooling from a variable cost into a fixed one, and that is a margin decision before it is a quality one.

Why does per-seat and per-org pricing hit consultancies hardest?

An end customer grows along one axis: people. They have a production org, a few sandboxes, and a team that gets bigger slowly. A per-seat tool tracks that growth honestly.

A boutique SI grows along a different axis: orgs. Ten clients means ten production orgs, their sandboxes, and usually a scratch org habit on top. The bill is metered on precisely the axis the business expands on, and none of that expansion is billable by itself. Three structural problems follow.

• Cost lands before revenue. You connect and configure a client org during onboarding, which is usually fixed fee or absorbed.
• Churn is asymmetric. A client leaves, the contract term does not.
• It is hard to pass through. Clients will fund licences they can see inside their own org. They are far less willing to fund yours.

What do the published price lists actually meter?

Read the vendors' own pages, not the round-up summaries. Gearset publishes list prices: core deployment is charged per Gearset user per month, while automation and CI/CD is sold separately per team, with each tier including a fixed number of CI/CD target orgs. The org axis is real, it just sits in the automation line rather than in the headline number.

Copado does not publish list pricing. Essentials starts free and the enterprise tier routes to a consultation. For a partner that is its own kind of cost: you cannot model gross margin on a number you have to negotiate first.

Neither model is dishonest. Both were designed for a customer who owns the orgs. A partner who only borrows them is an edge case in that design.

What does the org axis do to a growing client book?

Model the shape rather than the numbers. If any line of your bill moves with connected orgs, tooling cost grows with the client list while revenue grows with billable hours. Those two lines diverge every time you win work you cannot immediately staff.

The step changes are what hurt. When an automation tier includes five target orgs and the next one includes fifteen, your sixth client can cost a whole tier more than your fifth. Nothing about that step reflects the effort of the sixth engagement.

Is standardising one pipeline a quality decision or a margin decision?

It is usually sold as quality: fewer failed deploys, a real audit trail, rollback you can put in writing in an MSA. All true. The bigger number sits on the cost side.

Per-client pipelines mean per-client tribal knowledge. The consultant who built a client's branching model becomes the only person who can release for that client, so utilisation gets pinned to individuals and holidays turn into delivery risk. One pipeline shape across the book changes three things.

• Onboarding a client becomes configuration rather than a project.
• Any consultant can cover any account, so utilisation stops being hostage to one person.
• Release evidence looks identical for every client, which makes audits and QBRs cheap to produce.

Standardising does not mean every client works identically. It means the stages are fixed (ticket, branch, validation, approval, deploy, rollback) and only the configuration varies.

What should you check before signing a DevOps contract?

1. Does any line of the price move with connected orgs? Ask for the figure at your current book and at double it.
2. Does it move with seats, and can a client stakeholder approve a release without buying one?
3. What happens when a client offboards mid-term?
4. Can a consultant who does not use Git run a release unaided?
5. Does the tool install anything in the client org? A managed package means client approval on the way in and an uninstall on the way out, every time.
6. If any client is an ISV, does the same pipeline cover 1GP and 2GP package workflows, or is that a separate purchase?

What changes when the price is flat per company?

Serpent prices per company rather than per seat or per org. Scale is $699 per company per month with unlimited users and $0 setup, and the price does not move whether you connect three client orgs or thirty. There is a free Essentials tier with 30 credits a month if you want to run a single account through it before committing.

To be straight about the metering: usage is credit based, so the meter tracks work rather than clients. A feature deployment is one credit, a release to production is two, an AI action adds one, a data operation is four, and Scale includes 300 a month. That is a variable your delivery volume controls, not one your sales team creates by winning a logo.

Two details matter specifically for partner work. Serpent installs nothing in the client org and connects over standard APIs, so onboarding needs no package approval and offboarding needs no uninstall. And because the workflow is ticket based with Git running in the background, the consultant covering an account does not have to be the one who built it.

FAQ

Is per-seat pricing always worse for a consultancy?

No. Four consultants covering twenty client orgs can be cheaper per seat than per org. The problem is that most contracts meter both, so you pay on whichever axis grows first.

Can we bill DevOps tooling back to the client?

Sometimes, as a line in a managed service retainer. It is much harder on fixed-fee implementation work, which is where most boutique SI revenue sits.

Does one standard pipeline mean every client gets the same branching model?

No. Keep the stages identical and let branching, environments and approval gates stay per-client configuration.

What about clients who are ISVs?

Check that package workflows are included rather than an add-on. Serpent covers 1GP, 2GP and AppExchange release workflows on every plan, including the free one.

How long does moving a client onto a shared pipeline take?

Serpent setup takes under 15 minutes per workspace and onboarding sessions are free, so the constraint is usually the client's change window rather than the tooling.