Once you have made your choice of supplier, in most cases you should make sure you have a clear agreement in place between you. This does not have to be a weighty legal document, but it should set out the expectations and responsibilities on both sides.
In many cases the supplier will provide this for you. If this is the case, just make sure you read it through in detail and know where responsibility for different parts of the project will lie (and don’t be afraid to have them amend it if there are any grey areas).
If you are paying a supplier through Elance or Guru they also have a number of measures in place to protect both sides (another benefit of using these websites).
For a starting point for putting together an agreement, take a look at the Supplier Agreement Template* in the Resources section of this guide or download the original file from the Members Area (under Resources) of app-outsourcing-guide.com
(*Please note that this template is purely for your guidance and does not constitute legal or financial advice.You should always make your own enquiries before signing any agreement.)
What is being produced
You needn’t necessarily re-produce the whole spec but it should be clear what is being produced, including a brief list of all major pieces of technical functionality and sections.
Responsibility
You should breakdown exactly what the agency is responsible for delivering and what is required on your side. Bullet points will do. This might look like:
Supplier’s Role
Responsibilities to include:
- Functionality scoping and wireframe for client sign-off;
- Production of app to match wireframe including integration of XML feeds;
- Final bug testing of the app;
- Submission of the app to Apple via iTunes Connect by ‘x’ date;
- Ongoing support and maintenance.
Client’s Role
Responsibilities will include:
- Delivery of all icons and images for app by ‘x’ date;
- Delivery of working XML feeds by ‘x’ date;
- To manage the relationship with the sponsor of the app.You can tailor it to your requirements and, as you can see, it needn’t be complex.
Timeline
As well as defining who is responsible for each aspect of the project you may also want to attach timelines to different parts, particularly the date that the app will be 100% complete, tested and ready for Apple submission.
In a large project with many dependencies (eg. feeds coming from your own in-house developers; logos or other materials coming from suppliers) which may have a knock-on effect on other areas of the project, it is particularly important to get all of these dates agreed up front.
If the supplier is guaranteeing an overall finish date or certain number of working days before it gets submitted to Apple and there are some dependencies on your side then they might want an agreement here too.
For example if you are building a ‘hybrid’ app, your developers might be required to finish work on the feeds that will send content to the app by a certain date. This then gives a guarantee to the developer on their side that can pick up the work and integrate it with the app knowing that it is complete and they are not going to find any bugs.
You should also be clear about what happens to the cost of the project if things over-run. Will you pay more? If the fault is at the supplier’s end will you still pay the same price even though they are working extra days?
Payment schedule and terms
If it is your first time working with a supplier then I’d suggest only making the payment at the end of the project or, in the case of a larger project, structuring payments as installments. If the payment is being split you might to identify two or three key milestones in the project to trigger these.
You should also be clear what the payment terms are from the supplier (30 days after they invoice you? 60 days after they invoice you?) as well as how they expected to be paid.
App Store submission, testing and (dis)approval
No-one likes to think of something going wrong but it might pay to be clear on one point. Who bears the cost of ‘fixing’ the app if it is rejected by Apple? You might like to break this down because – as we’ve seen – there are several reasons that an app might be rejected.
If it’s because of a bug, then whose ultimate responsibility was it to do the final testing on the app? Yours or theirs? Either way it is likely the developer will have to do some extra work unless, perhaps, the issue is something that was produced by work on your side (such as content feeds pushing content from your website to the app). The following should be made clear now:
- Whose final responsibility is it to test the app?
- Will there be an extra charge from the developer to correct any bugs?
- Does the developer guarantee to fix any bugs as a priority (before moving on to whatever other projects they may have had lined up) – where do you sit in their priority list?
- If your launch date was critical and and you are to set it to miss it because of this – should you be compensated in some way (for example, a reduced final payment to the developer or doing the next app update for free)?
If it’s because of the content or concept of the app then – unless you have a very understanding supplier – almost certainly the cost for change the app to meet Apple’s approval will almost certainly fall on your side (assuming you wish to continue).
If you want the developer to manage the whole process of submission on your behalf, you should make this clear now as well (though I’ve not known a developer have any problem or want to charge extra for doing so).
Parting ways
Thinking about a future parting of the ways is not think negatively it’s just that in an extremely fast-changing industry no-one knows exactly what will happen in the future. You might want to bring development in-house one day or you might find a provider more suited to your needs to develop the app further down the line. You should also be clear about who owns the code and if you transfer away from them what happens, so you should also get the following worked out up-front:
- Who owns the code?
- Who owns the designs?
- What if I want to transfer to another provider / take it over in-house?
- What about transferring the hosting?
Who owns the actual code of the app after it is finished? Is it you or or them? (This may also relate to designs, logos and any other elements they create for you). You should in most instances own the code (unless it’s some kind of partnership or franchise arrangement where’s that part of the deal). Who knows, one day, someone might want to buy the app (which includes it’s actual code) from you or they might want to licence part of the code. Also, if you’re producing this for your employer then the app will be an asset for the company like any other, so you should clear this up.
If the supplier has any issues with this, explain to them that if all goes well (as you expect) then you will be keen on working with them in future and hope to develop a long-term relationship with them. It will be much easier for you to stay with them because they worked on the existing code but in such a fast-moving industry (and with no-one being able to exactly predict the future) you need to keep your options open.
If you’re managing the production of the app for your employer you can just explain that it is company policy to get this agreed up front and you are unable to enter any agreements without this being clear. If the supplier is having any serious issues with this, then maybe think twice about using them altogether unless you consider their request reasonable in the circumstances.
If everything is agreed, it’s time to move onto the Project.
