Software on demand means using an application over the internet as a service, without installing or maintaining it yourself: the provider runs the servers, applies the updates and bills you by subscription or usage, which is the model most people now call SaaS.
The phrase is older than the acronym. Before everyone said software as a service, vendors described the same idea as on-demand software: you ask for it, it is there, and you stop paying when you stop using it. For a business the useful questions are practical ones. How is it different from the licensed software you might already own, how will it be priced, when should you buy it and when build your own, and what does it take to run a product like this yourself. This guide answers those in order, and finishes with the infrastructure side for anyone considering building.
Table of contents
- What software on demand actually means
- How it differs from licensed and installed software
- Pricing models you will run into
- Build versus buy
- What it takes to run your own SaaS product
- Hosting the product you build
- How this fits the rest of the stack
- FAQ
What software on demand actually means
The core idea is simple. The software runs on the provider’s infrastructure, and you reach it through a browser or an API. You do not buy a copy, you do not install it on your own machines, and you do not patch it. One running system, operated by the vendor, serves many customers.
You have used it for years. Email, accounting packages, customer relationship tools, video calls and project boards all work this way. The phrase on demand emphasises the buying experience: you can sign up in minutes, add users when the team grows, remove them when it shrinks, and cancel without stranding an expensive asset.
A note on terminology, because the phrase attracts confusion. You will also see it used for high-performance computing portals, for custom software development commissioned as needed, and for a few product names. This guide uses the business meaning, which is the same as software as a service. If you want the model explained from first principles, the SaaS meaning and SaaS model posts cover it in depth.
What defines the model is not where the code runs, but who carries the operational burden. In the on-demand model, the vendor carries it: uptime, security patches, backups and scaling. That is what you pay for, and it is what you are trusting them with.
How it differs from licensed and installed software
Traditional software is sold as a licence. You pay once, or annually, for the right to run a copy on your own hardware, and you take on the work of installing it, upgrading it and keeping it secure. The purchase is a capital expense, and the software may stay unchanged for years.
On-demand software reverses most of those properties, and it helps to see them side by side.
- Cost shape: a large upfront licence and annual maintenance for installed software, against a recurring subscription or usage fee for on-demand.
- Updates: you schedule upgrades yourself for installed software, and the provider ships changes continuously for on-demand, whether or not you asked.
- Infrastructure: you supply servers, storage and backups for installed software, and the vendor supplies them for on-demand.
- Customisation: installed software can often be modified deeply, while on-demand products offer configuration, integrations and an API within limits.
- Data location: installed software keeps data on your systems, while on-demand keeps it on the vendor’s, which matters for compliance and exit.
- Time to start: weeks of setup for installed software against minutes for on-demand.
Neither is better in general. Regulated environments, air-gapped systems and workloads with extreme customisation needs still favour installed software. Most other business functions favour on-demand, because the operational work is rarely what makes a company different.
Pricing models you will run into
Pricing is where on-demand software surprises people, because the model determines how the bill behaves as you grow. It pays to recognise the common shapes.
- Per seat: you pay for each user, which is predictable and easy to budget, and gets expensive when many occasional users need access.
- Tiered plans: fixed bundles of features and limits, where the jump between tiers can be large and the feature you need sits in the higher one.
- Usage-based: you pay for what you consume, such as messages sent, records stored or compute time, which is fair and hard to forecast.
- Flat rate: one price for everything, simple, and usually paired with fair-use limits.
- Freemium: a free plan with paid upgrades, useful for trying the product and designed to convert you once you depend on it.
- Hybrid: a base subscription plus usage on top, increasingly common as vendors try to match price to value.
Three questions cut through most pricing pages. What is the unit that grows with my business: users, records, requests or revenue? What is the price at ten times my current size, not at today’s? And what does it cost to leave: can I export my data in a usable format, and is there a notice period? A product that is cheap at ten users and ruinous at a thousand is not cheap, it is a deferred decision.
Watch also for the features that sit behind the higher tier, such as single sign-on, audit logs and API access. They tend to be exactly what a growing company needs, so the real price is often the tier that includes them.
Build versus buy
Once you understand the model, the decision that follows is whether to use someone else’s product or build your own. The default should be to buy, because building a version of something that already exists is a slow way to spend money.
Buy when the function is not what makes your company distinctive. Payroll, email, accounting and support desks are solved problems, and the vendors have more engineers on them than you can afford. Buy when speed matters, because a subscription starts tomorrow and a build starts in a quarter.
Build when the software is the business, or when it encodes something competitors cannot copy: a workflow, a data model or an experience that is your edge. Build when off-the-shelf products force you to bend your process around them and the cost of the bending exceeds the cost of building. And build when the fees at your scale would exceed the cost of a small team running your own version, which happens less often than people hope.
A middle path is often the best: buy the commodity parts and build the thin layer that connects them and captures your specific logic. Be sceptical of the argument that building is cheaper because the licence fee is visible while the maintenance is not. A system you build is a system you run forever, with security fixes, upgrades and an on-call rota. Count that before you decide. The cost of building an app puts realistic numbers on it.
What it takes to run your own SaaS product
If you decide to build, or if you are a company that wants to sell software this way, the operational shape is worth understanding early, because it differs from building an app for internal use.
The first requirement is multi-tenancy: many customers use one system without seeing each other’s data. The common approach is a shared database with a tenant identifier on every row and every query, enforced in one place in the code. Separate databases per customer give stronger isolation at higher operational cost and suit larger or regulated customers. Decide early, as retrofitting tenancy is painful. The SaaS architecture guide goes through the options.
The second is the set of unglamorous components every product needs: authentication with password reset and ideally single sign-on, roles and permissions, subscription billing, transactional email, background jobs for anything slow, and an admin view for support. Then the operational duties: backups you have actually restored from, logs you can search, monitoring that wakes someone, and a way to deploy changes and undo them quickly.
Security carries more weight here than for an internal tool, because a single flaw can expose every customer. The securing SaaS applications post covers the essentials. Be ready for customers to ask about it, in questionnaires, before they sign.
Finally, plan for scale you do not have yet. You do not need to build for a million users, but you need a path: a stateless application tier that can add instances, a database you can upgrade, and file storage that is not the local disk.
Hosting the product you build
The infrastructure for a typical small SaaS product is smaller than the surrounding worry suggests. You need an application service running your backend, a relational database for tenants and subscriptions, somewhere to store uploaded files, a domain with a certificate, and a way to keep secrets out of the code. A background worker joins the list as soon as you send emails or run reports.
The choice that matters is how much of the operating burden you carry. Renting raw virtual machines gives you control and also gives you patching, monitoring, TLS renewal and failover to build. A managed platform takes those on: you deploy from a repository, the platform runs the process, restarts it when it fails and routes traffic, and the database is a managed instance with backups. For a young product with a small team, that is usually the right trade, because every hour spent on servers is an hour not spent on customers.
Autoscaling deserves a mention, because a SaaS product has spiky traffic: a launch, a big customer onboarding, an end-of-month reporting rush. A platform that moves you between plans within limits you set handles the spike without you being awake. Set the ceiling deliberately, so a bug or an attack does not become a surprise invoice.
How this fits the rest of the stack
A SaaS product is a running service and a database, and the question that decides your margins is what those cost while you have few customers and what they cost when you have many. The RunxBuild hosting calculator shows the service, the managed database and the bandwidth as separate lines, so you can model the launch stage and the growth stage before writing the first billing page. When you are ready, deploy the backend from a repository through the RunxBuild dashboard, attach a managed Postgres or MySQL instance from the database documentation, and read the autoscaling guide for how to set the floor and ceiling. Environment variables hold the secrets, logs show what happened, and rollback to the previous deploy makes the first risky release a little less risky.
Useful related references:
FAQ
What is software on demand?
It is software delivered over the internet as a service. The provider hosts, maintains and updates it, and you access it through a browser or an API on a subscription or usage basis, without installing anything. It is essentially the same thing as software as a service, or SaaS.
Is software on demand the same as SaaS?
For business purposes, yes. On-demand software was the earlier phrase for what is now usually called SaaS. Elsewhere the words can mean other things, such as high-performance computing portals or custom development commissioned as needed, so context matters.
What is the difference between on-demand and licensed software?
Licensed software is bought and installed on your own hardware, and you maintain it. On-demand software runs on the vendor’s infrastructure, is paid for by subscription or usage, and is updated by the vendor. The first offers more control, the second offers speed and less operational work.
What are the main pricing models for on-demand software?
The common ones are per seat, tiered plans, usage-based, flat rate, freemium and hybrid combinations. Compare them by the unit that grows with your business, the price at ten times your current size, and what it costs to export your data and leave.
Should I build or buy on-demand software?
Buy for commodity functions and when speed matters. Build when the software is your core business or encodes something competitors cannot copy. Remember that anything you build you also have to run, secure and upgrade for years, so count that cost alongside the subscription fees you avoid.