The SaaS Model: How the Business Works, the Metrics That Run It, and the Infrastructure Line Everyone Forgets

The SaaS model is software rented by subscription instead of sold once, hosted by the company that makes it, with the cost of running it paid by the company and recovered a month at a time. That last clause is the whole model. Revenue arrives slowly and predictably; costs, including the servers, arrive every month whether or not the customer renews. A SaaS business works when the monthly revenue per customer, minus the monthly cost of serving them, pays back the cost of acquiring them before they leave. Everything else is a detail of that sentence.

The pages that rank for this term are written by payment processors and billing platforms, and they are good on the revenue half: subscription tiers, sales motions, the standard metrics. They are thin on the cost half, and in particular on the infrastructure line, because their readers are finance people and the servers are someone else’s problem. If you are the person who will also run the servers, this post covers both halves.

Table of contents

• What the model actually is
• How the money moves
• The metrics that actually run the business
• Gross margin is where the servers live
• Pricing that matches the cost curve
• Sizing the infrastructure to the model
• How this fits the rest of the stack
• FAQ

What the model actually is

Three things distinguish SaaS from the software business that came before it, and each has a consequence.

The software is hosted. The customer opens a browser; the vendor runs the servers. Consequence: the vendor pays to run every customer, forever, and a customer who pays little but uses a lot is a loss.

It is paid by subscription. Monthly or annual, recurring until cancelled. Consequence: revenue is predictable and small per customer, so the business is a long game of keeping customers rather than a series of large sales.

Everyone runs the same version. One codebase, one deployment, updates arrive for all customers at once. Consequence: engineering cost does not scale with customer count, which is where the margin comes from, and a bad deploy affects every customer at once, which is where the risk comes from.

The SaaS meaning post covers the definition and what it implies technically. This one is about the business those three facts produce.

How the money moves

Revenue in a SaaS business is best understood as a bucket with a tap and a leak.

The tap is new subscriptions. Each new customer adds their monthly fee to monthly recurring revenue, MRR, the number the whole company watches. Annual plans are usually normalised into it by dividing by twelve.

The leak is churn: customers who cancel, and customers who downgrade. A business with $10,000 MRR and 5% monthly churn loses $500 a month it must replace before it grows at all. Churn compounds; at 5% a month, half of any cohort is gone within fourteen months.

The offset to the leak is expansion: existing customers upgrading, adding seats or crossing a usage tier. When expansion exceeds churn, the business has negative net churn, which means the existing base grows on its own, and that is the single most valuable property a SaaS company can have. It is also why usage-based tiers and per-seat pricing exist: they turn a customer’s growth into your growth without a sales conversation.

The three sales motions differ in how the tap is opened. Self-serve: a pricing page, a card form, no humans. Sales-assisted: a demo and a proposal for mid-sized customers. Enterprise: a long procurement cycle for a large contract. Most companies start self-serve because it is the only motion a small team can afford to run, and add the others as the deal size justifies a salary.

The metrics that actually run the business

Five numbers, and the relationships between them, are the model.

• MRR and its growth rate. The scoreboard.
• Churn, monthly, by customers and by revenue. Revenue churn is the honest one, because losing one large customer is worse than losing three small ones.
• Customer acquisition cost, CAC: everything spent on sales and marketing in a period, divided by the customers acquired in it.
• Gross margin: revenue minus the cost of serving customers, as a percentage. This is where infrastructure lives, and it is covered next.
• Lifetime value, LTV: the gross profit a customer generates over their expected life, which is average monthly revenue times gross margin divided by monthly churn.

The relationship that matters is LTV to CAC. If a customer costs $300 to acquire and produces $50 a month at 80% gross margin with 3% churn, their LTV is about $1,333 and the ratio is about 4.4, which is healthy. The same customer at 50% gross margin has an LTV of $833, and at 8% churn, $500, which is barely above what they cost.

Two of those three levers, margin and churn, are engineering problems as much as business ones. A product that is slow, breaks, or loses data churns. A product that costs too much to run has thin margin. The billing platforms’ articles treat these as inputs. If you build the product, they are outputs.

Gross margin is where the servers live

Cost of revenue in a SaaS business is everything spent serving existing customers: hosting, third-party APIs the product calls, payment processing, and the support team. A software company is expected to run at 70% to 80% gross margin or better. Below that, the business behaves like a services company, and investors, acquirers and your own cash flow will treat it as one.

Infrastructure is the largest controllable line in that cost, and it behaves differently from the others. It has a floor: the smallest production setup that runs the product for zero customers. It has a slope: what each additional customer adds. And it has cliffs: the moments when a database needs a bigger plan or a second instance is required.

The floor is what most early SaaS companies get wrong, in both directions. Some run the whole product on a $5 server with the database on the same box and no backups, which is a churn event waiting to happen. Others adopt a large cloud’s full menu on day one and spend a thousand a month serving twelve customers. The SaaS company post walks through what one actually runs; the short version is a web service, a worker, a managed database, object storage and a way to send email, sized for the customers you have plus the next tier.

The slope is the number to know before setting prices. If each customer costs $2 a month to serve and pays $29, the margin is fine. If each customer costs $12 because the product runs a heavy job per user per day, a $29 price has a problem the pricing page cannot fix.

Pricing that matches the cost curve

Pricing in SaaS is less about what the customer will pay than about aligning what they pay with what they cost and what they value. Four common structures:

1. Flat tiers. Three plans with feature gates. Simple to explain, easy to build, and the free or lowest tier usually loses money by design as an acquisition cost.
2. Per seat. Price scales with the customer’s team. Aligns with value for collaboration tools and creates expansion revenue as they hire.
3. Usage-based. Price scales with what the product does for them: requests, records, minutes processed. Aligns perfectly with infrastructure cost and is the hardest to forecast.
4. Hybrid. A platform fee plus a usage or seat component. This is where most companies end up.

The decision that matters for the cost side is the free tier. A free tier is a marketing expense paid in infrastructure. Set a hard ceiling on what it can consume, and know what it costs per free user, or it will quietly become the largest line in cost of revenue with no revenue attached.

Whatever the structure, the price should be set from the slope: know what a customer at each tier costs to serve, and make sure every tier is profitable on its own before the acquisition cost is counted.

Sizing the infrastructure to the model

The practical consequence of everything above is that a SaaS company’s infrastructure should be sized to the current customer count with headroom for the next tier, on a platform where the next tier is a plan change rather than a rebuild.

On RunxBuild, an early-stage product is typically a web service and a worker on the general plan ladder, a managed Postgres beside them, and storage attached for uploads. The API on the $20 BasicPlus plan (1 vCPU, 2GB), the worker on the $6 Basic plan, and the database on the $13 BasicMini plan is a $39-a-month floor that serves a first few hundred customers with backups, private networking between the services and the database, and deploy logs and rollback when a release goes wrong. Autoscaling between a floor plan and a ceiling plan means the slope is paid for as customers arrive rather than in advance, and the managed database has a connection limit and a plan ladder you can read, which is what turns the cliff into a line item.

The number to track is cost of revenue per customer per month, recalculated quarterly. When it rises, something in the product got more expensive to run; when it falls, you have room to lower a price or raise a free-tier ceiling. That number is the SaaS model, seen from the infrastructure side.

How this fits the rest of the stack

The SaaS model is recurring revenue against recurring cost, with the business living in the gap between them. Know your MRR, your churn and your CAC, but also know your gross margin and the infrastructure slope inside it, because those are the levers the product team holds. For a sense of what the serving cost looks like before customers arrive, the RunxBuild hosting calculator shows the API, the worker, the database and the storage as separate line items, which is exactly the floor-and-slope arithmetic a pricing decision needs.

Useful related references:

• SaaS Meaning: The Definition and What It Implies Technically
• SaaS Company: What One Actually Runs Under the Hood
• Securing SaaS Applications: The Boring Controls That Actually Prevent Breaches
• Managed Databases on RunxBuild
• Autoscaling on RunxBuild

FAQ

What is the SaaS business model in simple terms?

Software that customers rent by subscription and access over the internet, run on servers the vendor operates. The vendor collects a small amount every month from each customer and pays the cost of serving all of them. The business works when a customer’s subscription revenue, minus the cost of serving them, repays the cost of acquiring them before they cancel.

What is a good gross margin for a SaaS company?

Seventy to eighty percent or higher. Cost of revenue includes hosting, third-party APIs the product calls, payment processing and customer support. Below seventy percent the business behaves financially like a services company. Infrastructure is usually the largest controllable line, which makes sizing it correctly a margin decision, not just an engineering one.

What are the most important SaaS metrics?

Monthly recurring revenue, churn measured by revenue rather than by customer count, customer acquisition cost, gross margin, and lifetime value. The relationship between lifetime value and acquisition cost is the health check; a ratio of three or more is generally considered sound. Churn and margin are the two levers the product and engineering team control directly.

How much does it cost to run a SaaS product?

A small production setup is a web service, a background worker, a managed database and object storage. On RunxBuild that floor is around $39 a month at the plan sizes a first few hundred customers need, with each component able to scale to a larger plan as customers arrive. The number that matters for the model is cost per customer per month, which sets the floor for the price.

Should a SaaS product have a free tier?

Only with a hard ceiling on what it can consume and a clear number for what each free user costs to serve. A free tier is an acquisition expense paid in infrastructure. Without a ceiling it grows into the largest line in cost of revenue with no revenue attached; with one, it is a controlled marketing cost like any other.