Software as a Service

Software used to be bought like an object. You paid once, you got the right to run one copy, and that copy went to live on your own servers as your property. Once it left the maker's hands it aged separately at every customer site, so the company that built it had no idea how its own product was actually running out in the world.

That put a long gap between the day a contract was signed and the day anyone used the thing. A server had to be racked in the customer's machine room, an engineer had to fly out and install it, settings had to be bent to match internal policy, and only then did the first screen appear. Two or three months was normal. The selling side had it no easier. One bug fix meant sending a patch file to 300 customer sites and asking each of them to apply it, and because some sites were on 3.2 and others on 4.1, the same question got different answers. The first thing a new support hire learned to ask was which version the caller was on.

The shape of the money made the arrangement hard to sustain. A deal brought in 300,000 dollars the year it closed and then 60,000 a year in maintenance. A strong year did nothing to make the next year easier, so the company started from zero every January. Buyers were in the same bind from the other side. They paid the 300,000 up front, spent two months on installation, and only then found out whether the product fit — and if it didn't, there was no way to unwind it. Decisions got heavy, and heavy decisions got slow. Spending six months evaluating a purchase and then declining it was a common outcome.

SaaS turns that structure around. The software is never handed over; the maker keeps running it. Customers type an address into a browser and pay for the stretch of time they use. With no installation, work starts the day after signing, and when something needs fixing, one set of servers gets fixed and every customer has the fix that day. The money arrives in small amounts that stack up, which is why a separate unit for the portion that repeats every year — annual recurring revenue (ARR) — came into use alongside this model.

Delivery isn't the only thing that changed. A customer who no longer buys once but re-decides every month forces the seller to keep watching whether the product is actually being used after the deal closes. The signature used to be the end of the relationship. Now it's the start.

Six terms sit under SaaS in two groups. Four describe deployment structure — how one body of software gets divided among many customers. Two are neighbouring layers that rent out infrastructure and development environments the same way.

Deployment structure splits on what customers share and what gets kept apart. The screens look identical either way; what differs is how servers and data sit behind them, and that difference decides both unit cost and whether a security review is survivable.

1. Multi-tenancy — many customers share one instance of the system. Three hundred companies use the same servers and the same database, and their records are separated only by a customer ID attached to each row. Running one copy means costs don't grow tenfold when customers do, and shipping a feature puts all 300 on the same version the same day. Most SaaS products start here, and the ones that don't usually moved away later for a reason a specific customer forced on them.
2. Single-tenancy — each customer gets its own servers and database. Banks and public agencies that insist their data must not share a store with anyone else's can only be sold to this way. The cost is that 100 customers mean 100 environments to operate and 100 deployments for every release, which is why this usually sits behind a separate plan priced at a multiple of the standard one.
3. On-premise — the software is installed on the customer's own servers. This is the model SaaS displaced, and it has not gone away. Some organisations work on networks deliberately cut off from the public internet, and no amount of product quality lets those users reach a hosted service. Deals like that can be worth millions, so as a company grows, how far to accommodate the request becomes a genuine problem.
4. White label — the maker's name comes off and the customer's brand goes on. The support chat window inside a bank's app is often another company's product wearing the bank's colours. You build no brand of your own, but you land inside the screens of a company that already has the users, which can be worth more than recognition when the alternative is acquiring those users one at a time.

The two neighbouring terms occupy different layers on the same line. What separates them is what you rent. Rent finished software and it's SaaS; rent the environment for building and running software and it's PaaS; rent the servers and storage themselves and it's IaaS.

1. Platform as a Service (PaaS) — the whole environment for building and shipping comes rented. Push code and the provider handles server configuration, deployment, and adding capacity when traffic climbs. The renter writes code. This layer is why a team of three engineers can run a product with no systems administrator.
2. Infrastructure as a Service (IaaS) — only the base equipment is rented: servers, storage, networking. Installing an operating system and everything above it stays with the renter. It takes the most work and gives the most control, which is why companies large enough to care about the bill sometimes move back down to this layer.

The three layers stack. Pagedeck rents servers from an IaaS provider, puts deployment tooling on top of them, and sells the document collaboration product it builds that way as SaaS. The higher the layer, the less you can change and the less you have to think about — that's the trade. The usual analogy is dinner: rent the kitchen and the stove and you have IaaS, get prepped ingredients and a recipe and you have PaaS, sit down to a set table and you have SaaS.

The four deployment terms and the two neighbouring ones answer different questions. The first four are a choice about the shape in which you hand your product to customers. The other two are a choice about what you rent to build it. Pagedeck sells multi-tenancy to most accounts, opens single-tenancy to a few large ones, and runs both on IaaS. Using two of the four in one company at once is not unusual.

"This customer wants it installed on their own servers. We're SaaS, so that's a separate build."

The deal can't be closed with the product as it stands; closing it means building something else.

"The nice thing about SaaS is that what we fixed yesterday is what everyone runs today."

Nobody is mailing patches to individual customers on individual versions any more.

"If trials keep growing and paid conversions don't follow, SaaS math doesn't hold up."

Revenue accumulates in small monthly amounts rather than arriving in one lump, so when the accumulation stalls the floor comes into view quickly.

Pagedeck ran straight into this last quarter. Sofia brought in an enterprise account whose contract required that its data not sit in the same store as any other customer's. The deal was worth 400,000 dollars a year, so Sofia wanted to take it, and Theo came back with the operating cost of standing up a dedicated environment. Mia pointed out that opening the door for one account meant the next enterprise buyer would ask for the same thing.

Grace decided to make the dedicated environment its own plan at three times the standard price. The point was to sort acceptable deals from unacceptable ones by price rather than by judgement call. Since then the Pagedeck price sheet has carried a shared plan and a dedicated-environment plan side by side.

The same meeting settled that on-premise requests would be declined. A dedicated environment still runs on servers Pagedeck operates, so fixes move at the usual speed; installing on a customer's servers forks the version and commits the company to supporting that fork for years. Sofia wrote the rule straight into the sales material. Putting the conditions for saying no in writing saves having the same argument every time, and it gives a sales rep something to point at in the room rather than having to escalate the question and call the buyer back a week later.

The most common mistake is assuming anything reached through a browser is SaaS. There's no installer and the screen loads in Chrome, so the conclusion feels obvious. But the dividing line isn't the screen — it's how the money is collected and who carries operations. Plenty of companies sell a perpetual licence and install a web application on the customer's servers, and while that looks identical in a browser, it isn't SaaS. Miss the distinction and you'll introduce your company as SaaS during an investor review or a business type exercise, then have no number to offer when someone asks what your recurring revenue is.

The second is the belief that SaaS is always cheaper. Nothing large leaves the bank up front, so it feels that way. Stretch the timeline and it often flips. A tool for 50 people at 20 dollars per seat per month costs 60,000 dollars over five years, and if the same capability could have been bought outright for 40,000 and run in-house, the second option wins by year five. Comparisons therefore have to run on the total over the period you expect to use the thing rather than the monthly rate, and once server administration staff and failover planning go into that total it can tilt back toward SaaS. Take the cheaper claim on faith and you'll be explaining the line item in year three. Sellers fall for the mirror image of it: the subscription price looks small, so they set it low and only later notice that server costs and support headcount grow with the customer count. A price that covered its own costs at 50 accounts can stop doing so at 500, and raising it on customers who already signed is far harder than setting it correctly once.