I will be presenting on mobile app development at the Practising Law Institute (PLI) Technotainment Conference on October 5, 2013. This is part 4 of my outline on the topic.
a. Detailed Specifications
i. Mobile Platform Decisions. The publisher needs to decide whether to build for different platforms simultaneously or sequentially.
ii. Social Integration. Think ahead what types of social network integration will be used. Options include logins, social sharing and use of social graph.
iii. Hosting & Live Operations.
- Service Level Agreement (“SLA”). If the app will have elements hosted online, will the publisher host them or the have the developer handle them? If the developer is responsible, there needs to be an SLA with penalties for downtime.
- Operations Services. Will the app be static or consistently developed?
iv. Analytics. Publisher should look at free analytics providers, but these don’t receive customer support and may include developer’s analytics as part of larger “industry-wide” studies for re-sale. Publisher may be better paying for higher service levels that keep analytics private.
v. Ad Server Integration. If the app will contain advertising, publisher should think about ad placement ahead of time and the types of ads that will be served (banner, video) and whether publisher will sell ads directly or want to use an ad network.
b. Intellectual Property (“IP”) Rights and Restrictions
i. Works Made For Hire. Publisher should ensure that developer’s deliverables are owned by publisher, while publisher may want to retain certain rights. It is important to lay these out specifically in the development agreement. Most deliverables should be covered with “work made for hire” language.
ii. Developer Code. The developer often brings its own pre-existing code libraries. These code libraries may also be developer further as part of the engagement. It is important to list these in detail and determine publisher’s rights in deliverables that use these code libraries. Publisher should have the right to use and modify the developer code as part of the app.
iii. Developer Third Party Materials. The developer may use third-party tools, software or code in the deliverables. It is important to ensure that it is properly licensed and any restrictions or obligations for the publisher are included in the development agreement.
iv. Publisher Licensed Third Party Materials. The publisher may also be providing third party materials and services, such as analytics packages, hosting and other tools that publisher uses generally.
v. Open Source Software. If developer is including any open source software in the app, it needs to be called out in the development agreement, together with any obligations imposed on the publisher.
i. Specific Deliverable Phases. The development agreement should break down the app deliverable into as many milestones as possible. The use of several deliverable milestones to trigger payments protects the publisher by ensuring that payments aren’t made if things deliverables are not acceptable.
- Design Document. The deliverables often include a design or development document, specifying the features and functionality of the app.
- First Playable Build. This is usually a demo version of the app (not necessarily including implementation of graphics, content, sound and text) that is playable outside of the development environment to show proof of concept. The First Playable Build does not need to be free of bugs and may not include all planned features or functionality.
- Alpha Build. This is usually a preliminary version of the app (including partial implementation of graphics, content, sound and text) with functionality sufficiently complete and usable to enable the publisher to test and evaluate the App for distribution on the applicable platform. The Alpha Build does not need to be free of bugs and may not include all planned features or functionality.
- Beta Build. This is usually a working version of the app (including full implementation of all graphics, content, sound and text) that will enable the publisher to test and evaluate the app for operation on the applicable platform. The Beta Build should be reasonably free of bugs and include all analytics, planned features and functionality.
- Gold Master Build. This is usually a working version of the app for the applicable platform, meeting all of the specifications in the development agreement. The Gold Master Build should be free of bugs, include all analytics, planned features and functionality and comply with the rules for distribution on the applicable platform.
ii. Format. The developer should provide the publisher with all code, including source code, build scripts, configuration files.Documentation. It is important that the code delivered by the developer to the publisher contains programming notes, so that it would be understandable to another professional developer.
- App Code and Server Side Code. There may be different elements of the code base. Many apps rely on interplay between the code that runs the actual app and code that runs on a web server to support certain online elements of the app.
- Android / iOS specifics. Android and iOS both contain specific file formats for their apps. It is important that the developer provide the publisher with both the final builds and the underlying files necessary to modify and re-create the builds.
d. Liability and Risk Allocation
i. Warranty Period. The development agreement should include a warranty period that allows the publisher to discover defects after the app is accepted and have them corrected at no cost. It should include a deficiency resolution and correction process that breaks down various levels of errors and the appropriate time to fix them.
ii. Representations and Warranties. The development agreement should contain representations and warranties from each of the developer and the publisher specifying that each party has all necessary rights for the materials it is providing and those materials don’t violate the rights of third parties.
iii. Indemnification. The development agreement should contain indemnification provisions for breach. The most important area to cover is violation of third party intellectual property rights.
iv. Replacement by Developer. If any of the deliverables violate the intellectual property rights of any third party, the developer should have the option to procure a license for publisher to continue using the deliverables, or replace or modify the deliverables so that they become non-infringing. This should be at the developer’s expense.