Structuring a contract properly is important when doing business, and even more so when you’re outsourcing your work to a third party in a different geographical location altogether.
Not only does it protect both parties from any form of malpractice, it also lays down the scope of the project andcovers other essential details, like payment terms, delivery of projects, etc.
Here are the things to consider while structuring a contract:
1. Go monthly or go fixed?
Firstly, ask yourself whether you’ll be paying a fixed price for the project or paying on a monthly/weekly basis. Here’s how to decide.
- Fixed Price: This works well when you are certain about your needs and you have detailed out your specifications at the beginning of the project. Fixed price decreases the risk but if there is a change in scope, you will have to negotiate a change in price.
- Time and Material: If you’re not very certain of your requirements, it makes sense to go with a Time & Material model, where you pay for the resources utilized. This will allow you to make changes freely and will not burden the service provider in case changes prolong the project.
2. How to handle changes?
Your product roadmap will change. It’s imperative that you agree on a system whereby changes and the associated budget/timeline modifications are handled. In a T&M agreement, this is less of a problem, since more changes will mean more time. But in a fixed price agreement, here’s what we recommend:
- Smaller changes: Defined as changes that take a few hours as opposed to a few days to complete. Most developers generally absorb these changes.
- Larger changes: These may take more than a day to implement and may involve undoing something already built. There are two ways to treat them:
- The client informs the developer of the changes and the developer comes back with the revised quote and timeline.
- You decide to pay for any changes on a T&M basis.
On a side note, this might be the time to consider agile development, where development is done in independent parts or modules. If changes need to be made to the parts that haven’t yet been started, they can generally be easily absorbed. Changes made to modules that have already been built can be more challenging and require changes at the design and backend level, which may be further complicated due to dependencies.
3. What is the timeline?
If the project is done on a fixed price basis, what is the timeline and when are the final deliverables due? Usually, the project is broken down into modules or milestones, which may be further subdivided into features or user stories. The best practice is to have timelines and deadline set for each of the modules, such that a rough timeline can be created for the entire project.
Some agreements penalize for timeline delays. If there is sufficient delay (say over 15%-25%) that is not a function of a change request or roadblocks, a monetary penalty may be imposed.
4. How to setup a payment schedule?
Developers usually ask for something upfront and clients usually want to make the full payment after the final delivery. Here is an example of an app worth $20,000
- Advance Payment: $5000
- Payment after design is completed: $5000
- Payment after first development milestone is reached: $5000
- Payment after the first delivery: $5000
Using escrow can help incorporate trust in the agreement. The developer is confident that he will get paid if he does his job. Similarly, the client knows that she will not lose her money if they work is not done to her satisfaction level.
5. How to deal with maintenance?
Projects are rarely ever finished at the time of handover. Nature of software is such that bugs are discovered after real users start using the product. So make sure to structure the maintenance agreement such that bugs can get resolved.
How long will the maintenance period last? Anywhere between 3 months to 1 year is a justifiable period, depending on the complexity of the product.
What kind of issues will be fixed in the maintenance period? At times, there can be a thin line between a “bug” and a “change”. So agreeing beforehand on what can be handled during a maintenance period will definitely save headaches later.
6. Project Handover
Its useful to underline what constitutes deliverables at the end of the project. While the ‘code’ and the files will be transferred to the client, the following documentations are usually helpful (and often forgotten) for the new developer that may take over.
Read Me File: A ReadMe file that outlines what is the file structure and what design/development standards have been followed.
Video Walk Through: A screencast of the code & files can supplement a Read me file to help new developers learn faster.
Comments: Comments for every part of code are absolutely required for new developers to understand the flow in the file.
7. Other Considerations
- Timeline delays: If there is excessive delay (say over 15%) that is not a function of a change request, it helps to put in place some kind of penalty.
- Third party services: If there are any third party services that will be used, the general practice is that the client pays for it. However, these should be outlined at the beginning.
- Non-disclosure: While it is difficult to enforce non-disclosures, it makes sense to have a statement that protects your intellectual property. That said, many software programs are “commodities” (for eg. login, file sharing) and cannot really be treated as IP.
As you can see, there is a lot that goes into making a robust contract and we hope these pointers come in handy for you. If you’d like to know more about how to make software development outsourcing work for you, download our free ebook Outsourcing 101. It makes for a great read!