So you have found a development firm you want to work with to build your product. Hopefully, you took the advice outlined in Part 1 of the series to vet candidates and obtain the right firm for your project. So now it is time to code, right? Wrong! 

Remember, the whole purpose of vetting candidates is to figure out who is the right developer to enter a business relationship with. The last place an entrepreneur wants to be is where disputes occur around who is doing what, who owns what, who is responsible for what, and how do conflicts get managed and addressed. After vetting candidates and deciding whom you should work with, your next step is to get a contract with the development firm. 

Written contracts define and outline the complete mutual understanding of the relationship and scope of work between you and the development firm. Contracts limit the claims anyone can make around misunderstandings as the relationship progress. A well-written contract specifies: 

• What rights are purchased;  

• What rights are being retained by whom;  

• How parties are to work together; and  

• Who is responsible for certain development risks.  

Beyond contracting, Part 3 of this series will dive into project management best practices. 

From a contract and work execution perspective, you are the project manager. The developer is providing you with subject matter expertise to help bring your product to life. Ultimately, you are responsible for managing the project budget, timeline, risk, and final product approval. A good contract should also lay out the framework for execution. With this framework in mind, a contract should include the following:

 

A clear definition of your app concept and what it is for 

Every contract you enter into should always start with defining the why behind the agreement. This critical statement provides context that will guide contract interpretation in the event of a dispute.  

 

Detailed written specifications of what that app will do 

Ultimately, you are contracting with this developer to build an app that will do a specific set of things, i.e., the functionality. The contract should provide a clear definition of what this functionality is.  

 

A timetable for the development process and acceptance 

The proposal you obtained from the developer should lay out a time frame for what is developed and when. You and the developer need to outline this in the written agreement.  

Additionally, as part of this agreement, you should include project reviews. Reviews will enable you to check in, review demos to see the progress to date, and catch issues in the development and manage them quickly. Ideally, it would be best if you were doing this on a weekly/biweekly basis. 

 

Project Budget and Payment Structure 

The contract should define the budget for the project. The budget should include all development costs and any post-development add-ins around app maintenance and support. 

Additionally, the contract should lay out when payments for services rendered are due. My advice is that you tie payments to project development milestones outlined in the timetable. This way, you align payments with work performed and satisfactorily completed. Payments structures should be part of the negotiation process outlined in Part 1 of the series.  

 

Clarity on Who Owns the Intellectual Property of the Developed Software 

By default, Intellectual Property belongs to the party who created it, not the party which commissioned it. However, ownership is transferrable by contact. Ideally, a developer should transfer any and all intellectual property rights of the created app over to you. A contract can create this obligation. 

 

Additional Intellectual Property Matters 

Many developers often utilize open-source software or other created software materials to build a product for a client. This practice leads to two concerns. First, does the developer have permission to utilize said materials for your project? Second, do those materials have limitations on use that would impair your ability to commercialize the finished product? What you want to do in your contract is have the developer responsible for any liability you face due to these issues, i.e., indemnify you. 

Additionally, the best IP defense for early-stage start-ups is leveraging trade secret protections.  A trade secret is the right to protect against the disclosure of information about your business. One protection you can put in place is a non-disclosure clause as part of this agreement. This clause creates a duty for your developer not to disclose information about the engagement and its work product. Another protection is to place a 3 to 5-year non-compete clause, limiting your developer’s ability to use the information learned from working with you to assist a competitor.  

 

Decision Making, Dispute Management and Resolution 

Often in the development process, decisions impacting timelines, functionality, and budgets have to be made. You and the development team should review these types of decisions. However, the final decisions regarding these topics should come from you. Make sure the contract specifies this process. 

Additionally, there is always the inherent risk that there will be issues with the developer. Following the steps outlined in Part 1 of this series should help limit these issues. However, suppose you still find that delays are occurring and services are not delivered as promised. In that case, the ability to terminate the contract quickly to cut your losses and move on is paramount. Even better is to attach clauses that require any additional incurred development cost under these circumstances beyond what was budgeted for in the contract becomes the developer’s responsibility. 

Finally, what law governs this agreement? This choice of law question becomes a significant issue, especially with working with overseas developers without a local contact. Take the time to work with legal counsel to sort this out before signing the contract. You also want to consider if you want to use mediation or arbitration as a more cost-effective method of resolving contractual disputes than going to court. 

 

Warranties, Support and Maintenance 

Your contract should specify what type of ongoing support, if any, the developer is to provide. The contract should also be clear on what type of maintenance support, if any, is provided post-development. 

More importantly, one should have a warranty on software performance. If everything works out well, your app should work the way the contract says it would, and the developer warrants when they complete the project. You may find post-development glitches with the app. Ideally, you have a warranty in place that would allow issues with the app to be fixed free of charge to you. Even better is to include product testing as part of the development timeline. 

 

As a final note, when working on these types of agreements, please consult an attorney to ensure your interest is protected. Doing so is vital because issues with app agreements can impact future investors, future business partners, and future business growth.

---