A data tooling vendor licences its product per environment plus per named seat. The platform team is about to give every pull request an ephemeral preview environment containing the full stack. Which change keeps the licence bill flat without abandoning preview environments?
Show the full answer Hide the answer
The deciding property
Whether the licensed component is on the path the pull request is changing. For the vast majority of PRs it is not: the branch changes application code and needs the tool present and functioning, not isolated. One licensed non-production instance with per-branch schemas or namespaces satisfies that, and the licence unit stops tracking PR volume.
The general rule: when a licence is priced on a unit your architecture can multiply without limit, the fix is to stop multiplying that unit, not to buy more of it. Environment count is unbounded by design once it is tied to branches; seats are not.
Why this is the right call
It keeps the developer experience the change was made for, it bounds the licence at one unit, and it is reversible in an afternoon. Where a PR genuinely does change the licensed tool's configuration, that small minority can be routed to a second licensed instance or to a schema with elevated isolation, which is a handful of environments rather than one per branch.
Why the other options fail
- Negotiate a higher count. This buys the problem rather than solving it. The licensed quantity now has to track a number that grows with team size and merge rate, and every renewal is a negotiation about a figure nobody can forecast. It is the right move only when the vendor will switch you to a consumption metric such as vCPU-hours, which is worth asking for explicitly.
- Replace the tool everywhere. Re-platforming production to fix a non-production cost. It takes on migration risk, retraining and a new operational burden to avoid a bill that a configuration change removes. Rip-and-replace is justified when the licence is structurally hostile at production scale, which is a different finding from the one in the stem.
- Cap concurrent previews. This converts money into lead time. The cap binds hardest on the busiest days, which are exactly the days previews are most valuable, and the cost reappears as developers waiting. Queueing a scarce licence is defensible for a genuinely expensive unit such as a per-GPU licence; it is not defensible when a shared instance would have worked.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| PRs routinely change the tool's own config or schema | Isolated licensed instances for that subset | Shared state makes the test meaningless |
| The vendor offers a consumption metric | Renegotiate the metric | Removes the structural mismatch entirely |
| The tool is on a hot path and self-hosting is trivial | Open-source equivalent in non-production only | Keeps production licensed and support intact |
| Licence cost already exceeds the migration estimate with payback under two years | Replace it | The arithmetic has flipped |
Common weak answers
"Ask the vendor for a dev licence" is a reasonable first phone call and not an architecture answer; it leaves the design coupled to a commercial favour that can be withdrawn at renewal.