During the journey of finding a company to build your mobile app, you've likely talked to several developers. The conversation of cost has undoubtedly come up, and likely has multiple times. While it can be a difficult conversation, it is beneficial for both you and the developer to understand why fixed prices and software development are much like oil and water. In exploring the pitfalls, you'll better understand why the successful and experienced developers have moved to time and materials billing, or an even more simple structure such as per person, per week billing.
Software is not like other industries.
This is where most people get tripped up. You likely have preconceived notions of what building software should look like. You might even say things like "If I spend enough time planning, I can come up with perfect and precise blueprints for my app. The development team I choose should be able to understand them, follow them exactly, and give me a hard number on cost." This is where it all goes downhill. Suspend your disbelief as I explain why.
Well understood and disciplined industries can safely apply the measure twice, cut once philosophy. These industries such as manufacturing and construction have been around for a very long time, and are well understood. On the contrary, software has only been around for a fraction of that time and is still a rapidly evolving industry. It is our natural tendency as humans to relate building software to building a house or manufacturing a car. For example:
- In construction or manufacturing, blueprints are well understood and are not likely to change. This is because these industries are tried and true.
- In software, blueprints are rarely well understood. This is because we don't know what we don't know until we know it, and we often don't know what we want until we see something in action. For example, the User Sign In feature of your app may have originally been with just a username and password, but after testing the app, you and your testers decide that it really needs to support logging in with Facebook. This is an example of what we call an "unknown unknown" in software. Developers can make suggestions and explain best practices to you, but neither you or your developer can predict the future and know what will need to change. This caveat most often falls on the developer to eat the cost, but it makes the relationship unbalanced and unfair.
Simply put, neither you or the developer you hire knows how your features will need to change or evolve until they are tested by you and your users.
So, I can't just change features within the fixed price?
If you were having a house built, and halfway through you realized you were going to need another bathroom, would you expect that bathroom to be free? I'm willing to bet you wouldn't. If you did, the contractor would likely cancel the project as it would become cost prohibitive and promote an unreasonable relationship expectation.
Now, parallel this with software. If you were building a social networking app, and halfway through you decided that users needed to be able to upload videos instead of only photos, would you expect the developer to do it for free, even though the original agreement was just for photo uploading? I doubt it.
If there is a relationship precedent that software developers will build new features within a fixed price, the quality of your product is going to plummet. Your developer will quickly lose interest in the project and eventually either fire you or go out of business because they're not making any money.
But what if my features don't change? Can I have a fixed price then?
No. I mean, you may be able to convince an inexperienced developer to give you a fixed price, but your product is going to suffer and the developer is going to learn a very valuable lesson. It is almost impossible for a developer to predict complexities that they may run into. For example, when the developer is planning out how to set up your database for a social networking app, they may have a great schema all mapped and diagrammed out. Suddenly, halfway through building, they realize that they need to reimagine the schematic because it is not as performant as they hoped it would be in your particular application. Your application will have very specific needs.
This is not the case only with junior developers, but even with the most senior developers. Software development is a very unpredictable and fluid process. It is important for you as a client to respect and appreciate that, giving your developer the freedom necessary to do good work for you.
Good developers will build software in two week chunks called Sprints. Sprints are part of the Agile Methodology and allow you to see what works and what doesn't work in smaller, non cost prohibitive phases. Rather than going through a formal change order process every time you meet complexities or need changes, having a time and materials approach gives you the freedom to address these things in real time without slowing down your project.
It all comes down to trust.
Fixed prices do one thing: they mitigate financial risk for you, the client. The problem is, all of the financial risk ends up with the developer. This sort of relationship is bad to get into for both parties. You should not impose unrealistic financial constraints on your developer, and your developer should do their very best to deliver high quality software quickly, efficiently, and cost effectively. If you're not working together, you're working against each other. Do you really want to be working against your developer from day one?
Counterintuitively, the illusion of a fixed price will come back to bite you later on down the line. When developers aren't given the freedom to build high quality software, you end up with a low quality piece of software that needs constant bug fixes and attention long into the future. In short, if you don't want to pay for quality up front, you'll pay twice as much later on to maintain a poorly made product.
Most developers work well on a basis of mutual trust. If you don't trust your developer, don't work with them. If you want to know if you should trust them, look at their portfolio and speak with their previous and existing clients. Find reviews for their work. An honest developer will keep you in the loop with how much each change will impact your timeline and budget in real time.
If you'd like to build something great with us over at Teeps, fill out our Contact form. We would love to chat.