The development of bespoke mobile applications for businesses is currently experiencing a similar explosion in growth to that previously witnessed in e-commerce websites during the dotcom boom. The barriers to entry are also dropping as more freelance developers spring up offering packaged development services.

For most businesses, commissioning a mobile application will be their first experience of software development. Managing a specialist process of this nature can be challenging, particularly where there is a lack of in-house technical expertise and perhaps also experience of managing IT contracts.  Putting in place an appropriate development contract is an important step in managing the development process and ensuring you get what you are paying for.  But first, here’s some thoughts on what you should try and resolve with the developer before you even reach the point of negotiating the detail of the development contract:

  • First and foremost, a strong concept for your app and of what it is for.
  • A detailed written specification of what it will do. Of course a good developer may do a considerable amount of preparatory work with you to develop your thinking and produce that specification and may expect payment for that process, but you would be advised not to commit to a full development process until the specification has been agreed. 
  • A timetable for the development process.
  • A payment structure (preferably a staged one which incentivises performance).

That said, here are some key issues particular to software development (ignoring generic issues such as limitation of liability, although these are also key) which should be considered at the stage of contract negotiation:

Ownership of intellectual property in the developed software

By default ownership of IP will stay with the developer and the extent of the customer’s rights will be determined by the scope of the licence granted by the development agreement.

When software has been written from scratch at the customer’s expense, the customer may understandably take the view that they should own it.  However, in practice developers will rarely have written software entirely from scratch without reusing existing generic code.   As the price will invariably reflect this fact and the developer will require to reuse this code in other projects, insisting on full ownership may not be a realistic or necessary stance.

It should not however be assumed that the licence offered by a developer will be appropriate for the business’s intended use of the software.  You should consider for example whether the licence permits your business to have the software maintained and developed by third parties; or restricts the ability of the developer to sell the same software to competitors of the customer.  

Acceptance testing

Agreeing the process by which you are to test the application conforms to the specification is important, as once the application has been accepted this will often trigger the developer’s right to the main staged payment due on project completion and curtail any right to reject the software, leaving only the possibility of a claim for damages.  Equally, from the developer’s perspective it is important that acceptance testing cannot be unduly delayed as a means of delaying the supplier’s payment.  An acceptance testing procedure should also set out what the developer will be required to do to fix non conforming elements of the software.

There are also some issues specific to mobile development which should be borne in mind in relation to acceptance testing.  Approval from Apple is required for iPhone and iPad (iOS) apps to get them into the App Store.  The approval process involves basic reliability testing and other analysis.  Certain apps have been rejected in the past on the basis of objectionable content, in particular where they contain adult content. It is therefore important that acceptance of an iOS application encompasses its approval by Apple. In the case of Android applications, the wide range of devices supported by the platform with varying hardware and OS versions, mean that it is likely to only be possible to test and support a subset of devices.  It is therefore important to be clear on which devices/OS versions are to be supported.

Liability for infringement of third party intellectual property

The customer should seek contractual protection, in the form of an indemnity, against the risk that the developer does not own all necessary intellectual property rights in the developed software to grant the licence provided to the customer under the agreement.  This protects it against such scenarios as plagiarism of code by one of developer’s employees, or situations where the developer has already granted conflicted rights to a third party (such as an exclusive licence).

The developer may also seek a counter indemnity in respect of claims relating to infringement resulting from materials/data supplied by the customer or for software patent infringement relating to functionality implemented at the request of the customer.

The risk of software patent infringement claims for mobile developers has been highlighted recently following Lodsys’s patent infringement claims against a number of small app developers http://www.bbc.co.uk/news/technology-14682700/.

Another area that both developer and customer should be aware of in this regard is the reuse of third party data in apps.  While many well known websites provide mechanisms for third party to access to their data, this will usually be subject to a data license which will set out the conditions on which it can be reused.  Often this will restrict or prohibit the commercial sale of apps utilising this data.

Support and maintenance

The extent of the developer’s obligations after the programme has been accepted should be clearly mapped out.  At a minimum, most customers would expect any faults identified within a reasonable period of time of acceptance to be corrected.  However, in most cases necessary maintenance will involve making enhancements suggested by customers and supporting new versions of mobile operating systems as well as bug fixing.  Is the developer willing to support the application in this wider sense and if so, at what cost?  Consideration should also be given to the possibility of putting in place a source code escrow arrangement to ensure that if the developer ceases trading or goes into insolvency, the client will have the source code and necessary rights to allow a third party to continue maintaining the programme.

Conclusion

We hope that this article will be useful to businesses who are considering dipping their toe into the world of app development for the first time.