I think we can all agree that contracts – the writing, reviewing, and negotiation – are everyone’s favourite parts of any project. The legalese, the pages of obtuse language… good times for all.
All jokes aside, the contract process – while sometimes tedious – is critical to understand and get right if you’re looking at hiring for custom software development. Be it for a web app, a mobile app, a combination, or the infrastructure around it all, good software work can be valuable and isn’t cheap – so both parties need to be protected. And when it comes to software development, there are some contractual and project specifics you’ll need to look for and understand.
Before we dive into more precise areas, it’s important that both parties are approaching the contract in good faith. That means a couple things:
If the opposite of the above is happening, a discussion needs to be had so those items can be respectfully resolved. If they can’t be, then those perspectives will likely hang over the relationship to poor effect.
When it comes to the nuts and bolts of contract content, there is a litany of variables. While I’m not a lawyer (yes, that’s my disclaimer), I have written, customized, negotiated and signed off on hundreds and hundreds of these types of contracts – and these are the items that jump out to me as top-priority for prospective buyers like you to understand.
The first big thing to understand, and make sure is represented accurately in the contract, is this: are you buying time, or deliverables? It might seem obvious, but it’s actually fairly common for a client to think they’re buying one thing (a fixed deliverable with a defined set of requirements, e.g. a web app with X,Y,Z features), and the software developer to think they’re selling another (1000 hours to deliver a web app).
Neither Time nor Deliverables contracts are inherently better or worse for either party. They are just different, and thus come with different risks and expectations.
A few more notes on Fixed Deliverables contracts:
There are three big questions around intellectual property that you’ll want to make sure are clearly answered in your software development contract:
Nothing is a given here, but more often than not IP gets transferred or assigned to the buyer at some point. However, as the ol’ saying goes, everything is negotiable.
Our contracts stipulate that IP is assigned to the buyer when invoices have been paid. It’s pretty straightforward and fair to both parties. However, some contracts stipulate that IP stays with the developer and the buyer (you) gets a lifelong, non-restrictive, royalty-free, worldwide license to use it.
That means you can use it forever, but you don’t own the IP. Generally speaking, IP has value. So, it can become a negotiating point. If you don’t care about the IP, you can ask for the above licensing agreement in exchange for a lower price, since the IP stays with the development firm. If you do care about the IP, you might have to pay more depending on where the pricing and IP discussions started.
Further, not everything can or should get treated with a blanket IP ownership statement. There are two common points here:
The next area of focus is on the project schedule. As a buyer, you’re going to want to know when you can expect what, in terms of your software product. The details of that schedule are dependent on the type of approach the software firm takes in development.
For example, a waterfall shop who works in sequential fashion may have a project schedule with specific deliverables and specific times. An agile shop or a time & materials contract will likely not assign hard deadlines to specific deliverables, as this method of working allows for continual iteration on deliverables (so it’s hard to pin a date on when the “final” version of, say, UI design will be done).
A few notes:
Part of a project schedule is not only what the software firm is accountable for, but also what the buyer is accountable for. With that in mind, what are the turnaround times for you?
It won’t be a long-winded paragraph in the contract, but it’s important to clearly identify the turnaround times expected from the buyer’s side in the contract. That is, how long do you have to give approvals or feedback? Often, these take the shape of either a five or ten business day timeline.
There is a relationship to timeline and development methodology here as well. If you need more than five or ten days, that’s fine – but expect the project schedule to lengthen, perhaps considerably. And if you’re working with a full-on, high-velocity agile shop under agile contractual conditions, you can expect turnaround times as short as a day, or weekend.
Make sure you understand and are being true to your context as well. You might be confident in the velocity of your decision-making – but do you truly have decision-making power? Do you have a slower-moving C-suite who needs to give approval at a certain point, or points? Do you have a board that needs to give the OK? What about managers who care about a sliver of the overall application functionality?
With the above subject of turnaround times in mind, look for and consider is if there is a Pause Clause (h/t Bureau of Digital). There are countless shops, including yours truly, who have been burned by projects that were delayed for months and months (aka “Disappearing Client Syndrome”).
When a software firm suffers from DCS, it leaves us with high-salaried staff sitting around, resourced for a project they can’t work on – and an operations team frantically trying to fill their time with other, billable work. When shops have been burnt by a lengthy delay or two, you can expect to see a variant of a pause clause – that is, a clause that stipulates what happens if you, the client, goes dark for a clearly defined period of time. Often, it gives the shop the right to totally reschedule your project (meaning, potentially book it months out, if they’re busy). It can sometimes also come along with additional fees to cover the assumed billable time lost to the client’s disappearance.
The large majority of project contracts never need to be terminated. But, sometimes they do – for reasons both poor and reasonable – so it’s critical to understand your project’s termination clause.
A termination clause can take a variety of shapes, but usually has two levers – the amount of notice that needs to be given, and any fees associated with terminating the contract. Ours, for example, is a 15-day notice and a “kill fee” amounting to 25% of the remaining contract value. You’ll likely come across variants here: 15 days, 0%; 30 days, 10%; and so on.
What works for you depends on the other variables in the contract, but terms like these are pretty standard issue. You can also expect common additional terms including stipulations around what needs to happen to confidential information and the like.
Nothing needs to be nefarious or scary here. As much as it’s good to understand what entering the relationship looks like, it’s equally appropriate to understand what exiting the relationship looks like.
When you distill service contracts down to their simplest form, they’re comprised of two things: what is being bought, and how it is being paid for. So, let’s talk payment.
As you’re probably starting to see, there’s a theme here. How payment terms roll out are highly variable, and dependent on how the software shop operates. Below are a few you’ll run into.
Milestone-based. When the shop delivers an item by a date, you pay part of the fee. For example, on kickoff, you pay 20%; on wireframe delivery, you pay 20%; and so forth.
Time-based. At the end of a specified time period (2 weeks, the month, etc.) the firm tallies up the billable time spent and sends you an invoice.
Equal payments. The total fee is divided across the expected timeline, into equal payments. This is what we do for the majority of our projects – for example, a $100,000 project expected to take five months equals one $20,000 invoice per month for five months.
Lastly, let’s talk about warranties and support. These items are related, and should be clearly understood as they can put undue risk on either party if they’re not.
Warranties (or guarantees) will be found in some, but not all, software contracts. Basically, if they’re in the contract, it’ll mean that the firm providing the software guarantees its functionality for a period of time. Commonly, that is 30 days post-launch. I’ve seen everywhere from 15 to 90 days, and once had a client ask for 6 months (!).
The idea here is that there is a period of time where the shop will fix any discovered bugs for free. After 30 days though – especially for web apps and other similarly less-controlled environments – it becomes difficult to differentiate between what was an existing bug and what is a new bug based on all the moving parts that change hyper-fast in tech: hardware, browsers, core platform updates (e.g. Laravel, React), packages installed into those core platforms, APIs, operating systems, and so on and so on.
If you’re wondering why software isn’t guaranteed past 30 days or so, that’s why – it’s not uncommon to have upwards of a dozen variables change in a 2 week period. That equals thousands of combinations of potential conflicts right there.
If, for whatever reason, you need to negotiate a longer guarantee period, that’s fine – just understand that your costs will go up as a result. That’s because of the general rule that if you want to take risk off your plate, which is what an extended guarantee does, you have to pay for it.
Lastly, make sure not to conflate support with warranties or guarantees. The guarantee period dictates the terms of fixes within a defined period of time, but should not be misconstrued as a support agreement. A support agreement, or Service Level Agreement, is a separate contract written up for the post-launch period, and dictates in detail the specific expectations around support for your new software. That’s outside of the scope of this post – but we have a post on SLAs coming soon!
Now that you understand some of the critical pieces of software contracts as outlined above, you’re in a good spot. Bookmark this post and reference it, and download the cheatsheet above, for the next time you’ve moved into contract negotiations with your software development firm of choice.
Go into those negotiations knowing that a good business relationship, and a good contract, is predicated on the ideas of fairness and risk-sharing for both sides. Get that contract in place, sign it, and then focus on building the best software you can.