The full title of this post should really have been “Do not underestimate the cost per user on a small, well-planned project versus both a proof of concept and a ‘at scale’ system”, but that would have just looked silly.
One thing that is overlooked time and time again, and eventually catches up with every project, is that there is a jump in costs per active user when you go from a proof of concept to something that can work at scale before the advantages of a large-scale project starts bringing the costs back down.
Let me explain.
A proof of concept exists to answer a simple question. Will this work? Whether it is an application, a migration, or any other kind of system, particularly in a corporate environment, the aim is validation rather than longevity. The challenge comes when moving from that early validation to a solution that is robust, commercially sensible, and capable of operating at scale with a reasonable cost per user.
Between those two points sits a significant and often underestimated investment. It is the cost of building proper foundations.
This tends to appear most clearly in two common scenarios.
The first is the seemingly small project. For example, moving a limited number of users from one system to another, or implementing a narrowly scoped solution. The proof of concept is completed, the demonstration goes well, and confidence is high. Then the implementation costs are presented, and everyone has a heart attack. It only has ten users, so why does it cost so much?
The answer is that the cost is not driven by the number of users. It is driven by the need to build something correctly. Even for a small user base, the underlying architecture, security, supportability, and operational processes still need to be in place if the solution is to be reliable.
The second scenario is more subtle but ultimately more disruptive. A proof of concept is seen to work well, and the decision is made to move it directly into production. Initially, this can appear successful. It may run for months, sometimes even years, without major issues. However, without those foundational elements being in place, sooner or later things are going to go bang, and always at the least convenient moment.
When they do, they are rarely simple to fix. It is not a case of adding a little more budget or introducing a small process improvement. Instead, it often requires going back and rebuilding the core of the solution properly. By that point, the cost is usually higher than if it had been done correctly from the outset, as there is the added complexity of undoing or reworking what is already in place.
In effect, the cost has not been avoided, only delayed and now with interest.
When moving from a proof of concept to a production system, it is important to anticipate this increase in cost and to communicate it clearly to stakeholders. Likewise, when delivering something that appears small today but has the potential to scale in the future, the investment in solid foundations can seem disproportionate.
It is natural for that to prompt questions and resistance. However, it is worth being clear that reducing that investment rarely removes the cost. More often, it shifts it into the future, where it becomes more expensive and more disruptive to address.