A SaaS company is a business that charges recurring subscriptions for software it hosts itself - and underneath almost all of them is the same short list of infrastructure, assembled in roughly the same order.
Most writing about this category is commercial: pricing models, churn, expansion revenue. That is legitimate and it is not what someone building one needs on day one. What they need is a straight answer about what has to exist for the product to be sellable at all.
Table of contents
- The technical minimum for something you can charge for
- The order that avoids expensive rework
- What it costs to run before there is revenue
- The operational habits that separate the survivors
- Scaling, when it eventually arrives
- How this fits the rest of the stack
- FAQ
The technical minimum for something you can charge for
Below this line you have a demo. Above it you have something a stranger can pay for, which is a meaningfully different object.
- Accounts and authentication, with a real password reset flow. Not a hardcoded login.
- Data separation between customers, enforced in the data access layer rather than remembered by developers.
- Persistent storage for records and for files, backed up, with a restore somebody has actually tested.
- A deploy path that produces a build log and can be reversed when a release is bad.
- Logs you can read when a customer says something did not work.
- Billing, which means a payment provider and a way to handle the failed-card path without a human noticing manually.
- A way to email people - receipts, password resets, notifications - that reliably reaches an inbox.
Seven items. None of them is your product, and the product cannot be sold without them. This is the gap between a prototype and a business, and it is where a great many promising builds quietly stall.
The order that avoids expensive rework
Sequence matters here more than in most engineering, because two of these are extremely painful to retrofit.
- Tenant isolation first. Before there is any data, decide how customers are separated and enforce it in the layer every query goes through. Retrofitting this into a codebase with two hundred queries is a genuinely bad month, and the failure mode while you do it is showing one customer another’s data.
- Authentication second. It touches everything and it sets the shape of permissions later.
- Deploy path and logs third. Before real customers, so the first production incident is a debugging exercise rather than an archaeology one.
- Billing fourth. Later than instinct suggests. Charge people manually for the first handful of customers - it is faster, and you will learn what your pricing should be before you encode it.
- Everything else after. Onboarding, admin tooling, analytics, integrations. All valuable, none blocking the first sale.
The two irreversible ones are tenant isolation and, to a lesser extent, authentication. Everything else can be improved incrementally without a rewrite.
What it costs to run before there is revenue
Smaller than most people expect, and the shape is more interesting than the total.
A small web service, a small API, a managed database, some object storage, a background worker, and bandwidth. At low traffic each of those is a modest monthly figure, and the sum is comfortably within side-project territory. The database is usually the largest single line, which surprises people who assumed compute would dominate.
The costs that actually hurt early are not infrastructure. They are the per-seat SaaS tools the company itself buys - error tracking, analytics, email delivery, a support inbox, a CRM - each individually reasonable and collectively larger than the hosting bill. Audit these quarterly; the compounding is real.
Where infrastructure cost becomes serious is bandwidth for anything media-heavy, and compute for anything doing per-request work that could have been cached. Both are engineering problems before they are procurement problems.
The operational habits that separate the survivors
Four practices, none glamorous, that predict whether a small product survives its first year of real customers.
Test the restore. Not the backup - the restore. Provision a fresh database from last night’s backup and confirm the application runs against it. Do this before you need to and then do it periodically. An untested backup is a belief.
Keep configuration in environment variables. Secrets never in the repository, configuration scoped per environment, changeable without a rebuild. This is also what keeps the application portable, which keeps your hosting decision reversible.
Make rollback boring. If reverting a bad deploy is a one-action operation you have used before, you will ship more often and panic less. If it involves remembering a procedure, you will hesitate to deploy at all, which is how teams end up with monthly releases and terrifying ones.
Put deploy logs and runtime logs in the same place. Most incident time is spent correlating what was released against what then broke. Systems that do not know about each other make a ten-minute problem into an hour.
Scaling, when it eventually arrives
The good news is that the six-piece architecture scales considerably further than its reputation suggests. The usual sequence when it strains is predictable: the database gets a read replica for reporting queries, the worker gets separated from the web process so slow jobs stop blocking requests, caching goes in front of the expensive reads, and the web tier scales horizontally because it was stateless from the start.
Notice that none of that is a rewrite, and all of it is easier if the application never kept state on local disk and never ran analytics against the production database. The decisions that make scaling straightforward are made at the beginning, cost nothing at the time, and are almost impossible to add later.
How this fits the rest of the stack
The infrastructure for a first version is short enough to price exactly, which is worth doing before rather than after the first customer. The RunxBuild hosting calculator breaks out the web service, the API, the database, the worker, the storage, and the bandwidth so the monthly number is a fact. RunxBuild deploys from GitHub in Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker with build logs, runtime logs, rollback, and autoscaling, alongside managed MySQL and Postgres with backups and private networking.
Useful related references:
- Application Service Providers: ASP, SaaS, MSP, and the Lineage
- Django Web Development: When to Hire a Team vs Build In-House
- Backend App Development Company: The Five Things the SERP Glosses Over (And What to Ask Instead)
- Services on RunxBuild
FAQ
What does a SaaS company need to launch?
Seven things beyond the product itself: accounts and authentication, data separation between customers, backed-up persistent storage, a reversible deploy path, readable logs, billing, and reliable transactional email. None of them are your product and none of them are optional.
What should I build first in a SaaS product?
Tenant isolation, before any data exists, enforced in the layer every query passes through. It is the one decision that is genuinely painful to retrofit, and the failure mode while retrofitting it is exposing one customer’s data to another. Authentication follows, then the deploy path and logs.
When should I add billing?
Later than instinct suggests. Invoice your first handful of customers manually - it is faster to set up and you will learn what your pricing should actually be before encoding it. Automate billing once the pricing has stopped changing every few weeks.
How much does it cost to run a small SaaS product?
Less than most people expect: a web service, an API, a managed database, object storage, a worker, and bandwidth. The database is usually the largest single line. The costs that actually hurt early are the per-seat tools the company buys for itself, which collectively exceed the hosting bill.
What makes a SaaS product hard to scale later?
State on local disk, analytics queries against the production database, configuration in files rather than environment variables, and tenant isolation that was bolted on. All four are free to avoid at the start and expensive to fix once there are customers.