Why are software development costs generally (whether upfront or through the project) so much higher than a business owner might expect?

Article at a Glance:
  • Development Takes Longer than You Think
  • Scope Creep/There isn’t a Plan for the Software

“That’s outrageously expensive!” is one of the main complaints a software development firm will hear from a would-be customer. Most businesses tend to underestimate either the time or the cost of having enterprise level software created, so where does it all come from?

Development Takes a Lot Longer Than You Think

The biggest surprise to people is the fact that custom software takes a lot more manpower and hours than people really realize. It is considered “extraordinary” that it ONLY took 400 hours to build the first version of the BaseCamp software many companies rely on for project management and day-to-day operations.

A service based business (especially in the United States) also gets to pay for all the wonderful standard overhead items like insurance, business licenses, and taxes. Looking at a breakeven cost for a small firm (around $50 an hour) and your 400-hour software costs $20,000 just to keep the lights on.

Anyone who has operated a successful business will tell you that you can’t just charge enough to break even. You’ll never survive.

People drastically underestimate the expertise needed to build custom software. Developing good software takes an insane amount of effort, and most people involved (even if you’re using foreign labor or cheaper labor) are in high demand. Imagine if you needed to hire 8 lawyers for a year to develop your software product? Would you expect that product to be inexpensive?

Finally, I think a lot of people just think that software development is simply “writing code.” Software development is about utilizing code and resources to build the best tools to fit a need. I’d say that a successful software is 20% about the code, and 80% about how the project was planned, managed, executed, and maintained.

Code always works great on a developer’s machine. However, software needs to be able to run in an environment. It needs to work where the users expect it to work (on their computer, browser, and/or phone). This required extensive testing and repairing when bringing the software into different environments.

Scope Creep/There isn’t a Plan for the Software

This is one of the largest killers I see in the product/software itself, especially with startups and new ideas.

The best part about building software or an app is the fact that you literally have a blank canvas. Modern coding and technology gives us so many tools, we can build some incredible features.

The worst part about building software or an app is that you literally have a blank canvas.

You get part of the way through a project, and think of some awesome feature that will “revolutionize it.” Then, are disenchanted when you find out it’ll delay the project by three months and cost an extra $30,000.

A lot of people confuse building software with the metaphor of constructing a building. It’s easy to relate to, and even we use it to give examples as to why some things take longer. The largest difference is, we can reasonably estimate how long it will take to build a building after we get the exact blueprint for it. Not to mention we’ve had thousands of years to perfect building processes and architecture.

With software, the “exact” blueprint almost never happens. While a lot of companies like J9i are going towards getting these “blueprints” in order, it’s still hard to visualize. Just recently we had a software project that started with almost a perfect blueprint. It was signed off by all the stakeholders, and the production went smooth. Then, while testing the final product, one of the key stakeholders realized they didn’t give us any information about a specific template of reporting they used.

This would be the same as if they had shown up to inspect a custom home, only to realize they didn’t make plans to add in a living room. While hindsight makes it obvious, in wasn’t caught during the planning stages.

This occurs much less frequently than actual scope creep. This is (using the building metaphor) the equivalent of being shown the home for the first time and suddenly having the idea to move the living from the left side of the house to the center of the house. The problem is, a non-developer can see the software and go “oh it would be awesome if we could add in the ability for this to automate reporting” without realizing it’s the same thing as asking to move the living room from the left-hand side to the center of the house.

These projects are also some of the most malleable projects you’ll embark on as a business. Software is highly malleable by nature, and the complexity and scope can grow MUCH faster than any other engineering discipline.