One of the most common questions I get from software consultants is whether or not to accept fixed bid contracts.  In this post, I’m hoping to shed some light on fixed bid vs. time and materials contracts and help you make the best decision for the project at hand.

Let’s start with some definitions to help you better understand what I am talking about.

A fixed bid contract is a contract where the developer and the client agree on a price and/or timeline up front for a particular contract.  If additional time is needed, there must be some sort of change order issued to and signed by the client.

A Time and Materials contract is a contract where the developer and the client agree on an hourly rate for the development of a project.  While there should be some initial estimates up front, the developer is not locked into a certain number of total hours/dollars.  If more time is needed than stated in the original estimate, the developer has the freedom to continue as the client’s budget (and patience) permits.

Below, I’ll compare and contrast the pros and cons of both fixed bid and time and materials contracts.  Note, this is just from my experience and your experience might vary.  In fact, if it does, I’d love to hear about it in the comments.

Fixed Bid: Pros

1. You can potentially make a lot more money.
   If you are a good estimator (or a bad one and the client accepts an overbid), then this is your chance to get paid whatever you want to get paid per hour.  If you bid 100 hours and get it done in 50, you have essentially doubled your rate.
2. *It’s easier to manage the pipeline.
   *Generally, when you do a fixed bid contract (again assuming you are decent at estimations), fixing a contract allows you to plan out more contracts ahead of time.  Typically the fixed cost comes with a (roughly) fixed timeline.  This allows you to project future availability for yourself to work on other projects.
3. *You know what you are building up front.
   *If you have done your due diligence (gathering requirements, specking things out, etc…) there should be no surprises.  Everything is already laid out for you and if the client wants to change anything, it will require a change order.
4. *You are selling value instead of time.
   *This is actually a hot topic lately.  Many will argue never to sell by the hour as so much more goes into your rate than just time (your knowlege, history, expertise, etc…) The client wants to pay your for a solution to their problem and that’s infinitely much more valueable than your time.
5. *It’s sometimes easier to land contracts.
   *Some clients have a very specific budget.  If you can provide a solution to them inside of their budget, then the contract is yours every time.

Fixed Bid: Cons

1. You can potentially lose a lot more money.
   There is a joke that goes something like this: There are only 2 hard problems in software development, knowing when to expire a cache and accurately estimating working.  Generally, the overzealous developer will error on the side of too few hours in order to ‘land the contract’ or ‘please the client’.  This usually results in the developer bidding 50 hours and realistically working the 100.
2. Feature Creep.
   Clients WILL feature creep.  Feel free to tweet that or write it on your forehead.  It’s just a fact of life.  You, being the super nice developer that you are, will want to please the client and will say something like “it’s outside of scope, but I’ll make an exception”.  Before you know it, the app has pivoted and you are building things WAY outside the scope of the initial contract.
3. Can I…? NO! Well, what about…? NO! Just This… NO, NO, NO!
   With a fixed bid contract, if you are an experienced developer, you will ALWAYS be telling the client NO.  If you are wondering why, see #2.  While feature creep creates a tension, so does not allowing the client to change course, if needed.
4. *It’s sometimes harder to land contracts
   *If I take a fixed bid contract, I generally error on the side of overbidding.  This allows padding for things like QA, small changes, App Store submission, etc.  Given the high bid, your client might baulk at the contract and attempt to outsource to India himself, where he will eventually spend double.

Time And Materials: Pros

1. *Your work is always compensated
   *Given that you are getting paid per hour, you can always count on a steady stream of revenue coming in.  This is very comforting to developers since you know you will always get paid the rate you want for the work you do.
2. *Landing contracts can be easier
   *Clients don’t always know what they want up front and the idea of not committing to a certain dollar amount is sometimes comforting. It also gives them MUCH MORE freedom to make changes and pivot down the road.
3. *It gives clients the freedom to prioritize features
   *This is one of the biggest selling points that clients appreciate when I sell a time and materials contract.  Given that my team follows a version of the agile development methodology, clients love that they have some insight as to how much each feature roughly costs.  They can see the estimates and translate that into cost.  If they feel a less important feature is too costly, they can prioritize the backlog to get more (less complex) features for the same price.
4. *Less Risk
   *Since you are only selling the client your time, you don’t necessarily owe them anything except work.  Most of the time, time and materials contracts don’t even have an official scope of work attached.

Time And Materials: Cons

1. *It doesn’t scale
   *You can never make more money than your time will allow. If you charge $100/hour and work 40 hours/week, then you can never make more than $4,000/week unless you work more.
2. *You are a commodity
   *The client doesn’t so much look at you as someone who is providing them a solution as they do a “resource”.  You are perceived as less valuable and therefore could easily be replaced.
3. *More Risk
   *I know this type of contract is listed as less of a risk above, but there is also some riskiness to it.  If you get in the weeds on a task or start introducing too many bugs, the client might feel that you are misleading them or incapable of performing and you risk getting released from the project.

Takeaways

While I have only scratched the surface in comparing these two types of contracts, I hope you have a better understanding about which route to pursue for you.  My advice is to not be too rigid stating “I’m only going to use contract type X forever” because each contract situation may vary.  Use your best judgement and make the decision that is best suited for each individual project and client.  At some point in the future, I will post a few tips for making this decision based on some factors, but that is for a later date.

Until then, happy consulting!

P.S. Make sure to sign up for the newsletter below to be notified about awesome posts like this in the future!