Software House Agreement? Use the checklist!

Not so long ago, I had a TechHub workshop at Warsaw’s Google Campus on software company agreements, taking a closer look at coding for startups.

When participants begun to share their stories, I was struck how many of them were about “third-party failures” (for both freelancers and companies). Being one of those external contractors, I was in a shock: these projects were derailed by things easily avoidable — to me at least.

That’s why I’d like to show you my three checklists, named roughly by the topics they cover: tech stuff, copyright, and other stuff — obviously the most extensive of them all. I hope that the things mentioned below will not only help you save money, but also prevent many stressful situations.

The Tech Stuff

a.k.a. service provider requirements that have to be met in full before making any type of commitment. If your startup team doesn’t meet the criteria below, it’s a warning sign: you might be dealing with rookies or a team who have never taken on bigger projects.

1. A code has to be kept in a repository, which means:

• You can always roll back to an older version,
• Teams can collaborate while working on a code,
• A code is always available both on a local machine and a server (GitHub, GitLab, etc.),
• It’s much easier to backup a code — on the GitHub, for the third-party, or GitLab, for a service provider,
• You can run code quality auto checks on a remote server,
• You can work on multiple features/revisions at the same time,
• If you work with a freelancer and a repository is located in-house, you don’t lose access to your code when the project is completed.

2. Auto tests — if you want to be a professional, you can’t do without them. You need them because:

• You have to be able to see whether adding/changing a functionality in Module A affects Module B,
• Introducing a new person to the project team is more manageable (if “the new guy” breaks something while coding, you’ll know that before the code goes out to the production server),
• You’ll have to think twice before any piece of functionality gets coded,
• If you hand the development over to another team, they can’t “destroy” your work,
• Speaking about tests, you should think about a Quality Assurance team. You won’t be required to have one, but it’s a testimony to the quality of your programming process.

3. Code review, i.e. the process where every piece of code is analyzed by a different person. This is very important, as someone who didn’t create a particular piece of code can offer a new insight by:

• Finding a bug unnoticed by the author,
• Offering a better solution to a given problem.

4. CI (Continuous Integration), i.e. the additional server used after moving the code to the repository which will:

• Run all auto checks throughout the project,
• Check for any outdated external libraries used in the code and also run a validation check,
• Check for potential security breaches,
• Prevent a code that didn’t pass tests from being used in the project’s main development pipeline.

5. Mandatory use of English — seems like a secondary issue at first, but reading a code that is written in both English and another language:

• Is a bit inconvenient,
• Makes a bad impression (looks kind of messy).

6. Documentation — I can’t imagine how you’d expect a project to be maintained in the long term without a proper description of major functions or methods.

7. Known framework vs. custom systems (or spaghetti code) — this might be harder to verify by someone without a proper technical background. Using a known framework:

• Is a safety measure; you don’t have to rely on one company and their programmers, they’re not the only people in the world who know your code,
• Allows new people/companies to join your project and get up to speed with ease,
• Enables use of libraries made by global community,
• Means that the community is responsible for maintenance, development, and security of your code base,
• Results in you having access to an enormous component database that you don’t have to code yourself and that means savings.

8. Staging, test, and production servers — the ability to preview the code and partial results in another environment (not the user server).

Copyright

It seems like there’s not much to worry about in the beginning stage. But, if your project is a major success, this can be a real setback:

• First of all, make sure the copyright is granted :) (by the service provider).
• If you work with a company, check whether their contractors have waived copyright (e.g. as opposed to in-house staff).
• AGPL libraries — that doesn’t have to be the case in all your projects, but if you don’t want your code to be open-source, make sure you stay away from those.
• Include a “provision of a standard software” clause in your agreement. That covers what is yours, and what is granted to the other party. For example, a software house uses a portion of code from their library to solve a typical problem (like logging in). You’re not granted full copyright, but you get the product delivered faster.
• Remember to take a look at license terms for free scripts and images — some of them will require a proper credit on your website.

Other stuff

By now, at Binar::Apps, we’ve delivered dozens of projects (if not hundreds). I think that the negotiation process would be even smoother if our customers had certain issues thought out beforehand. For example:

1. Rate per hour, project stage, or fixed for the whole project. This is one of the most important decisions:

• Hourly rates allow maximum flexibility for both sides: you can modify ongoing projects to ensure everyone works toward a common goal; it equals the distribution of expenses, but it requires a certain degree of trust; you have to believe the company is honest and reliable and makes the best use of its time,
• Fixed project price — you get the impression that you know exactly how much you’ll pay for… but this can be quite deceptive. In real-life situations, there are always some changes to be made, either in a project or indirectly, requiring an annex to be signed. The contractor or service provider will be more than reluctant to work beyond the project scope without additional payment. The contractor will do everything to minimize the overall effort; the client will do everything to get as much beyond the agreed specification as possible,
• Staged billing — this is a hybrid model, you agree on a fixed price for modular pieces of work. Depending on the module size, you’ll have to deal with some of the pros and cons of the above :)
• Before you make that kind of decision, I recommend reading “Lean Startup” by Eric Ries,

2. Establish the delivery method: whether it’s a whole project or weekly updates with your feedback and user feedback.

3. Agree on delivery and acceptance phase for both sides — you can’t allow the acceptance process to take forever to complete.

4. Application maintenance after launch, SLA parameters — you have to include a provision that the contractor can’t just “abandon” you and the project after final delivery/launch. The real life-cycle of software begins when end users start using it.

5. You have to define both partial and final delivery terms & conditions.

6. Difference between maintenance and further development — what level of service do you get when the contractor only maintains your system?

7. On what terms can you get out of the contract (either you or the contractor)?

8. Prepare an NDA, don’t waste time on writing a list of big contractual fines.

9. Include a clause on allowing/not allowing your product to be included in the provider’s portfolio.

10. Get to know who implements your application on a server and how. Define who is responsible for application server availability on and post-launch.

11. Contractual fines — see situations in which they can be imposed.

12. Last but not least: consult your lawyer :)

For more tips & tricks on working with software house check our Binar::blog