Fixed Bids – Bad News for Developers and Their Clients

setting fixed bids is outdated

Software development is always evolving, and fixed bids don’t fit in an evolving industry. Here’s why employing fixed bid contracts is detrimental to software development. 


Fixed bids – offering an estimated price for a project before work is completed – were once the industry norm in the software development industry.

But personally I think fixed bids are risky and outdated.

 

It isn’t always easy to set a specific price. Unexpected problems can crop up, and sometimes things just take longer than expected.

Nowadays, more developers base costs on the number of hours spent on the project instead of setting a price in stone. This is known as pricing on “time and materials.”

While many clients still believe that a fixed bid will move the risk of unexpected costs to the developer, they don’t realize that this payment structure is often bad for them as well.

In my ten years as a software developer, I have come across many clients that have insisted I set the price before the project begins. However, experience shows me that this normally leaves at least one party unhappy.  

What clients don’t realize is that often a good developer is on their side, and should plan a project based on a realistic timeline.

But with fixed bid projects, there is more chance that a developer will be tempted to cut corners to meet deadlines, which can lead to poorly completed work, which doesn’t meet the real needs of the end user.

It is also extremely difficult to make an accurate estimate which does not leave one party at a disadvantage.

Fixed bid contracts nearly always go over budget.

Developers who take fixed bid projects will come across difficulties and rush through them. Why would they want to spent extra time when they know they’re not going to be compensated for extra work? This leads to a shoddy end-project which in turn, disappoints the client.

 

You Lose Key And Peele GIF - Find & Share on GIPHY

 

Software development is extremely complex.

Unexpected things crop up: bugs, upgrades to framework (which lead to function changes), or an API call not working as expected. These can all lead to things taking a lot longer than expected, and hard-working developers begin to think that they’ve been given an unfair deal with a fixed bid.

In the worst cases, I have known developers to end up handing over an unfinished product. That’s a loss for everyone.

And the client is also going to lose out in terms of flexibility if they enter into a fixed bid contract. What if they want to suddenly change the requirements of the project? If they suddenly want to add a new feature at the last minute? Or a certain feature in the contract is complicating things and needs to be removed?

There is a lot more wiggle room and flexibility when a time and materials payment plan has been agreed from the outset (instead of a fixed bid).

 

Ultimately, clients will get a better deal if they do the research and pick a good software company. Review previous projects, speak to previous customers and you’re more likely to find a good match, instead of a bunch of cowboys. As the saying goes “You get what you pay for.”

Companies that realize that a per hour contract – which allows greater flexibility and ultimately a more impressive product – will be more successful in the long run.

 

agile-product-development

 

Many of us have been burned by setting fixed bid contracts for development work. Tell us your story or, if you support fixed bids, tell us why!

 

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz