We outlined this post in 2018 and never published it. The questions have not changed, so here it is.
Most software conversations are about the build. Almost none are about what happens after it, which is strange, because the build is the shortest part of a system’s life. If you have never taken a product through its whole lifecycle, you probably have these questions and nobody has answered them:
- What will the software cost in total, not just to build?
- Who hosts it after development?
- What does future development look like?
- How do I set a predictable long-term budget?
- Am I paying for bug fixes?
- What will the return be?
Here are the answers, as plainly as we can give them.
Software is an asset, and assets need maintenance
Like a building, a fleet, or a piece of equipment, custom software is an asset that needs regular attention to keep earning. The industry rule of thumb is that most of the total cost of owning software over its life is spent after the initial build, on running it, fixing it, and extending it. If you budgeted only for the build, you budgeted for the smaller half.
That is not a warning against building. It is an argument for planning the whole life of the asset from the start, which is exactly what most vendors skip because their engagement ends at launch.
Hosting
Nearly everything we build today runs in the cloud, and someone has to run it: environments, monitoring, patching, backups, security, and recovery when something goes wrong. You have three options.
- Your own IT team. Works when you have one that is comfortable with modern cloud infrastructure and has the time.
- The people who built it. They already understand the system, so problems get diagnosed faster and fixed once. This is what Managed Hosting & Support is, and it is what most of our clients choose, in their own cloud accounts so they can leave any time.
- A general hosting or IT provider. Fine for infrastructure, weaker when the problem is in the application rather than the server.
Whichever you choose, the accounts should be yours. Hosting is a service, not a hostage situation.
Bugs
Software has bugs. Custom software has them for the same reason a first-of-its-kind anything does: it has never existed before, and no amount of testing exercises every path real users will find. During the project, defects are fixed inside the budget. That is what testing at every stage is for. After launch, fixes run under a support agreement or reserved hours, and they should be budgeted from the start rather than treated as a surprise. Who pays for bugs covers the details and the mindset.
The next phase
Almost every system has more than one phase. The first release focuses on the highest-value features and is architected so the next phases can build on it rather than start over. It is common, and healthy, to pause new features for a while after the first release and spend a cycle or two on refinements and fixes that drive adoption. Then the roadmap resumes.
How much capacity you keep on the system afterward depends on how much the business changes. Some systems need a few fixes a quarter. Some need a small team working steadily. Some need a full team for years. The pricing page lays out those modes with typical costs, from reserved hours through a dedicated team.
Budgeting for it
Think in terms of a budget over years, not a price for a build. Before the first release ships, you should have a rough picture of year one, year two, and year three: hosting and support, a maintenance allowance, and the phases you expect to fund. Expectations set early are the difference between a system that keeps earning and one that becomes the thing nobody wants to spend on.
Budgeting for software maintenance has the working numbers, and custom software maintenance explained covers what the work actually is.
The return
The reason to think about all of this is that the return on custom software comes over its life, not at launch. A system that is well run, kept current, and extended in the right direction pays for itself many times over. One that is launched and abandoned decays until it becomes the legacy system the next team has to rescue. Across the clients we have worked with since 2005, the measured return has averaged 23 times the investment, and the systems that produced it were the ones someone kept running.
If you are approaching the end of a build and nobody has talked to you about any of this, that is the conversation to have now. Here is how getting started works, whether or not we built the system.