As a general rule of thumb people instinctively like an app contract that favours themselves and puts all of the risk onto the other party. Who wouldn’t want that, as it’s good business, right?
Wrong, wrong, wrong.
As we’ve pointed out before, your relationship with your app developer or development team must be one of absolute balance.
Anything less than equalibrium in the relationship means that there will have to be a loser and a winner. If this is your first mobile app project and you are engaging a developer with say 20 apps in their repertoire, who do you think will be more experienced in getting favourable terms for themselves. Clue, it’s not you.
App development contract are notoriously difficult to get right. When We Are Apps was developing apps for our clients we made sure we invested, at no little cost to ourselves, in a seriously good contract that protected our business but also was as fair as possible to the client.
Yet we still had occasion to seek protection from the odd bad client. Thankfully our contracts we’re up to the job, although we still managed to get ripped off by one client. That story will be for another day.
Get the project set up right, first
You can of course mitigate against a good relationship turning sour by making sure, from day one, that both parties are really clear on the project requirements. The best way to do that is with your App Project Briefing document.
But even if you have used our template to produce a really great brief that has attracted bids from really great developers, there is still the hurdle of making sure you don’t sign a one-sided app development contract.
Here are the tips to help you avoid signing a bad one.
Poor payment terms
A developer will try and get as much payment upfront before they have done any work. The reason is explained here.
Don’t sign a contract with an initial payment (deposit) of more than 50%. There’s no need, as the developer usual has their biggest costs, their staff, at around 40-45%
Try and aim for somewhere between 25-40% deposit. That way the developer knows they aren’t totally sunk if you go under but you also know they won’t sit on their hands, because you have left them with a small amount of risk.
The balance of payment should be on the basis of milestones reached or Agile sprints completed. Sometimes you can put time based payment plans in place for longer projects.
Also, make sure that its clear that any pricing either includes or excludes and relevant purchase or sales tax. You don’t want a nasty shock finding out the project is going to be 20% more than you had budgeted for.
There’s way more advice on payment terms here [LINK]. : How to get the best app development payment terms.
Pricing not clear – hidden costs
Elsewhere we have discussed the evil that is ‘under pricing’, something to be avoided at all costs.
Once again, a thorough App Project Briefing will help you avoid this, but some developers may still be determined to recover an aggressive quote by building in hidden costs elsewhere in the app project.
One thing to be particularly wary of is the development rates that would be applicable to work that is not covered by the contract.
You should aim for the same rate that has been applied to the contract.
It is fair enough if the developer has applied a discounted hourly or daily rate to the main contract, on the basis of a bulk number of hours etc. They will have a ‘standard developer rate’ for all other work, but see if you can strike a balance, perhaps negotiating a sliding scale where the hourly rate reduces as the number of hours charged for rises.
IP not transferred
Many investors insist that Intellectual Property Rights (IP, for short), is always transferred from the developer to the client.
In the days before frameworks and open source code this was entirely possible.
But do not let a developer tell you that they cannot transfer ANY code because third parties hold a claim over it.
Your contract/agreement should state that any unique code the developer has written on your behalf should be transferred.
If they are using any code that they have either used before or want to retain to use with other clients, common in app development, make sure you are given a licence to use that code, in this version of the app and subsequent version, in perpetuity.
You also need to make sure that the IP in any design, UI and branding work done by the developer is wholly transferred to you.
No sign of indemnities
I’m sure there are better descriptions but in our eyes, indemnities are there to protect the each party from any wrong doing by the other.
So you indemnify the developer against asking them to do something illegal, for example. And they indemnify you from the risk that they might have infringed someone else’s copyright by ‘borrowing’ an image or icon in the final design execution.
Little or no warranty
Mobile app development is slightly easier for a developer to provide a warranty for than other software because, once the app package is uploaded to a store for distribution, nothing much can happen to it.
As long as the app has been tested thoroughly, on the devices that have been defined in the contract, there should be little need to fall back on the warranty once it has been released.
Most developers offer between 30 and 90 days warranty, and 30 is perfectly fine, as long as that warranty period only starts AFTER the app has been published and found its way into user’s devices.
Key personnel not named
One of the biggest bugbears of clients is if the person or team they have established a relationship with suddenly dissappears from the project.
Of course, sometimes a developer cannot help a staff member leaving. Normally there will have been transitional period where their replacement will start working alongside the departing project manager or UI designer, to ensure consistency.
Make sure the key personnel are named and that the contract has defined terms for alternative staff. You don’t want the developer switching out a key staffer from your team to work on another project, if you can help it.
Lawyers like to justify their fees by using polymorphemic words that nobody understands (see what we did there). That way you have to go back to them at $200 per hour to get them to explain what they mean.
They can’t help themselves, but just because a contract uses complex and heterogeneous terms (now were just playing with ya), this doesn’t mean the contract is bad. Just difficult to understand.
Don’t let anything go. If you don’t understand something, ask the developer to make it clearer. In effect, their email response will also add to the contract terms, so if possible, ask them to substitute their terminology for the confusing stuff in the contract.
Do not be afraid to do this. The developer will be quite used to it. Our CEO spent many, many evenings responding to client clarifications over contract meanings.
BETA release testing not clearly defined
As well as your App Project Briefing no other process has as much impact on the success of your project as the testing phases.
When the developer has ‘finished’ developing the app they will release a BETA version of the app, ready to be tested.
You need to see the details on the exact processes and methods the developer will use, what they will test, the operating systems they will be testing on as well as the devices they will be using.
User acceptance not clearly defined
Once the developer has done their own testing (much of which will be done in sprint phases, but they also need to make sure the app is tested as a whole working unit), they will release the app to you for your own testing.
We seriously advise that you use a third party at this stage, but if you do need to save budget you can do it yourself.
Make sure, however, that the terms under which you are expected to ‘Accept’ the app are made clear and that you are comfortable with them.
No dispute resolution defined
No client or developer wants to walk into a contract knowing they are going to fall out at some point. But disputes do happen and the point of contracts is that both parties know exactly what should happen throughout the course of the relationship, especially if things go wrong.
There should be a clear dispute resolution process based around escalation, with the emphasis placed on the project teams sorting things out in a structured manner before throwing the issue at senior managers.
Ultimately, there should be clause that ensures, if the client and development can’t agree on a solution, there should be an external dispute process through a neutral party with the terms of who contributes to their fees clearly defined.
Avoid the chances of your project developing problems by completing an App Project Briefing and using it to attract top quality development teams.