BiteSite was founded in the summer in 2012 and we’ve worked with a ton of clients on a lot of projects. With that comes a good amount of experience that has given us some confidence in saying what works for us and what doesn’t.
One thing in particular that we’ve experimented with in several different ways is the way we structure our contracts and after years of developing software, we’ve come to the conclusion that we don’t believe in fixed term contracts when it comes to software development.
What do we consider ‘fixed term’?
Alright, before we get started in explaining why we don’t believe in fixed term contracts, it’s probably a good idea to get on the same page as to what is a fixed term contract and what isn’t.
While there may be many different interpretations out there, for our purposes and for the purposes of this article, we consider a fixed term contract any contract that states something along the lines of:
You will get this output for this amount of money
Now, obviously contracts are not usually written this way, but they can be boiled down to something similar. What’s more common is something like this:
You will get Feature A, Feature B, Feature C, Feature D for $10,000.00
That is probably looking more like contracts that people are used to dealing with. Now obviously, contracts are usually more fleshed out than that, but the more detailed it gets, the more “fixed” we’re talking about, and as you’ll see, the more “fixed” a contract is the worse it is.
Now, there is a small but very important change we can make to these types of contracts that we are very much in favour of. This small change removes this “fixed” aspect of it. What’s the change? Simply removing either side of the equation:
You will get unknown for $10,000.00
You will get Feature A, Feature B, Feature C for an unknown amount
In either of these cases, while you are fixing either the deliverables or the budget, you are NOT fixing both. When we talk about ‘fixed term’ contracts, we are talking about situations that fix both. If you allow either to be flexible, the contract does not fall into the ‘fixed term’ category.
Types of projects
BiteSite has an interesting history in that it didn’t used to be strictly a Custom Software development company. In the past, we focused on corporate video and before that we offered graphic design and photography services. As such, we want to be very clear about our philosophy around ‘fixed term’ contracts.
When we say we don’t believe in fixed term contracts, we are strictly talking about Custom Software projects.
While our philosophy might extend to other types of projects, we have a lot of concrete reasons and evidence around Custom Software projects and thus this article deals specifically with Custom Software projects.
Developing good software
Our belief around ‘fixed term’ contracts and why we avoid them really stems from our belief in how good software is developed - or rather what we believe is the best process to develop good software. We by no means invented any of these concepts but rather followed in the footsteps of great minds.
At BiteSite, we develop software following many Agile methodologies and principles. We use a process we’ve called Scrum Express (a slightly modified version of classic Scrum) and in our many years of experience, we find following these principles works really well.
Without going too deep into these principles, one of the biggest philosophies is continually integrating feedback into your development cycle. Whatever form the feedback takes, testimonials, usage statistics, data models - it’s important to take it in and incorporate it into your product on a continuous basis.
These principles are based on the notion that no one can really predict what users will do or how they will behave, and it’s important to put out software, observe, and iterate.
We’ve seen time and time again that these principles truly work in the real world. We’ll spend a little bit of effort developing a small feature that we’re excited about and find out very quickly that no one wanted to use it. So we stop developing it. On the other hand, we’ll add a small feature that we thought was a small fix and people loved it so we poured more resources into it.
It’s all well and good to read about these principles, but we (and I’m sure so many others) have seen it in action and it’s very powerful.
So how do you plan your software product?
With this in mind, it may seem impossible to have a long term plan for a software product while maintaining effective development practices and in a way - it is.
If you subscribe to the philosophy described above, you should embrace the fact that you just don’t know what the future will bring.
Don’t get me wrong, it’s good to have a plan, and it’s good to have vision, and rough idea of where you’re going, but at the same time, you have to get used to the idea that within weeks if not days, your plan could completely change - that’s what agility is all about - the ability to change.
Processes and concepts like Scrum, Continuous Integration, MVP and more all account for this and give you powerful tools to take in feedback and remain agile.
If you think you can sit in a room full of researchers, designers, engineers and plan exactly how your software will work months from now without ever putting it in the users’ hands - then you’re adopting a waterfall approach - an approach that in our opinion is less effective.
It’s a pretty logical conclusion
If you believe in these agile philosophies as much as we do, then it’s a very logical conclusion as to why fixed term contracts are bad for software development.
Fixed term contracts lay out specifics about how a piece of software will look, behave, be architected, and more - all before some serious thought, but more importantly, all before it’s put into users’ hands.
If the contracts don’t leave room for flexibility or for the potential for the plan to be completely altered, then you could be developing software in a very ineffective way and basing your decisions on what’s written on a piece of paper rather than what your users are telling you.
By leaving your contracts open ended, you allow for the agile principles to shine through.
Is that it?
Following Agile development principles is definitely the main driving factor in our belief to avoid fixed term contracts, but we’ve also seen other benefits arise from it.
When you tell a developer to “Develop Feature A for $200.00”, they will constantly be racing against the clock. They’ll constantly be thinking of ways to shave off hours, and get the minimum amount done without taking some care. Not to mention, they’ll throw out any creative ideas, or spur of the moment inspiration to make things better. The distraction of needing to finish it in the exact time or amount or less leads to uninspired output.
Further to that, if the engineers, developers, or designers have any moral conscience, they’ll probably try to minimize the amount the customer spends. That’s great, but it can also stifle good conversations and discussions that can lead to great output.
When we moved to non-fixed term contracts, we felt we concentrated less on time, and more on just developing great software.
Can’t the contractors just buffer in the expense?
Whenever we’re faced with a client who just can’t do an open ended contract, we do what we believe most companies do - buffer the cost. So even if we think it’ll take 50 hours to produce, we’ll budget in 150 hours to cover these unforeseen costs.
While this can work, there are two reasons I’m not a fan of this approach. One, I think it’s an artificial and inaccurate way to account for the cost of what’s being done. It’s almost like saying “We can’t predict what’s going to happen, so we’re just going to charge you a bunch more money.” Secondly, if it really takes 50 hours, I never liked the idea of a company paying us more than what it took. If it took us less time, the client should pay us less.
Fixed budget is not fixed term
One thing I want to stress is a point I brought up when defining ‘fixed term’. If you remove either side of the equation, it removes the ‘fixed’ aspect of it.
So while we don’t believe in fixed term contracts, we are very much a fan of fixed budget contracts.
A fixed term contract may look like this:
We’ll develop Feature A, Feature B, Feature C for $10,000.00.
A fixed budget contract sounds more like this:
We’ll aim for Feature A, Feature B, and Feature C, however things could change and we may develop other features, but let’s keep our spending to only $10,000.00 maximum.
We find customers who are not comfortable with open ended contracts are at least more comfortable with fixed budget contracts.
This all sounds well and good, but I have to remind myself that I am writing from the perspective of the Custom Software service provider - not the client. I have to remind myself that it can be really scary to sign an open-ended contract with a provider. Sure I trust myself and my team, but how can I expect you, the client to, if you’ve never dealt with us or worked with us before.
The open-ended contracts we talk about are based big time on a trusting relationship between the vendor and the client.
So how do you establish this trust?
At BiteSite, we usually recommend starting with a small fixed budget contract - not fixed term - fixed budget. In fact, we’ve taken on starter contracts as small as $500.00 to start just to see how we work together.
I’ve never been a fan of companies who say, “We won’t talk to anybody who has a budget of less than $5000.00”. We’ll go as small as you’re comfortable with. Granted, we may not get much done for $100.00 or so, but if that’s what you want to spend, you’ll get to know us and then you’ll know whether or not to trust us with more.
Going through a pilot project of sorts is a great way to establish trust and if things go well, you can continue with that trusting relationship.
So how do we structure our contracts at BiteSite?
So with all that said, how do we structure our contracts at BiteSite? Well, it’s actually quite simple. If you strip away all the fine print, the only thing we really have in our contract is our hourly rates - no feature set, no deadlines - just our rate.
Once the contract is in place, the rest is discussed outside the contract. You only want to spend $1000.00 a month? No problem, we’ll keep track of that and not go over that. You want to try to get these 5 features in by March? No problem, we’ll aim to do that. Again - there is a trust factor, but this works really well for us.
If things go south, we find these contracts work really well too. Don’t like how we’re getting along or unhappy with the progress? Simply as us to stop, and we’ll stop.
One thing I should note, occasionally our contracts will include some extra details about feature sets that were discussed. However, these details in the contract are always stated as “rough plans” or “estimates” and emphasize that we are not bound to these plans.
Value based vs time based
Some of you out there reading this might be frustrated in our use of Time-based billing vs Value-based billing. Value based billing is definitely a philosophy with its merits, but frankly, I don’t know enough about it.
What I do know is it cost X dollars per hour per employee to run my company at a comfortable pace. That’s something concrete I can gravitate towards and something that’s easy for me to plan for. As such, for the time being I decide to use time-based billing.
It can be tough
It can be tough to sell the idea of open-ended contracts, but we find that once we explain our reasons, most clients get on board and it leads to a great working relationship.
I’m not saying that these types of contracts are for everybody, and I know there are definitely organizations that are bound by their contract processes that they have no other choice but to use fixed term contracts.
That being said, the more open ended contracts we put out there, the more evidence we get that it’s the right way to go. We hope that more and more organizations embrace this idea as we believe it lines up perfectly with how good software should be developed.
I want to give a special shoutout to ThoughtBot. ThoughtBot is a company that we look up to and admire greatly. ThoughtBot’s open source playbook was the first place I read about this idea and seeing them write about it publicly gave us the confidence to advocate for it in our daily work.
(photo by Cytonn Photography from Pexels)