Focusing on the high level estimate for your software project’s "grand vision" can result in misplaced efforts to cut corners or pick a vendor that could ultimately contribute to your failure. You should be working with a strategy driven team that works with you to define every release according to those features with the highest likelihood of driving maximum return on investment within your time and budget constraints.
It is often the case when starting a new software project that there are a lot of expectations from the client or customer. This is especially the case when they are new to the software development process. Customers commonly expect the project should not exceed “$X”, sometimes because that is the limit of their budget toward the software application component of their venture. They will often map out their budget through the “big release”, only to become upset that the total projected cost is beyond what they want/have to spend.
The Cycle of ROI
This is a logical fallacy, because they are not considering the cycle of ROI. Everyone has budget limitations, and one should always focus on getting the most bang-for-the-buck by targeting the release toward the smallest possible spend for the greatest possible return (profit).
In my experience, many unsuccessful software projects are characterized by a single round of development or a fixed investment upfront. If that initial release ultimately doesn’t produce results and they don't go any further, that technically is a project that didn’t go over budget, but also wasn’t successful. Not to suggest that a limited development investment was necessarily the cause, as the factors that contribute to the success of an application development project are numerous. But, rather, that the prospect of long-term development actually represents success that has justified further and ongoing investment in continued success. In essence, it’s the problem you always wanted to have.
Some of the most successful software products, ones that we use every day, started with a very modest first step. Development is undertaken in very small, carefully selected increments and driven by the end-user community’s feedback as they adopt and use it.
Take, for example, one of the greatest software successes in history, Microsoft Windows. In 1992 Microsoft released Windows 3.1, and gained widespread adoption. It had been a very ambitious endeavor, and the install took (an unheard of) six 3.5” floppy discs, and the total lines of code for that release is estimated at 2.5M lines of code  for a development investment in the broadly estimated at $65M  at the time .
That’s a lot, however the product was wildly successful and their next release, Windows NT the following year had an estimated development cost of $120M (**), ultimately spending over an estimated $5B in development of Microsoft Windows between 1992 and 2007.
That means that Microsoft’s initial release of Windows cost roughly 1.2% (less than 1/80th) of what they would spend in total over their first eight major releases. It was a drop in the bucket, but that release was essential in funding the subsequent release, and so on.
Sustained Development Investment = The Problem You Always Wanted
I often remind entrepreneurs and business owners who are developing a software product that if you end up having to continue investing to maintain or grow the product because it is so successful, that is actually the best possible outcome. The question they should be asking is "how do I get the most ROI fastest with the least possible initial investment?"
Trying to control long-term development cost arbitrarily is really setting your sights on failure, and as a product owner, your time is most valuable making the next release as successful as possible. There certainly should be some expectation that there's going to be a payoff that will necessitate further investment. However, there shouldn't be a mindset that you know that only “$X” dollars are going to be spent beyond the next release.
The Spirit of the Agile Development Process
I reflect on this challenge often. Custom software is developed most efficiently using an Agile delivery process that takes “baby-steps,” utilizing short iterations and incremental releases while avoiding making presumptions about how exactly the software system will be used. For customers new to software development, they almost always get nervous about financial predictability - “well this could take forever and it could cost a million bucks!”
That is an understandable feeling to have, and is actually one of the reasons why the Agile software development methodology was developed. This methodology provides a well tailored strategy using the agile process. Customers can actually spend far less and enjoy more success more quickly, and let end-user adoption and feedback drive the future of the product.
If you quickly align your product to your users’ needs, you’ll continue to invest into it, your customers will continue to buy into it, and you’ll be on track for long-term success with your software offering. Worst case, if your product isn’t going to succeed, you will have wasted the least possible amount of your time and money making that determination.
Tom DeGerlia is President of Denverdata Web, a Digital Strategy and Implementation firm specializing in digital marketing and web design and web development. Tom has over 35 years of software development and digital marketing experience. Feel free to contact Tom with your questions or comments.
 Software development releases and effort derived from https://informationisbeautiful.net/visualizations/million-lines-of-code/. The corrected source hyperlink for the Win 3.1 estimates is https://www.cnet.com/news/the-root-of-the-problem-bad-software/.
 2008-2010 estimated price per good line of code from two separate sources: https://www.embedded.com/a-million-lines-of-code/ ($40/good line of code in 2008) and http://betterembsw.blogspot.co.uk/2010/10/embedded-software-costs-15-40-per-line.html ($40/good line of code in 2010).
 Inflation factor calculator https://www.usinflationcalculator.com/ was used to adjust the estimated development costs for inflation.