Simple Pricing Models

When people look at a company's pricing page, they often judge it by how elaborate it looks. Tiers, add-ons, usage bands, and conditional discounts can seem like the work of a sophisticated business that has thought hard about its customers. The assumption behind this reading is that a complicated price structure signals a mature, serious product.

This article tests that assumption. The reasoning is weaker than it first appears. A complicated pricing structure does not prove a sophisticated business, and a simple one does not prove a simple business. To see why, we need a concept the source calls a deployment cost model, and we need to ask a different question about any price: what does it have to pay for?

Before reading the explanation, try the question below. Think about what a rival's simpler price might tell you about that rival's product, not about its marketing or finance team.

The source treats deployment cost as a spectrum with two ends. At one end, a product carries setup and integration costs that the vendor must recoup somehow. Those costs have to be built into what the buyer pays, so the pricing carries a burden tied to getting the product in place. At the other end, a product has no deployment cost to recover. There is nothing of that kind to recoup, so the pricing does not have to carry any setup load at all.

The source uses Intercom's Fin as its example of a product with no deployment cost. Walking through its details step by step shows how the concept applies in practice. The trace below follows the facts the source gives, one at a time.

It helps to picture the cost flow of a product as a sequence. Setup and integration are stages that consume effort, and the vendor has to pay for that effort somewhere. The diagram below shows the two situations side by side: one where setup and integration must be recovered through pricing, and one where that stage is absent.

In the left chain, setup and integration effort is real, and it creates a cost that the pricing has to recover. In the right chain, that stage is absent. Nothing needs recovering, so the price does not have to carry any burden tied to getting the product in place. The price itself may still be detailed or simple; what changes is whether a deployment load sits underneath it.

The central distinction in this article is between two dimensions that are easy to blur together. The first is the pricing model's complexity, meaning how many tiers, add-ons, bands, or conditions the price contains. The second is the setup and integration burden behind it, meaning how much effort getting the product in place requires. The two can vary independently, so two products can share a similar price structure while carrying very different deployment loads.

The comparison above is an illustration built for this article, not a source example. Product A and Product B are hypothetical. Each has a pricing structure and a setup and integration stage, and the diagram shows that the pricing structure does not tell you what the setup stage costs. The reading of a simple price as a clue about deployment load therefore depends on looking at the second row, not the first.

Suppose you are comparing two support products for a team. Product X charges per outcome and needs an hour or less to set up on an existing helpdesk, as the source describes for Fin. Product Y has a multi-tier plan with several add-ons, and the vendor's documentation describes a longer setup and integration process. Using the source's framing, you can ask two separate questions about each. First, what does the price look like? Second, how much setup and integration sits behind it, and so how much deployment cost does the pricing have to recover?

Product X's simple per-outcome price points toward low deployment effort, and it has no setup or integration fee to recover. Product Y's more detailed price does not prove commercial sophistication. What matters for deployment cost is the setup and integration work behind each price, and that is the thing you should compare.