Creating a new piece of software, or adding a new feature to some existing software, can often be done fairly quickly and inexpensively. And so the benefits of a new feature often seem to easily outweigh the costs of development.
In the grander scheme of things, however, all of the following economic factors need to be considered.
Small development efforts that can be completed quickly and reliably often deliver more economic benefit than larger efforts that take longer to deliver and are at higher risk of failure.
Developing a feature before it is definitely needed often results in a feature that is never used or one that requires significant rework before it becomes useful.
Developing a feature with at best a marginal return on investment is rarely worth the effort, since actual costs tend to exceed initial estimates, whereas actual benefits often have trouble living up to early projections.
Developing an application or feature that is already available from another source within the marketplace may prove to be a wasted effort.
Developing unique software for a particular customer is generally only economically beneficial if that software genuinely aids that customer in differentiating themselves from their competitors in the marketplace.
While features that are fashioned carefully to support existing business processes are often requested and appreciated by current customers, in the long term such software can be costly to maintain, if it must be reworked each time processes and customers and business trends change. It is often much more cost-effective to simplify and generalize the design so that it can be used more flexibly by a broader range of customers across a wider spectrum of business processes.
The costs of supporting a piece of software over its entire life span are often much greater than the initial development costs. What often gets ignored are the costs of sustaining a set of features over a decade or two or three, including data storage, backup and archival costs, as well as the cost of maintaining the software.
As technology ages and becomes obsolete over time, the costs of replacing existing software must also eventually be taken into account.
Each new feature necessitates additional regression testing which must be repeated with each new software release, to ensure that some other change has not inadvertently broken this feature.
As new features are added to a product, the overall complexity of the product increases, which tends to drive up maintenance costs, as it becomes more difficult to add additional features, or make additional changes. Such complexity also increases the cost of the eventual software replacement.
Developing a new class of software that is in its early stages is often more rewarding than continued refinement of an older piece of software that has been around for years if not decades. For example, developing a new client for mobile devices might be more financially advantageous than further refinements to a back-office application that is already working reasonably well.
Acquiring commercial or open-source software developed to be used by a broad range of customers with similar interests can often be more cost-effective than developing new software for a specific customer.
However, one must also consider the business model behind any potential software supplier. Will they survive, or go out of business and leave their customers without a viable path forward? Conversely, will they thrive, but only by continually charging customers for new releases that may combine necessary technical upgrades with unneeded new features, resulting in software bloat over time?