AscendryxThe standard model is that one company builds the software and somebody else runs it. The developer is paid on delivery, hands over a repository and some documentation, and moves to the next project. On paper this is efficient. In practice it is the single biggest reason business systems decay.
Handover hides the cost of shortcuts
Every project has moments where a developer can do the careful thing or the quick thing. If the developer leaves at launch, the quick thing costs them nothing. The consequences arrive months later and land on somebody else, usually at an inconvenient hour.
When we host what we build, a shortcut taken in March becomes our problem at 2am in July. That changes the decision at the moment it is made, which is the only moment that matters. It is not that we are more virtuous. The incentive is simply pointed the right way.
The person who answers has seen the system
Most support arrangements put a first line between you and anyone who understands your setup. That layer exists to protect expensive engineers from cheap questions, which is reasonable for a product with a hundred thousand users. For a system with one client it just adds delay to every problem.
Our support goes to the people who wrote the thing. That only scales to a certain number of clients, which is why we take on a limited number of builds at a time and sometimes ask people to wait for a slot. We would rather say that plainly than take the work and degrade the service for everyone already on it.
Nobody argues about whose fault it is
Split responsibility produces a predictable conversation when something breaks. The host says it is the application. The developer says it is the environment. The client, who cares about neither, waits. We have watched that argument run for days.
If we build it and run it, there is nobody to point at. The fault is ours either way, so the only useful thing to do is fix it.
The honest disadvantages
This arrangement is not free of drawbacks and you should weigh them.
- You are more dependent on one supplier. We reduce that by writing ownership into the agreement and guaranteeing a data export in a usable format, but it remains true.
- We are a small team, not a hyperscaler. For workloads that genuinely need global infrastructure and a support organisation behind it, we will tell you so and help you scope it elsewhere.
- It costs more monthly than unmanaged hosting, because a person is watching it. If nobody would notice your system being down for a day, you may not need that.
What it looks like in practice
Nightly backups held away from the main machine. A watchdog that restarts services that stop responding and tells us when it does, so most incidents are over before a client notices. Security patching as part of the retainer rather than quoted each time. And a response time written into the agreement rather than invented per incident.
None of that is remarkable. It is the ordinary work of keeping software alive, and the only real question is whether it is somebody specific's job. In this arrangement it is ours.