photo by Alejandro Escamilla
When outsourcing a digital project such as a website or mobile app, it is vital that the developer and client are on the same page in terms of expectations and requirements for the project. These details are normally outlined within a development agreement that is agreed upon by both parties. This agreement acts as a roadmap for whom is responsible for what and when.
You have probably heard the old saying, “get it in writing.” That’s exactly what the agreement is intended to do. It is used to cover the expectations of both the developer and the client. If there is ever a disagreement on a particular issue, the agreement can be used to help resolve the situation.
Agreements can come in all shapes and sizes from a quick one pager to the book sized tome with lots of legalize. However it is structured, here are the major areas that I feel should be covered.
Project Scope
This is basically the “what” of the agreement. It will list out all the features of the project. This can be listed out in a feature list with items like “App will display users current location on home screen” or use a story based approach such as “As a user, I want to be able to view current location from home screen.”
The scope needs to be detailed enough to cover all functionality without getting stuck in deep technical detail. Unless there is a very valid reason, the scope should instruct the developer “what” to do and not “how” to do it.
High-level sitemaps or screen flows are helpful to include in the scope. Words are nice, but sometimes it’s easier to convey meanings through diagrams and drawings.
If the project is required to depend on any third-party libraries or services, be sure they are listed. Let’s say the project uses Company X’s API to pull in data. The agreement should cover items like, is the developer or client responsible for initiating contact with Company X? If Company X charges a fee for the API, is that fee paid for by the client or included in the cost of the project? Does the project require a specific version of Company X’s API?
The scope should list what platforms or software the project will support. For mobile apps, this may be something like Android 4.0 or above, for web projects it may be something like IE 10 or above. This is a key phrase to include because it will affect how the developer approaches the actual programming.
Deliverables
Deliverables is just a fancy way of saying “I’m going to send you this.” The agreement should include a section for client deliverables (items the client sends to the developer) and developer deliverables (items the developer sends to the client).
Client deliverables should include all items the developer will need to proceed with the project. This could include previously created wire-frames and mock-ups, graphic design files, company logos, and user accounts to access company servers.
The obvious deliverable for the developer is the completed project. But developer deliverables can also include test builds and project source code.
Schedule/Costs/Billing
Schedule, costs and billing can be included as one section or broken down into separate sections. The agreement should clearly state the total cost of the project and how long it will take for completion.
If a relative date is used for completion, like 30 days, be sure the start date is also included. Is that 30 days from when the agreement is signed? 30 days from when the client delivers all required deliverables? 30 days from when the developer starts programming? The idea is to just be clear so both parties have the same expectations.
Some projects can easily be broken down into phases or milestones. Milestones can then include their own scheduling and billing. An example would be Milestone 1 takes 15 days and costs $1,000. Milestone 2 takes 30 days and cost $1,500.
Talking money always makes people nervous, so be sure the terms of payment are clear. When invoices will be sent to the client should be stated in the agreement. Some developers send invoices based on milestone completion within the project, some require an upfront payment, some take the payment at the end, and others do a combination of these. The agreement should also include how long the client has to pay the invoice and what happens if the payment is late.
A few things to keep in mind when stating the billing: taxes and external costs. Some projects may require payment of government taxes. The agreement should specify which party will be responsible for taxes and if it they are included in the existing billing prices. Besides the costs of paying the developer, there may be charges associated with external tools or companies (such as paying for Company X’s API in our example above). These costs should be clearly stated and noted which party will pay them.
Website Hosting and Mobile App Store Submissions
When projects are complete, websites will normally be published live to a production web server and mobile apps will be submitted to the appropriate app stores.
For web projects, the agreement should state where the web site will live. Is it on the developer’s server or the client’s server or somebody else’s server? Who is in charge of maintaining those servers and who pays for those servers?
For mobile apps, be sure the agreement states if the app will be uploaded using the client’s or the developer’s app store account. Will the developer upload the app to the app store or will the client handle the app store submission process? Who is responsible for uploading app descriptions, logos, and screenshots?
Maintenance
Unfortunately, no developer is perfect and most projects have a few bugs, even after being publically released. Make sure the agreement states when a project is considered “final.” That could be when the project is delivered to the client or when the project is published to a web server/app store. The maintenance section of the agreement should address changes made to the project after the project has become final. These bug fixes can be handled through a pre-determined maintenance fee, through hourly work by the developer, or the client may handle all future updates themselves.
Disclaimer
Developer agreements essentially act as the contract between the client and the developer. Signing any type of contract often makes people pause and really study what they are signing. To prevent an extended delay, developers often include a clause in the agreement that says the agreement is valid until a specific date, after which it can be altered. This is just so a client doesn’t sit on an agreement for months at a time, during which the developer may have to update pricing or scheduling for whatever reason.
Termination
Be prepared for the situation where the project never makes it completion. The termination section may include the details of how and when either party can terminate the project. If the project is terminated, who pays whom? Who gets the work that has been completed so far?
Ownership
Who owns the source code for projects is something to really pay attention to. For most work for hire work, the client will own all rights to the source code, but be sure you have that in writing. Some projects the client may be paying for a license to use the code, but not actual ownership of the code. In this scenario, the developer may include an option for the client to buy ownership of the code for a separate fee.
Legal Mumbo Jumbo
With the disclaimer that I am not a lawyer, there are a few legal specific sections that are normally included in the agreement. I’ll try to explain a few of them in normal human terms.
Confidentiality Agreement says that neither party will share information about the agreement or either party’s confidential company information with other people.
Complete Agreement says that once signed, the terms of the agreement cannot be changed unless both parties agree to make the changes.
Indemnity clauses are somewhat like a warranty and who is responsible to pay for lawsuits. An example is if the client is sued by a third-party for copyright violations stemming from code the developer put in the project. The indemnity clause could say that the developer would have to cover the costs of the lawsuit. Again, I am not a lawyer, so please consult other resources on the full aspects of indemnity.
Force Majeure is the “act of God” clause. If something completely unexpected and out of the developers control occurs (like a war or hurricane), any disruption of the project from that event cannot be held against the developer.
The key take away for both developers and clients is clarity. The agreement should be easy to read and understand. Like any contract, a developer agreement can often go through many revisions before being signed off. That’s a good thing. It shows that both parties want the agreement to accurately reflect their expectation for the project. And a project where the client and developer see eye-to-eye has a much higher chance of success.
If you are looking for help with a digital project, check out our company Cullaboration Media. We also help mobile apps with user engagement and feedback through our User Hook service.