Pricing Is a Product Decision Engineering Needs to Be In On

“Promise, large promise, is the soul of an advertisement.”
— Samuel Johnson, The Idler No. 40 (1759)

Put an engineering leader in the pricing discussion before the options narrow, with one job: cost each option the way you would cost any other product commitment. Pricing is a product decision. It has a build cost, a run cost and a set of things it makes hard to change later, and the people who own those costs should see them before the price is on the website.

The usual view runs the other way. Pricing gets decided by the CEO, product, sales and finance, because it is a commercial question about value, competition and willingness to pay. Engineering hears about it when the new pricing page is in review, or when the first customer on the new plan hits a limit the product doesn’t know exists. The reasoning is that implementation follows strategy. The flaw is that the packaging has already made architectural decisions by then, and nobody who owns the architecture was in the room to say what they would cost.

Packaging becomes architecture

Every line on a pricing page is a promise the system has to keep. Some are cheap. Many are not, and the expensive ones don’t look expensive from the commercial side.

A per-seat price needs a definition of a seat that the product can count and enforce. Is a deactivated user a seat? A guest? A service account? Each answer is a rule in code, and each one will be argued over by a customer at renewal.

A plan limit, such as “up to 10 projects” on the starter tier, needs an entitlement check at the point where a project is created, a clear message when the limit is hit, and a path to upgrade that doesn’t require a support ticket. If the limit is enforced by scattered checks of the form “if plan is pro,” every new plan means a hunt through the codebase. If it lives in one entitlements service that the rest of the product asks, a new plan is a configuration change, which is the case for configuration-driven development applied to packaging.

Usage-based pricing is the biggest step. Analytics data can be approximate. Billing data cannot. Metering that you invoice from has to be complete, deduplicated, attributable to the right account, auditable when a customer disputes a charge, and consistent with whatever usage the customer sees in the product. Late and duplicate events stop being an analytics nuisance and become revenue errors. Billing providers design for this: Stripe’s documentation on usage-based billing assumes you send it clean, per-customer usage events, and its API supports idempotent requests precisely so retries do not double-count. The provider handles the invoice. Producing the events correctly is still your job, and it is a data pipeline with financial-grade requirements. Treat the usage event as a contract between the team that emits it and the team that bills from it, the argument made in the post on data contracts.

Feature gating by tier ties entitlements to feature flags. Enterprise tiers often promise SSO, audit logs, data residency or a dedicated environment, each of which is its own project. Custom terms in large deals create one-off entitlements that the system has to represent somewhere other than a spreadsheet in finance. And the first time prices change, you discover whether plans were versioned, because existing customers almost always keep their old terms for a while.

None of this is an argument against any of these models. It is an argument that the choice between them carries engineering cost and lead time, and the people choosing should know what those are.

The case for keeping engineering out

The opposing view deserves a fair hearing, because it is not foolish. Pricing has to move at the speed of the market. A competitor changes its packaging, a large prospect asks for a different structure, the board wants a test of a higher tier next quarter. Add engineering to that conversation and you risk a meeting that turns every option into a list of reasons it cannot be done. Some engineering leaders do treat a seat at the table as a veto, and some will propose a general-purpose billing platform when the company needs one new plan.

Even so, the cost of leaving engineering out does not go away. It moves to later, where it is larger. A pricing decision that ignores what the system can measure gets made twice: once in the meeting, and again when the product cannot support it. The answer to an engineering leader who vetoes is a clearer brief, not an empty chair. The brief is to cost options, propose cheaper variants and name the lead time, and to leave the commercial call to the people who own it.

A useful check on which view is right at your company: count how many of the last three pricing or packaging changes launched on time with the product enforcing what was sold. If the answer is all three, the current process may be fine. If the answer is one, the gap is costing you more than a few extra meetings would.

What bad looks like

Picture a Series A company that announces a usage-based tier at its annual customer event. Sales starts quoting it the same week. Engineering learns the details from the announcement and finds that the event the price is based on isn’t tracked per account, isn’t deduplicated, and lives in an analytics tool that samples at high volume. The first invoices go out based on a best-effort query. Two customers dispute their bills, and the numbers in the invoice don’t match the numbers on the in-product dashboard.

Follow the cost through. Finance issues credits to settle the disputes, so the new tier’s first quarter of revenue is lower than forecast and harder to trust. The two disputing customers are among the largest on the plan, and their renewals are now at risk. The next quarter of roadmap goes to building the metering system that should have existed before launch, which pushes back the features sales promised to close the deals that justified the new tier. None of this shows up as a line item labelled “pricing”. It shows up as missed revenue, a slipped roadmap and an engineering team blamed for both.

Smaller versions of this happen constantly: a limit that sales sells but the product can’t enforce, a “free forever” tier with no abuse controls and real infrastructure cost, an enterprise feature promised in a contract with no ticket behind it. The gap between deployments and deals is where these live, and disciplined sales qualification only closes part of it, because the problem starts upstream of any single deal.

What good looks like

Engineering joins the pricing discussion while the options are still options. The engineering leader’s job in that room is not to veto a model. It is to answer a short set of questions for each one. Can we measure this unit accurately today, and if not, how long until we can? Can we enforce the limits, and what does the customer see when they hit one? Can we change prices and plans without a deploy? What happens to existing customers? What does a billing dispute look like, and can we answer it from our own data?

The answers shape the decision in useful ways. A value metric that the system already observes reliably is much cheaper to price on than one that needs new instrumentation. A launch can be staged so that the new plan is sold to a handful of design partners while metering hardens, before it goes on the public page. And the cost of the pricing work goes onto the roadmap next to everything else, instead of displacing it by surprise.

Cost of serving matters here too, and it runs in both directions. A plan that includes unlimited usage of something with a real per-use cost, such as compute-heavy processing or calls to a hosted model, can lose money on its heaviest customers. Engineering is usually the only function that can say what a unit of usage costs to serve. That is the same unit-cost conversation as explaining cloud and AI spend to the CFO, and it belongs in the pricing room for the same reason.

This is part of the broader point that a CTO has to understand how the company makes money (see the T-shaped CTO). Pricing is where that understanding turns into specific system design.

What changes by stage

Seed. Keep pricing simple enough that it needs almost no system support. A handful of customers on negotiated contracts, invoiced by hand, is fine. Don’t build a metering pipeline for ten accounts. The one thing worth doing early is cheap: route every plan or limit check through a single function, even if that function is a hard-coded lookup. That seam is what makes the next pricing change a small job.

Series A to Series B. Pricing changes often, because this is when most companies are still finding the value metric that tracks what customers get from the product. Plan this as an expected part of the roadmap. A real entitlements service, versioned plans and, if you move to usage-based pricing, billing-grade metering all belong here. Buying the billing system rather than building it is usually right; owning the metering and entitlement logic usually is too, because that logic is specific to your product, the split described in build, buy or wait at each stage. The choice of growth motion drives a lot of this: product-led growth puts self-serve upgrades and limits in the product, while sales-led growth puts more of it in contracts. A company moving from sales-led to product-led growth should expect its pricing work to move from the contract into the codebase.

Later stage. The work shifts toward finance and compliance. Revenue recognition, multiple currencies, tax, marketplace listings and enterprise contract terms all reach into the systems that hold usage and entitlements. Finance becomes as important a partner as product, and the accuracy bar on usage data rises again, because auditors will now test the numbers that customers were billed on.

What to ask for before the next pricing change

Name an engineering lead in the pricing working group, with the explicit job of costing each option. Ask for a one-page answer per option to “can we measure it, enforce it and change it,” with a lead time and a rough cost of serving. Require a plan for existing customers before any change is announced. And treat the launch date of a new plan the way you would treat any other launch: it goes out when the system can keep the promise on the page.

The question to take into the next leadership meeting: which promise on our current pricing page could the product not enforce or bill accurately today, and who would find out first, us or a customer?