Above all, the purpose of the agreement is to protect your software. The idea, the team and the commitment alone are worth just one dollar nowadays. A startup gains its real value when people start using it and the brand gains recognition. Therefore, in the early stages, it's the software that makes a startup's only valuable asset. A truly charismatic leader is another important asset, for that matter.
NDA - non-disclosure agreement - when and how to sign it?
I receive numerous emails from people interested in developing a startup that refuses to disclose the details unless the NDA attached to the email is signed. As soon as I open the attachment, I see is a contract which stipulates horrendous fines for the violation of various provisions of the agreement, amounting to as much as 10m EUR. I never sign such contracts. Ideas alone are worth next to nothing; it is just the charismatic leader that counts.
Does it mean I should not sign the NDA at all?
In my opinion, at the stage of submitting first price offers there is no need to sign the NDA. However, if you still believe that your idea needs a proper agreement to protect it, you may sign it, but without stipulating financial penalties, only reserving yourself the right to protect yourself whenever a software house (SH) unlawfully takes advantage of your idea. Thus, you will likely get more tenders and won't discourage prospective business partners with the million dollar fines in the contract.
NDA - when penalties and strong safeguards are necessary
I have experience working with a number of startups whose idea was not very innovative itself but the data required to prepare the offer was extremely sensitive. This mostly concerned projects where software met hardware. The devices had internal algorithms the disclosure of which would make the company need to recall products from the market, and essentially go bankrupt. These were the only cases when I did agree to sign the NDA with high penalty fines.
If you are interested in receiving a simple NDA sample, contact me at: email@example.com
Application implementation agreement with a software house
I assume you have chosen a software house working in scrum methodology. Flexibility will be crucial for both parties to the contract. You already have documentation in the form of user stories that you should attach to the agreement and man-hour estimation previously prepared by the company. If you do not have those, read more on how to create relevant documentation.
Data you should possess before entering contract negotiations:
- Hourly budget for development of the application to MVP (minimum viable product) version.
- The number of sprints, in which the application will be made
- Total hours allocated to be burned in each sprint
Two attitudes that a software house can take:
They give you people while you pay for their time, regardless of what they do. They are not interested in ready functionalities, they care about time.
- This is pure body leasing, the least profitable approach for a startup. People are not fully committed, they often work remotely, the programmers may not even physically be in the company. The resulting code quality is poor and riddled with errors, but it is the customer who ultimately pays. In this situation the SH is the only winning party, as they get paid either way.
They give you a Product Owner, a Scrum Master and a team that can handle the functionalities stipulated in the valuation
- This is the best attitude and possibly the only sensible one for you as a startup. You have a team of real people who will create for you particular stages and they are accountable for the functionality. If the valuation is poorly executed and the overall budget is exceeded (e.g. by error amendment cost) - the SH is ultimately the losing party. Put simply, it is ultimately in the interest of SH to get the job done.
As for the second option, if you know your budget and the scope of work needed, you should sign a contract for the performance of the whole application. However, this is not scrum! - what if you want to introduce some modifications during the production process?
Software house will insist that you sign a contract for e.g. 700h of work, which is as much as you want to spend on your MVP. This is due to the fact that they must effectively manage their resources and cash flow. However, there is no way around, you can’t reconcile what the SH and the startup need.
You should sign a general agreement including copyright, liability, confidentiality provisions etc. It should include general provisions regarding particular functionalities as well as the price for their implementation.
Note: SH may want to reserve itself a margin of error and make the client accountable for covering its cost in case of inadequate estimation. A healthy margin would range from 5% to 10%. Anywhere above this, the software house should account for bad estimation. You may also want to require a minimum margin to act in your favor e.g. 15% in case when in the course of the project it turned out you do not need all the functionalities.
Key actions: Add an agreement provision that each sprint requires an appendix that specifies what is to be done in it. Such attachment can also be circulated in the form of e-mail and confirmed by both parties.
This will allow you to figure out your available hourly budget to work within, and with each sprint, you will be able to review the scope of functionalities e.g. replace the old functionalities with the new ones, as per the initial user tests.
All copyright should be transferred to you. Do not sign a license contract as it may mean that you do not own the code, which constitutes no value in a startup. At the end of the copyright paragraph, add the provision that if the contract does not stipulate particular field of use to which the copyright is transferred, the SH is required, at no additional cost, to transfer it to the new field upon request.
Do not introduce a non-competition clause which specifies the technology or modules used in your startup. A non-competition clause should apply to the purpose of the application.
E.g. an application for the design of gardens may include the following clause: SH will not create a web application to design gardens for the period of 12 months from the commissioning of the project in the German market.
SH makes software, so a clause like "the SH will not use the "3D engine" implemented in my project for a period of 12 months from the release of the application" may lead to a major conflict and result in the contract not being signed.
If you have any questions please comment or contact me directly.