How to Budget for a Software Product

At Option 4.0, we build software products for clients.

Occasionally, a client will ask us to provide a quote along the following lines:

“Estimate x months for development, and then the cost for maintenance only”

With modern software, you can’t divide your budget between “a development” phase and a “maintenance” phase.

Software is like a house: it is never finished.

The moment you set your software product in “maintenance-mode”, that is the moment your software product starts dying. That is the moment is starts to fall into irrelevancy and obsolescence.

Why? Because of a phenomenon called “requirements drift.” In this agile, fast-paced world, the expectations of your users are constantly evolving. Your software may be able to meet your users’ expectations today. However, those expectations evolve. User expectations are not a discrete target, they are a stochastic time series. Once you set your software in maintenance mode, your software will drift away from those evolving expectations. With time, your users will first grow frustrated with your software product, and eventually they’ll learn to hate it and look for alternatives.

When thinking about budgeting for a software product, we recommend clients to budget for a “product engineering team”, and not for “development, then maintenance”. At the beginning, that team will be mostly focused on feature development. As the product matures, the team has to pivot and absorb operational responsibilities. The team must progress to strike a healthy balance between new feature development and operational tasks. As per SRE (Site Reliability Engineering) principles, a distribution of about 50/50 is a healthy combination. This allows your engineering team to keep adapting the product to those evolving needs, while being able to provide mature operations.