California Mobile App Design Contract Pdf

1. NDA or Non-Disclosure Agreement

They say why bother signing it if you are at the other side of the globe and your developer is a thousand miles away in a different country which has the laws totally different from your domestic ones. Dismiss any doubts! Make your developer sign it even if you understand that a possible breach of this agreement will not have any legal prospects. No matter what, your developer should see that you care about your idea and its confidentiality. Moreover, you never know if you would continue with the contractor you've initially come to. Anyway, at the very first stage there should be a document which would bring discipline. And think twice about your choice if the developer is not willing to sign it.

In respect to an NDA there is no key to all doors, however customizing some template or creating your own, follow some common sense and generally accepted rules:

Make it mutual and not unilateral — one can hardly imagine a situation when only one party will have to disclose the information.
Be careful about a non-compete clause. For example in the US such states as California, Montana, North Dakota, and Oklahoma totally ban non-compete agreements for employees, or prohibit all non-compete agreements except in limited circumstances.
Creating an NDA check your version against standard NDAs to exclude off-market terms and conditions.

Another issue which might be addressed already in an NDA is the use of the project materials or results by the developer. Since most of the developers do not own the final mobile product, they usually want to publish references to the project they work on and some general information in their portfolio. It's up to you to decide whether to assign this right to the contractor or make the information confidential. But in case you don't permit it, there is a chance that the rate or the price may go up.

The basic NDA template you might customize or use as-is — https://www.docracy.com/27/generic-shortform-nda

2. Contractor Agreement

This document is the one which would manage your business relationship with the contractor you decide to go with. There is hardly a one-size-fits-all kind of version as the scope and scale of mobile app development projects might vary, however there are a couple of clauses which you should pay your closer attention to.

a. Scope of work

Take your time to spell all your needs and expectations out to the contractor. Do not accept and do not confine yourself to generalized and vague wordings. Be as specific as possible and require that the scope be well-defined in an Appendix to your agreement. A good development company always knows how it should be and will specify all the details for a client to feel safe: platforms, programming languages, frameworks, solutions, milestones, man-hours, schedule, timeline, software used, guarantees, etc.

Do not forget that mobile app maintenance, update and enhancement services are usually out of the initial scope and are often negotiated to be a part of post-development contracts.

b. Price

Either you are going to work with your contractor on a fixed-price or a time and material basis, this paragraph is closely connected with the scope you jointly define at the start. If the price is fixed, make sure that the agreement with all its appendices clearly state what you will get at the end, when you will get it and how much the whole lot or each piece would cost. Of course, we all try to get the most out of every dollar invested, yet, let's be honest: if you want it fixed and have signed the contract, do not try to change the scope on the go. It won't add either to the project performance or your cooperation with the developer.

Time & Material is a different story. You will pay only for the hours worked to deliver the services you've jointly agreed. What is really great here is that you may introduce reasonable and agreed changes to the scope without affecting much the whole development process. This would be even a greater opportunity if your contractor uses SCRUM methodology and work in short sprints, for example, one-week sprints.

The most frequently asked question here is 'How would I know that they really worked the hours shown as due for payment?' With the long-run partners it would be simple — to keep your business relationship on the level they will hardly deceive. As for the companies you only start working with follow a 'trust but verify principle'. Well-established companies have special time tracking software installed like Time Doctor, for example, which provides for screenshots, web and app usage monitoring. It implies that on your request you can get a report with the actual hours worked and even screenshots to show what the developers assigned for your project were or have been busy with. Make sure that your agreement stipulates that you should have access to such software for the duration of the project to monitor the work done.

3. Intellectual Property Rights

Though usually at the end of a Contractor Agreement, this clause is way too important. A written transfer of ownership for a final product, work results and components is really crucial. To save yourself from unwanted consequences check that the agreement states that " <…> hereby transfers/assigns the rights for <…> to a client". There shouldn't be any promises like "<…> agrees to transfer/assign the rights for <…> to a client" , just clear and water-fast obligations.

Also, make sure that you own the ready-made assets after each major stage. For example, at the end of the design phase one should get the source files, screens designed and the appropriate documents to support the work done. Companies have different approach to final reporting and deliverables, yet take the appropriate precautions to have all the necessary assets at hand. This is not only a matter of ownership, all of them would come in handy in case you decide to go with a different contractor at the coding stage.

Now about the code. In most cases there are three different 'types' of code which might be used in your app: 'custom' code, third-party code, open-source code.

The first one is the code produced and maintained by the developer in the course of building your app. Make sure that the right to owning (not only using) this code is assigned to you right after the work is done and paid. There is also a chance that your developer might want to use some pre-existing code written before without transferring the intellectual property rights. Should this happen, make a reservation that any use of such code should get your written approval.

Using third-party and open-source code saves a lot of time and efforts as these types of code are usually reusable components developed to be either distributed for free or sold by an entity other than the original vendor. At first sight their use seems advantageous, but be aware that there are lots of issues you might probably have to resolve: quality, licensing, security and, of course, other intellectual property attributes. So again make an arrangement that the developer at least confirms the they know of no third-party rights that will be violated through the intended use of these components.

4. Assignment and Subcontracting

In the days of tameless competition and outsourcing one has to keep ears to the street. Some companies and freelancers often embark on all projects possible, even though they understand that they lack the resources to complete them. They just do not want to lose money, so they make a contract and then outsource the job they can not do in-house. So, first of all, decide for yourself if you want to work this way as for you it will mean that some part of the job will be done outside the team you've chosen as a contractor. Could it be done properly and in time? There is nothing impossible in this world, yet more often than not the results are poor. If you want your contractor to do everything in-house and with good quality, make sure that the assignment of rights to third parties and subcontracting are made impossible under the Contractor Agreement you sign. If you leave a reassignment and subcontracting possibility open, check if your agreement provides for not doing it without your written consent.

The basic Contractor Agreement template you might customize or use as-is — https://www.docracy.com/4754/contract-for-mobile-application-development-services

Conclusion

Needless to say that both documents we've given a brief overview of have many more clauses and provisions one shouldn't ignore. Entering into contractual arrangements is not fun and game but a very responsible step requiring your own cautiousness say nothing of professional advice. Still, forewarned is forearmed, the ball is in your court now. If needed, you may invest more time into studying all the aspects and preparing all the documents involved and do it as may be required by law or project premises.

Disclaimer: This article is only outlining some general guidelines based on certain personal experience and must not be regarded as a professional legal advice. The author, Rosberry, Docracy and the original authors of the legal documents cited disclaim any liability in regard to the use of these docs and materials without a certified legal attorney.