What you need to know about fixed price app development
Fixed price contracts are one of those, “Clients are from mars, developers are from Venus” topics.
In my experience, most clients are advertising on a fixed-price basis. That’s how they think they can protect themselves from getting screwed. And while the idea of a fixed price is super appealing in theory–you have a budget, you get developers to throw bids at your feet, and you pick the cheapest one thinking you can fall back on the dispute police at Upwork if it doesn’t get done–the trend poses a big problem for those who design and develop mobile applications for the healthcare industry.
More often than not, fixed price projects that are more concerned with budget than investment result in pricing wars between developers. This occurs in many forms: budget overruns, delays, developers taking shortcuts to deliver something on time with poor code, and almost always spells disaster. Clients get sourced by outsourcing, and by ballooning costs to fix poor code. Both sides lose.
Still, fixed price projects aren’t going away anytime soon. And if app developers are going to have any chance at improving their outcomes, I have a word of advice:
The secret to getting the most out of your fixed-price development contract is to build the most accurate estimates.
How do we do that? By identifying the most critical barriers to fair fixed-price settlements, and offering up industry-wise solutions for those looking to hire Topflight Apps.
Top Four Fixed-Price Barriers
1. Problem: Clients often request bids with very few details about the project (out of fear that their ideas will be stolen), forcing developers to come up with estimates based on vague 3-line descriptions.
Solution: Get comfortable talking about your idea. You should either provide detailed specs and UI mockups yourself or pay for a separate discovery scope for a developer or analyst to come up with them. Accurate development estimates require both.
2. Problem: Accurate estimates are possible, but require time to develop–time that developers don’t get compensated for. Thus, a developer isn’t incentivized to spend it.
Solution: Incentivize them! Understand that good estimates can take several days! Reward the developers that take the time to do this. Wait at least a week after posting a job before you consider hiring anyone. If a developer presents a reasonable estimate and then meets it, you should hold on for dear life.
3. Problem: Even though most clients will agree it’s common sense to freeze the scope of work in a fixed price project, even the best clients are prone to change requests. It’s simply human nature to not know exactly what you want until you see a part of it built. The gateway request may be something as simple as spending another 4 hours to convert a text field into a dropdown. Before you know it, there are a dozen change requests.
Solution: Be willing to agree to “no change requests” or “change requests must be handled with a separate hourly contract,” and seriously honor this.
4. Problem: Design is impossibly hard to estimate. Unlike with code (“does it do the thing?”), every client has different tastes for design. It usually takes several rounds of feedback and changes to come up with the final version.
Solution: Don’t expect a fixed price project for design to produce a result to your satisfaction. Be willing to accept a solid middle ground like a fixed price for an initial design concept plus a certain number of design revisions, while understanding that good design will always be an iterative process.