# Pricing Is a Product Decision, Not a Finance Decision **Date:** 2026-05-11 **Author:** Dan Maby **Categories:** SaaS, Product Strategy, Marketing & Business > Pricing architecture decides what gets built, who buys it, and whether the business survives. We argue it belongs in product design conversations from day one - not bolted on near launch by the finance team. [SaaS](https://blue37.com/blog/category/saas) | [Product Strategy](https://blue37.com/blog/category/product-strategy) | [Marketing & Business](https://blue37.com/blog/category/marketing-business) [View on blue37.com](https://blue37.com/blog/2026/05/pricing-is-a-product-decision-not-a-finance-decision) --- ## The pricing page is the product Earlier this year Bessemer published a playbook arguing that AI-native companies are abandoning seat-based SaaS pricing in favour of usage-, output-, and outcome-based models that directly align revenue with measurable results. That is not a finance memo. That is a product decision dressed in a pricing page. Whether you charge per seat, per token, per resolved ticket or per workflow shapes which features you prioritise, which telemetry you build, which customers you attract, and whether the unit economics hold up at the thousandth customer. This is the thing SaaS founders, and frankly a lot of consultancies, keep getting wrong. Pricing is treated as something the commercial team will sort out near launch, once the product is "ready". By then it is too late. The data model, the auth boundaries, the metering, the admin UI, the way trials work - all of it has been built assuming a pricing shape that may not survive contact with the market. Our position at Blue 37 is straightforward: if we are helping a client design a SaaS platform and pricing has not been on the table from week one, we are doing the job badly. ## Pricing decides what you build, not the other way around There is a comfortable myth in software that you build the product, then "figure out monetisation". Jason Cohen pushes back on this directly in [his essay on pricing and business models](https://longform.asmartbear.com/pricing-determines-your-business-model/), arguing that the pricing model you choose collapses the space of possible products you can sensibly build. A freemium-with-self-serve product is not the same product as an annual enterprise contract with a sales-led motion, even if the underlying code looks similar on day one. The practical consequences are everywhere once you look: - A per-seat model needs strong team and permissions primitives, invitation flows, seat reclamation, and admin reporting. If you bolt this on after launch you will spend months re-architecting auth. - A usage-based model needs accurate metering, idempotent event capture, customer-visible dashboards, and a billing pipeline that can survive a Stripe outage without double-charging. That is a significant engineering programme, not a setting. - An outcome-based model (pay when the AI resolves a ticket, drafts a document, generates a lead) requires you to define and instrument "outcome" with enough rigour that customers will pay against it and disputes can be resolved. As Bessemer note, unlike traditional software, delivering AI isn't free; cost of goods sold, specifically compute and inference costs plus humans in the loop, weighs heavily on monetisation strategy, and every AI query incurs a non-trivial expense. Get the pricing wrong and you can ship a product that loses money on every successful interaction. None of these are decisions you can defer to the marketing site. They reach into the schema. ## "What should we charge?" is the wrong opening question The GTM Newsletter put this well in [a recent piece on pricing model design](https://thegtmnewsletter.substack.com/p/how-to-price-your-product-a-pricing): pricing is not a math problem; pricing is a go-to-market decision that shapes how fast you sell, who buys first, how accounts expand over time, and how durable your revenue becomes over the long haul, and yet most founders still start with the wrong question: "What should we charge?" That is exactly the conversation we try to head off when scoping a new SaaS build. "What should we charge?" puts a number at the centre of a problem that is actually about structure. The better questions, the ones that change what the engineers do on Monday morning, are different: - Who is the buyer, and is it the same person as the user? Procurement-led buying changes everything about how the product needs to present itself. - What is the value metric - the unit that, when it goes up, means the customer is getting more out of the product? Seats, API calls, monitored assets, hours of audio, resolved tickets? - What does the customer have to commit to before they see value? Monthly, annual, multi-year? Self-serve credit card or signed order form? - How does the account expand without a renegotiation? Tiered upgrades, automatic overage, add-on SKUs? Answer those and the pricing page mostly writes itself. Skip them and you end up with a beautifully built product that nobody knows how to buy. ## The repositioning trap (and why "just charge more" is a product change) Founders sometimes ask whether they can simply raise prices once they have traction. Sometimes, yes. But the interesting case study from Jason Cohen on [repositioning to enable an 8x price increase](https://longform.asmartbear.com/more-value-not-save-money/) is instructive: the price change came alongside a deliberate change in who the product was for and what problem it claimed to solve. The software did not magically become eight times better overnight. The positioning, packaging, target buyer and surrounding service all moved. This is the part founders underestimate. A meaningful price increase is usually a product decision in disguise. It implies repackaging tiers, adding capabilities that justify the new price point for new buyers, possibly grandfathering or migrating existing customers, and often building new admin and reporting surfaces because enterprise buyers want them. We have seen teams try to skip that work and simply update the pricing page. It rarely sticks. The related point, made in [The GTM Newsletter's piece](https://thegtmnewsletter.substack.com/p/how-to-price-your-product-a-pricing), is that if procurement or finance gets involved early in the buying process, your pricing must feel legible and defensible, not clever, because a creative pricing structure that your internal champion loves but a procurement team can't categorise or benchmark will stall in approvals - procurement teams are trained to compare apples to apples. "Clever" pricing is a product liability, not a flourish. ## Our take We build custom SaaS platforms for a living, and the pattern we see again and again is this: clients arrive with a feature list and a rough sense that they will "probably do tiered pricing, maybe with a free plan". The features get built. The pricing gets discussed properly six weeks before launch. By then the data model assumes one account per company, the auth system has no concept of seats, the metering is approximate at best, and the admin UI cannot show a customer what they have used this month. Retrofitting all of that costs more than building it correctly the first time, and the launch slips while the team argues about packaging. A consultancy that does not raise pricing architecture in the first product workshop is not being polite, it is being negligent. Pricing is one of the highest-leverage decisions a SaaS business will make, and it is inseparable from the software itself. The model you pick determines the schema, the integrations, the dashboards, the support load and the gross margin. That is engineering territory, not a slide for the CFO to fill in later. That does not mean we expect founders to have a perfect pricing model on day one. We do not. Pricing should be revisited as the product and market mature - the consensus across operators like [Patrick Campbell](https://www.linkedin.com/pulse/profitwells-patrick-campbell-nuances-pricing-why-arent-collin-stewart) is that it deserves continuous attention, not a one-off decision. What we do expect is that the first pricing conversation happens alongside the first architecture conversation, and that the build is shaped accordingly. Optionality is cheap if you design for it. It is expensive if you discover you need it after the fact. ## If you are designing a SaaS platform If you are at the stage where you are scoping a new SaaS product, or trying to work out why your current platform feels stuck on the pricing page it shipped with two years ago, this is the kind of conversation we are built for. [Get in touch](/contact) and we can talk through where pricing architecture is shaping, or constraining, what you can build next.