Self-hosted, cloud or on-device: where software should run
Where a piece of software runs shapes its cost, its privacy and what happens when the internet drops. How we choose, with three real examples.
Before we write any code, we decide where it will run. It’s one of the few choices that’s expensive to change later, and it affects more than people expect: what it costs each month, who can see the data, how fast it feels, and what happens when the internet goes down.
There are three broad answers, and most of our projects use one of them.
In the cloud
The software runs on rented servers and people reach it through a browser or an app. It’s the default for good reasons: nothing to install, works from anywhere, and someone else worries about the hardware.
It suits software with many users in many places, especially software you sell. CenterSuite runs this way. Every learning center reaches it at its own web address, and each center gets its own separate database, so one center’s data can never leak into another’s, and one can be restored on its own.
The cost: a monthly bill that grows with use, and a dependency on the internet and on the provider.
On your own server
Self-hosted software runs on hardware you control: a server in the office, a box in a cupboard, or a machine you rent but manage. It suits private data, tools that must keep working when the connection doesn’t, and systems where per-user subscription costs have got out of hand.
Our self-hosted voice assistant is an example. Speech recognition and the voice run on a server at home, so what’s said in the kitchen isn’t streamed to anyone. Only the thinking goes out to an AI model, through a gateway that caps what it can spend, and everyday commands are handled locally without it.
Web Messaging mixes both. A Mac at home does the sending and receiving, a server relays everything, and the web app loads nothing from outside servers, which is why it works on a locked-down PC that blocks them.
The cost: someone has to look after it. Updates, backups and monitoring don’t happen by themselves unless they’re built in from the start, which is why we build them in.
On the device
Some software doesn’t need a server at all. It runs entirely on the phone or computer it’s opened on, and keeps its data there.
The Modern Person is one file under 140 KB. It works offline, keeps everything on the device, and needs no account. For a personal tracker full of private details, that’s not a limitation, it’s the point.
The cost: sharing is harder. If several people need to see the same data, something has to sit in the middle.
How we choose
We ask a handful of questions, roughly in this order:
- Who uses it, and where? One person, one office, or customers everywhere?
- How private is the data? Could it leave the building? Should it?
- What happens when the internet drops? Annoying, or the work stops?
- Who will look after it? An in-house person, us on a care plan, or nobody?
- What will it cost in three years? Not just to build: to host, license and maintain.
Usually the answers point clearly one way. When they don’t, we say so, explain the trade-off in plain terms, and you decide.