How To Get The Most Out of Fixed-Price Development Contracts
Fixed price contracts is one of those “clients are from mars, developers are from venus” topics.
Clients are almost always looking for a fixed price project because that’s how they think they can protect themselves from getting screwed. The idea of a fixed price is super appealing in theory: you have a budget, you get developers to throw bids at your feet, you pick the cheapest one thinking you can fall back on the dispute police at Upwork if it doesn’t get done.
This poses big problem for our entire industry. Fixed price projects that are motivated by pricing wars between developers almost always spell disaster. This occurs in many forms: budget overruns, delays, developers taking shortcuts to deliver something on time with poor code. All of this leads to clients soured by outsourcing, ballooning costs over time to fix poor code, and fewer opportunities for good developers. Both sides lose.
But since fixed price projects aren’t going away anytime soon, we really have to work on improving their outcomes. My advice to clients is to request a fixed price bid with a slightly different motivation than getting the best price: getting the most accurate estimates.
Here are my solutions to the 4 most common problems preventing you from getting accurate fixed-price estimates:
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 come up with, time which 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.
