The decision
Separate the cost of keeping the service available from the cost created by each customer and from exceptional support work. A single hosting figure hides storage growth, email, monitoring, backups, paid integrations and the people who resolve problems.
A worked example
Use an illustrative model: monthly base cost of 200 accounting units, 4 units per active customer and 12 support hours at 30 units. At 50 active customers the model totals 760 units. These are invented inputs, not supplier prices. Change one assumption at a time to see whether support, usage or the baseline drives the result.
Keep the assumptions attached to the calculation
Write a row for each cost with its unit, quantity, rate, billing source and owner. The base infrastructure line uses a monthly quantity; a messaging service might use messages; support uses time. Do not put them in one undifferentiated “server cost” cell. For the illustrative model, note that 50 means active customer organisations, not registered people. State what a support hour covers and whether onboarding is included. Where there is no verified supplier price, leave the rate unknown and show the formula rather than inventing a plausible-looking number. The model should distinguish evidence from a convenient planning input.
Test a few concrete operating changes
Start from the illustrative total of 760 accounting units. If support doubles from 12 to 24 hours while other inputs stay fixed, the total becomes 1,120 units. If active customers rise from 50 to 100 with support unchanged, the total becomes 960 units. These comparisons are arithmetic on invented assumptions, not a forecast of what growth will cost. They show why different cost drivers need separate rows. Add a scenario with a large document import, a temporary retry spike or onboarding several customers at once. Name the limit or operating decision that prevents each scenario from becoming an uncontrolled expense.
Use the model to assign operational responsibility
A spending alert is useful only if someone receives it and knows what can be stopped safely. Identify whether a limit applies per customer, per job or across the service, and what customers see when it is reached. Decide who reviews unusual usage, checks invoices and revises assumptions after a release. Do not silently reduce essential backups or monitoring to make a spreadsheet total look smaller. Compare actual charges and support work against the model at a cadence the team can sustain. A useful operating budget explains deviations and guides decisions; it does not require pretending that a growing product will have a perfectly stable bill.
Alternatives worth weighing
A simple fixed infrastructure can be easier to predict, while usage-based services connect spend to activity and can produce spikes. Self-hosting replaces some vendor charges with operational work. Compare realistic scenarios that include the people responsible for incidents and upgrades.
Where the plan breaks
Do not divide all costs by registered accounts when most are inactive. Match the denominator to the cost driver: active organisations, stored files, messages or processing jobs. Keep development investment separate and state whether taxes and payment fees are included in the model.
Before you commission the work
Which service bills per unit? What limit prevents a runaway job? How much support does an unfamiliar customer need? Bring the assumptions, not an unverified universal price, to the SaaS architecture discussion.