A Buyer’s Primer to Software Development Contracts: What to Look For and Why

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.

The Intent of a Good Software Development Contract

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:

1. The contract is about fairness and risk-sharing for both sides. There is no place in a good business relationship for lopsidedness – one party shouldn’t be looking to gain any sort of unfair advantage over the other.
2. The contract, in the view of a business relationship, should be designed to be written, signed, and stored. Any disagreements should be talked out and solved without pulling out the contract.

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.

Critical Pieces to Understand in a Software Contract

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.

Time or Deliverables?

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.

• Time & Materials: You’re buying a block of time (1000 hours) of a skilled team, in order for them to deliver a (usually less defined) software product. This puts a bit more risk on the buyer, as the feature set isn’t super dialed in, but allows for flexibility and change (a good thing with the right software firm). It requires more trust and agility between you and your firm, and because you’re taking on a bit more risk, it usually comes at a slightly lower price point than a Fixed Deliverables contract (or should, anyway).
• Fixed Deliverables: You’re buying a precise set of deliverables for a fixed cost. The amount of time that goes into it, from the agency side, doesn’t factor into the contract (although, it likely factors into the agency’s side in terms of delivering, but that’s mostly their problem – not yours). This puts more risk on the agency, and thus the cost can be higher than a Time & Materials contract (via contingencies and things of that nature, to control for the inevitable unknown). You get a “guarantee” of what you’re going to get, and pay a bit more for that peace of mind, and in turn you usually give up some flexibility (e.g. you can’t just add on more features, or necessarily swap features).

A few more notes on Fixed Deliverables contracts:

1. Expect a lot of detail in the requirements list. The term we use at Paper Leaf for this is acceptance criteria. Think – how will you know that this feature is done or acceptable?
2. If you don’t have that detail yet, it should be uncovered in a Discovery Phase, or you should perhaps sign on to a Time & Materials contract.
3. Excluded work – what isn’t included in the project – is sometimes as important as included work (i.e. requirements lists and user stories).

Intellectual Property

There are three big questions around intellectual property that you’ll want to make sure are clearly answered in your software development contract:

1. Who owns the IP?
2. How and when does it get assigned?
3. Is any IP not included?

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:

1. Internal tools: Often, software development firms like us will have a variety of internal tools and scripts we use (for example, to migrate or parse content, or to run automated tests, or a huge variety of other background items to expedite the development process). Usually, you’ll see a clause that excludes these tools from the IP ownership clause – if we had to hand over IP of these tools every time we finished a project, we’d have to bill you to reinvent the wheel over and over and over (and your project fees would go through the roof). If you insist on owning IP for these items (which no one ever has in my experience), you’d likely have to pay tens or hundreds of thousands of additional dollars. Not worth it.
2. Open-source: Our projects often run on open-source software (React Native for mobile apps; ReactJS for front-end; Laravel for back-end and web apps; sometimes jQuery and the like). The nature of open-source licenses is such that neither party can “own” the source code, by definition. It doesn’t pose any risk, financially or otherwise, to you – but it can be a confusing point for clients.

Project Schedule

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:

• Look for multiple, recurring review periods (progress review meetings, retrospectives, and the like). You should be reviewing the in-progress build every two weeks or so to ensure everything is transparent and on track.
• Milestones and limits on revisions may seem ideal but can be frustrating later.
• Issues arise when you try to put waterfall-specific language (milestones, “final” deliverables, etc) on an agile process or shop, and vice-versa.

Turnaround Times

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?

Pause Clauses

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.

Termination

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.

Payment

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.

• Milestone-based works with waterfall or “wagile” projects – it doesn’t work so great with agile projects, as agile projects do not have set milestones.
• The software firm will push for milestone-based payments to be based on delivery, not acceptance, or at least a combination of both. Sometimes buyers want to insist on acceptance to remove all risk – which, in turn, puts all the risk back on the software development firm. Insisting on acceptance of a deliverable means acceptance has to be clearly defined by all parties, which is a lot of work and sometimes unknowable at the outset of a software project – especially an agile one. Generally, this is avoided.

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.

• Time-based can come with big variance month-to-month, so if cashflow is a challenge for you as the buyer, be aware of that – and perhaps request equal payments or something more predictable so you can plan ahead.

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.

Warranties, Support, and Guarantees

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.

How Long Should My Software Guarantee Be?

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.

Support & Service Level Agreements

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!

Moving Ahead and Signing Your New Software Contract

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.