-
Software Consultant Contracts: Fixed Bid VS Time And Materials
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
- 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
- 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
- *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
- *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!
-
What I Learned In My First Year Of iOS Consulting
Wow, I can’t believe it has already been a full year since I struck it out on my own. Last year, I published a post after my first month on doing contract iOS development. Needless to say, I have grown and learned quite a bit over the past year and I wanted to share some of those experiences.
Income
While I won’t share exact numbers, I left my 6 figure/year job to pursue the indie/consulting life. During the course of the year, I was able to amass 40% more income in 2013 than I had at my previous position.
In addition to that, I had the time to launch a couple iOS applications and thus upping my Apple income by about 20% this year.
Network Network Network
I would say spending time networking and meeting people is just as important as being able to write code if you want to be successful on your own. Through out the year, I dedicated at least five to ten hours a week just meeting with people, talking on the phone, and making new connections.
Often times, I would get contract opportunities that I knew for sure that I wasn’t going to take; either because I didn’t love the project, or (more often than not) because I didn’t have the bandwidth to take them on. However, rather than just writing the client back “I don’t have time“, I would take the call (or meeting in town), make the connection, and even listen to details about the contract.
My wife would tell me to stop wasting my time and that those hours would be better spent on project work that actually made money. However, these contacts are arguably more valuable than the hours “lost”. In many situations, I have reached out to those potential clients weeks or months later once I hired a new developer and was then able signed a contract. If I had declined the meeting to begin with, they probably wouldn’t have been as inclined to work with me so readily.
Subcontractors
Subcontracting has been a mixed bag for me. It seems to be the only (safe-ish) way to expand your business as a consultant, other than hiring full time developers. So, if you want to be able to work less yourself (which is almost never the case) or increase your companies revenue, you need to hire out.
Once I found the right people, subcontracting was a dream. I was able to reach more clients, still deliver the same value in the work, and achieve the client’s goals, all while expanding my business.
The main challenge I have had is deciding whether to hire subcontractors from here in the states or “offshore”. They both have their benefits and complications. Here are some I have found:
Benefits of hiring in the states:
- Communication – Most of the time their timezones are close enough that one of you is not inconvenienced to communicate in real time.
- Trust From Clients – Some clients still have some issues with “offshore”, especially because many of them have tried their hand at the ODesk lottery and have lost. So, saying you have US based team members sometimes makes them more comfortable. It’s unfortunate, but I have seen it to be true in some cases.
- Colleagues – Often times you already know or have worked with these guys since starting with acquaintances/friends is a good place to look for developers.
Complications hiring in the states
- Cost – US devs are expensive. Most of the time they have full time jobs and want to do consulting on the side. So it is important that they get paid more to do contract work than their day job pays.
- Colleagues – This is on the negative list as well because hiring people you know can get weird if things go awry.
**Benefit of Offshore developers **
- Cost – I put this here, however that doesn’t mean I hire “cheap” developers. Honestly, if you are not paying a contractor well, you are either under paying him and should give him a raise OR he shouldn’t be working for you as he’s probably too junior.
- Perspective – I have some incredible developers in other countries that have taught me quite a bit whether it’s about development, process, culture, or even my own code. It’s a great opportunity to learn.
**Problems with Offshore developers **
- Location – Timezone issues can be a problem if you let them. For example, I have a developer who lives in a completely different timezone than my own. However, he does a fantastic job of being available when he is needed. I have had other instances where it was very challenging to reach my developer in an event where I needed information on short notice.
- Vetting Process – Finding developers is a little more tricky. With devs in the states, you can just head to a local meet up or conference, but finding GOOD “offshore” devs is a little trickier. I have lucked out a few times, but for the most part it’s a bit more work. I would suggest spending a little of your own money to adequately search and vet each candidate.
- Language – While doing iOS development, you may need your client and your developer to communicate with one another. That being said, it’s vital to find a developer who you can understand and who can understand you in order to make communication possible.
Hiring An Assistant
Taking a page from Tim Ferris’ 4 Hour Work Week, I decided to hire an assistant. Ferris suggests “virtual”, however, I have hired one locally (she’ll be proofreading this post 😉 ). I think it’s one of the best decisions I have made as a business owner. Here is just a short list of things she handles for me:
- Contracts
- Invoicing
- Payments of contractors
- Research
- Phone calls
- Personal issues (like returns, purchasing equipment, etc.)
Even if she saves me two hours per week, she has paid for herself, and believe me, she saves me much more than that.
Never Decline A Contract
I mentioned this earlier in the post, but I want to reiterate it here. I seldom tell clients “no” and I really feel that it has worked out to my benefit. At the very least, I hear them out and add them as a contact to keep in mind for the future.
What I generally do when I can’t take on a client is I will give them an estimate of when myself or a member of my team will be available. That way, if they are okay with the timeline, I can keep the pipeline open. If not, there is no harm done. Also, if I hire another developer before the time I said I was available, sometimes the client will still have the need and I am able to fill it.
If I absolutely don’t have time or don’t want a particular contract, I will refer the client out to other dev shops. I don’t look at this as competition, but rather opportunity as I would hope they would do the same for me one day. As an added bonus, some of them have a referral fee so you can at least profit from pairing the client up.
Taxes
I have found out that taxes are less fun when you are self-employed than when you are employed by a business. Luckily my wife is MUCH better at money management than I am, so she set up a separate tax account where roughly 40% of our income would go.
One of the other good decisions I made besides hiring an assistant was hiring a CPA. She has saved me countless hours and fees and is worth her weight in gold.
Hire a CPA from day one; you will never regret it.
Family
I know this is a “business” related post, but I have to mention this. Having a wife and kids, I am very much a family man. Working for myself has been such a blessing since I have been able to spend considerably more time with my family than when I was employed by someone else.
For example, if it’s a nice summer day and the family decides to head to the zoo, I can just go without asking a boss for time off or taking PTO. I simply work in the evening or more hours the next day to recoup the time. Personal time management is key to be able to have this kind of freedom.
Summary
Overall, 2013 was an incredible year. While I did make mistakes (a ton), I gained so much knowledge and had a blast doing so. Going solo isn’t for everyone (some days I wonder why everyone** isn’t** doing it, and others I wonder why I am), but it’s been one of the most exciting experiences of my life.
I look forward to what 2014 brings and seeing how I can continue to grow my consultancy.
Happy New Year and Happy Hacking!
subscribe via RSS
