Signing a contract appropriately is really important when doing business, as well as more so when you’re outsourcing your work to a 3rd party in a different geographical location entirely. Not only does it protect both parties from any kind of malpractice, it also puts down the scope of the project and covers other necessary details, like payment terms, delivery of jobs, etc
Here are few things to consider while signing a contract:
Monthly or Fixed payments
First of all, ask yourself whether you’ll be paying a fixed price for the project or paying on a monthly/weekly basis. Right here’s how to decide.
Fixed Price: This works well when you are particular about your requirements and you have actually outlined out your specs at the start of the project. Fixed price decreases the danger but if there is a change in scope, you will have to negotiate a modification in price.
Time and Material: If you’re not really certain of your requirements, it makes sense to choose a Time & Material model, where you pay for the resources used. This will allow you to make changes freely and will certainly not problem the company in case modifications prolong the project.
How to handle changes?
Your product roadmap will certainly alter. It’s vital that you agree on a system where modifications and the associated budget/timeline adjustments are managed. In a T&M agreement, this is less of a problem, since more modifications will certainly suggest more time. However in a fixed price arrangement, right here’s what we advise:
Smaller changes: Defined as changes that take a few hours as opposed to a few days to finish. A lot of developers generally soak up these modifications.
Bigger changes: These may take more than a day to implement and might involve undoing something currently constructed. There are two ways to treat them:
- The customer notifies the developer of the modifications and the developer returns with the modified quote and timeline.
- You choose to spend for any changes on a T&M basis.
On a side note, this might be the time to think about agile development, where development is carried out in independent parts or modules. If modifications need to be made to the parts that have not yet been begun, they can typically be quickly taken in. Modifications made to modules that have actually already been developed can be more difficult and need modifications at the design and backend level, which might be additionally complicated due to reliances.
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? Normally, the project is broken down into modules or milestones, which may be further subdivided into functions or user stories. The very best practice is to have timelines and due date set for each of the modules, such that a rough timeline can be created for the entire project.
Some contracts penalize for timeline hold-ups. If there is sufficient hold-up (say over 15 % -25 %) that is not a function of a modification request or obstructions, a financial charge may be imposed.
Ways to setup a payment schedule?
Developers usually request for something upfront and clients typically want to make the complete payment after the last shipment. Right here is an example of an app worth $20,000.
- Advance Payment: $400
- Payment after design is completed: $700
- Payment after first development milestone is reached: $1200
- Payment after the very first shipment: $1800
Using escrow can help incorporate trust in the contract. The developer is confident that he will certainly earn money if he does his job. Likewise, the customer knows that she will certainly not lose her money if they work is not done to her satisfaction level.
Ways to deal with maintenance?
Projects are rarely ever completed at the time of handover. Nature of software is such that bugs are found after genuine users start using the product. So ensure to structure the maintenance contract such that bugs can get resolved.
How long will the maintenance period last? Anywhere between 3 months to 1 year is an understandable period, depending upon the intricacy of the product.
What type of issues will be taken care of in the maintenance period? Sometimes, there can be a thin line in between a “bug” and a “modification”. So concurring in advance on what can be managed during a maintenance period will absolutely conserve headaches later on.
Its useful to highlight what constitutes deliverables at the end of the project. While the ‘code’ and the files will certainly be transferred to the customer, the following documentations are generally practical (and frequently forgotten) for the new developer that may take over.
Read Me file: A ReadMe file that describes what is the file structure and what design/development requirements have actually been followed.
Video Walk Through: A screencast of the code & files can supplement a Read me submit to aid new designers find out much faster.
Comments: Remarks for each part of code are definitely needed for new designers to understand the flow in the file.
Timeline delays: If there is excessive hold-up (state over 15 %) that is not a function of a change request, it helps to put in place some kind of penalty.
3rd party services: If there are any 3rd party services that will be made use of, the general practice is that the customer spends for it. However, these must be described at the start.
NDA: While it is tough to enforce non-disclosures, it makes sense to have a statement that safeguards your copyright. That said, lots of software programs are “commodities” (for eg. login, file sharing) and can not really be dealt with as IP.