The common law of business balance prohibits paying a little and getting a lot – it can’t be done. If you deal with the lowest bidder, it is well to add something for the risk you run, and if you do that you will have enough to pay for something better.

Attributed to John Ruskin

The cheaper the software development is, the more expensive it will be. When people seek to develop a product, it can be hard to understand all the costs that go into it. Software development can be like an iceberg in which 90% of the structure isn’t visible to the end user.

Beyond wanting to retain as much money as possible, cheap development can be appealing because it can seem like:

  • Development can occur anywhere
  • The software functions are simple
  • When the software is completed, other, more visible “higher value” items can progress
  • Software development isn’t that hard
  • Development really can occur anywhere. The problem is that accountability can be hard to ensure from a distance. When you don’t have the ability to directly supervise the hiring process, training, and code quality you have no way of knowing what you’ll really get. There are things you can do to mitigate the uncertainty that occurs with remote or offshore work, but they cost money and time and require expertise in software development. If you don’t have someone on your team with that expertise, remote/offshore development is a huge risk. Supervising a remote team is not the same as supervising a team on-site.

    Simple does not mean that a function is easy or fast to make. A really thorough exploration of the implication of the product can show the unintended consequences and supporting structures to operationalize the features. If there is any data that is supposed to be stored and retrieved, then your product will need some sort of storage and database.

    If your “high value” items are built on a fragile piece of software, then that value will quickly be lost as it breaks and loses customers or never functioned in the first place. You can’t rob Peter to pay Paul. That never turns out well.

    It is entirely possible for a developer to put a pretty face on a project to cover a mess of chunks of broken code underneath. Worse than that is a product that functions at the moment of release, but would require a complete rewrite to update because the developer didn’t architect the project well. Yes, many people can write some code. That is not the same thing as architecting a new product.

    Software development, like a lot of skills, is progressive. When you hire an inexperienced developer, you are paying for their education as much as you are their code. That balances out on a sufficiently large team and is part of the normal arc of growing new members of any profession. If you are going the cheap route, you’re probably going to be working with more inexperienced developers and that will be reflected in the ultimate cost.

    We’ve seen projects in which the initial development was an oozing pustule of code with functions distributed widely throughout because no one with sufficient expertise thought through the architecture and the implications for each of the functions/features upon it. This code quickly drags down the whole project when later developers attempt to update or add a feature and find they can’t because the scattershot code can’t be modularly replaced or improved. You can’t remove just the tumor, because the cancer has spread.

    Even worse than that is when a business falls into the sunk-cost fallacy and just can’t let go of some really nasty and fragile code. Rather than scrap it and start over, they spend an insane amount of money frankensteining more code on top of it to keep it limping along.

    The time you spend untangling a poorly developed product and repairing it costs more than the expense of the developers to test and correct the code, it costs customers. You lose revenue the product would have earned in the delay coming to market.

    There is a mistaken impression that producing software is so easy that high school and college students working alone are creating billion dollar companies. It is true there are prodigies; rare individuals whose monomaniacal devotion to a single product is the foundation for something larger. Though even they had early supporters and funders to enable their seed of an idea to scale.

    Even though finding a bargain on development is a bad idea, there are still many ways to prevent your project from bleeding money.

    Be wise about your development expenditures:

  • Map out the functions of your product to prevent wasteful redevelopment and inadequate architecture.
  • Learn about the process of software development to become an informed consumer so you understand what the developers are doing if not how they are doing it.
  • Have a software development-specific contract; buying software development is not the same as other services.
  • Get clear Statements of Work that show exactly what will be developed and what that code will do.
  • Have highly specific Acceptance Criteria and a plan for remediation if the software doesn’t meet that criteria.
  • Being wise about your expenditures will save you the costs associated with being unprepared and uninformed. Be frugal, but not cheap.

    Cheap is expensive, expensive is cheap.