How Cost of Development Changes over Time

Almost everyone knows the saying time is money, but what does that mean for development? Before we dive in to today’s article, let’s take a look at two paths you can take when it comes to time vs cost in development:

Person A wants to get something to market as soon as possible, so they skip research, design, and user testing. They quickly were able to develop and release their app, but the users almost immediately rejected it. To make the app a success, Person A had to make sweeping changes, causing the cost of the app to double. They had to go back to the board for a significant amount of money to fix the product. Without good feedback on the current version, the board was hesitant, causing the product to die all together.

Person B wanted to take the time to do research, design, and user testing. They talked to customers first, looked at potential competitors, and then quickly spun up a potential design. They then iterated through easy to change designs with people who would be the real users of their product and made changes based on feedback. While it took an extra month or so to get to market, the app saw immediate adoption from users. Person B was able to raise more money from the board to keep the momentum going.

We all want to be like Person B, right? An app can’t be a success without positive feedback. So what exactly is time’s effect on the cost and success of an app? We’re glad you asked.

As we’ve already said, time is money. What this usually leads people to do is build a product as quickly as possible. What you should think instead is that by spending time up front, you’ll be saving money in the long run. 

Another saying that makes this more clear is “earlier is easier:” the earlier you decide to make a change, the cheaper and easier you can get it done. If you wait until you’re deep into building the product, that same change will be significantly more expensive and take much longer to implement.

While projects have a goal of being completed as soon as possible, there are reasons you should take the time to make changes sooner rather than later. Let’s look at each stage of a project and see how simple (or not simple) it is to make a change.

During design, there is no code. This means that making a change takes little time and doesn’t cost much. Usually, designs can even start on paper, allowing them to iterate dozens of times. Don’t like the design? Throw it away and make another. Even when you get into designing the screens in a program like Sketch or Figma, it’s still easy to change the flow of the product or how a feature works. 

While slightly more difficult, the same goes for prototypes. Creating a prototype and testing with users does take time, but will save you in the long run. For example, let’s say it takes a week to convert your designs into a clickable prototype and to test it with 5 or so users. During those tests, you quickly learn you were way off. The cost of making a change now is miniscule (maybe a few days to another week). If you made that same change after development was underway, it could easily take up to 10 times longer to implement, and be that much more costly.

When you start writing code for your product, making a change suddenly becomes more complex. Now, any updates can potentially require both a change to the design and to the existing code. Additionally, you’ll have to re-test changes with users all over again. You may even break other parts of the application.

All of this adds up; making a change during development is significantly more expensive then when in design. The further along in development you make changes, the costlier it gets. This is because there is more code that potentially has to change and more testing that has to take place to make sure everything still works.

Your product is now in the hands of all your users. You’ve completed months of hard work and spent tens of thousands (possible even hundreds of thousands) of dollars on the effort. You should be kickin’ back and enjoying your new software. However, if this is the first time users are seeing the product, then chances are there will be several changes required. 

These changes are especially challenging because not only do you have to change the design, but also spend time updating the code and re-testing. You may also have to change how data is structured, requiring writing scripts to change data around in your live environment. 

Another costly side effect is that you may have to re-train and re-educate users on how the product works.  Depending on the severity of the change, the cost and time to implement could be almost twenty times more than if you had made these changes at the beginning of the project. 

We mentioned user feedback earlier in the article, but why is early feedback so important to the overall cost of a product? By talking to users early and often, as well as showing users your product in prototype form, you can find out what changes are needed. You can make those changes very early on in the process.  

This also means that when you launch, it’s not the first time your users will see the product. Chances are now much greater you’ll see significantly higher adoption and fewer changes will be needed. You can then leverage that momentum to raise more money from your organization and continue the effort. You’ll also have significantly more credibility when you launch other products.

Earlier truly is easier: the earlier you make changes to your product, the quicker and cheaper you can get them done. Changes made late in the game just cost you money.  By spending more time up front, you’ll be saving money (and time down the road).  

Looking back to Person A and Person B, we hope that you take the message of earlier is easier, and follow in the footsteps of our latter friend.

Why not to build custom software