As a company providing outsourced software development services, we acknowledge the fact that outsourcing contracts often lead to misunderstandings, missed deadlines, extra costs, and even failed projects. This isn’t because outsourcing itself is risky, but because many companies, particularly young ones, don’t have much experience in crafting outsourcing contracts and establishing good communication with an external team. Here are the aspects of outsourcing agreements that can be crucial for your business.
The main cause of trouble with outsourcing is not making sure that both sides’ expectations align prior to signing the contract. From transparency issues, through micromanaging, to copyright claims, there are so many ways in which something can go wrong. While our list is not fully exhaustive, it can help you cover all your bases and avoid the most common outsourcing problems. Remember, however, that if you’re not working with a trustworthy tech partner, our advice might not be enough to help you.
Transparent cooperation rules
Transparency doesn’t have to mean constant vigilance, but it should mean that both sides communicate their expectations and intentions clearly. You, the client, should convey what the goals for the project are, and what results you expect. Your partner should help you establish these goals, along with a work schedule, procedures for reporting progress (including deadlines and resources to be used), and more. Meetings dedicated to scope planning and an exploration phase to set requirements for the project are a good way to go about it. This approach will give both sides the information they need to plan their work, and will leave no room for confusion related to completing tasks or monitoring the development team’s progress.
Communication during a software development project should be almost constant. Aside from progress reports, your tech team might need you to accept tasks as completed, reject proposed solutions, or correct their proposals to better fit your vision. In short, you need to establish a clear flow for feedback, keeping in mind that less is more.
Costs and rules of settlement
If you’ve never worked on a software project before, you might not know what costs to expect. They include work hours, licensing fees, subcontractors’ wages, taxes, and so on. Talk to your partner, or an outside advisor, because you need to make sure that the contract assigns responsibility for covering these costs to the appropriate side. It’s also crucial to establish deadlines for payments required throughout the project, and the penalties for failing to meet these deadlines.
Though companies rarely attempt to obfuscate what goes into the cost of their service, they still often fail at communicating their pricing clearly. This can lead to misunderstanding and resentment. Sit down with your technological partner and have them explain their decisions on pricing and team composition for you project. Remember that a senior developer’s work, while pricey on paper, can be less expensive than using junior developers for a difficult task and then improving on their inefficient solutions.
Though they usually become relevant only after the project has launched, it’s crucial to cover copyrights in the contract, and to do so early on, particularly in relation to the app’s codebase. Many software agencies cede all rights to the code they produce, but this affects the price of their service. To manipulate the costs, it’s possible to agree to a partial or temporary transfer of copyrights. This could allow the contractor to reuse parts of the code, but never to duplicate the entire app.
Another issue that falls under copyrights is the right to use your project in the software company’s marketing materials (such as their portfolio). This can be beneficial to both sides, as it’s effectively free advertisement through the contractor’s website and social media. The most important thing is to set the rules early and make sure both sides understand them, to avoid misunderstanding and conflict in the future.
Third party licensing and patents
Licenses for third party libraries, frameworks and assets can be necessary to complete the project according to your vision. If you’re not sure whether you’ll need any, talk to your team, and use the opportunity to establish who should cover the fees. Do this every time the subject arises. You don’t want your contractor to surprise you with the fees at the end of the project, not maliciously but simply because they assumed you would cover them.
If your project relies on specific technologies or solutions, pay attention to patents. For example, parts of OpenCV cannot be used in US-based projects, even though it’s free for commercial use. Other open source tools can be under similar restrictions, and it’s crucial to be aware of them before they become integral parts of your app’s codebase.
Be careful when using open source solutions, too. The GPL sticking license, for example, can mean that anything using GPL code needs to be distributed as a GPL solution. In other words, contractors who employ GPL code in commercial projects commit copyright infringement. This is a legal risk to clients, who become bound by this license and are required to share their codebase, essentially making their projects available for free. Make sure that both you and your partner are aware of the legal aspects related to the resources you use.
Waterfall is an approach to managing and organizing projects that originated in the manufacturing and construction industries. It offers an inflexible model, attractive for its perceived security (you get the price estimate for the entire project upfront). While this can work well in some cases, in others, it leads to disaster when an unexpected change on the market can’t be addressed without overhaulig the entire project plan.
The Time & Material approach (where pricing is usually dealt with on a monthly basis, depending only on time spent working on the project) allows much more flexibility and can be beneficial to both young, dynamic companies, and enterprises. It helps teams react more quickly to shifts on the market, as they can immediately adjust the development plan, while with the Waterfall approach they would first need to renegotiate the contract. For the same reason, Time & Materials makes it easier to pace the development process, by extending or reducing the team (which also allows for scaling monthly project costs as needed).
While this problem is caused by a disingenuine approach of software development companies, it can be mitigated through carefully worded contracts. Some software agencies with USA addresses (which may be physical offices or virtual ones) outsource most of their development to India, for example. This might lead to issues with communication, time zones, cultural fit, and even quality of service. The client should always be made aware of who will work on their app, either through a list of all the people involved, or at least a written guarantee that the work will not be outsourced to a particular country or countries.
Technical specifications and handover
You might be tempted to treat project specifications as a separate entity from the contract, something to deliver to the team when you’re ready to start work on your app. This can be a big mistake, as it means that there’s no clear definition of what the finished product should look like. This leaves you vulnerable to exploitation - your contractor can deliver unsatisfactory results with no repercussions. Make sure to at least include basic project requirements in the contract as an attachment (especially if you’re using the Waterfall approach), or specify how the issue will be handled throughout the project. If you’re using Agile principles, it’s expected that requirements might change or be expanded upon during development. Still, it’s a good idea to put project specifications on paper.
This ties into what will happen once the product is finished. A good contractor will insist on establishing a handover process, with a proper definition of done not just for the entire project, but for each sprint (usually a week’s worth of work that’s delivered as a working element of the app). Handover doesn’t just happen automatically - whoever will be responsible for managing the app needs to be eased into it. You need to be able to judge whether your contractor has delivered what you both agreed on. Putting all of this into the contract can be a big step towards protecting yourself against careless or even purposefully neglectful contractors.
Good communication is crucial for a fast-moving software project. You’re going to want to oversee your team’s progress, receive reports, and be available in case they need additional information for you. Make sure both you and your tech partner open several channels of communication, ideally including the option to talk directly to specific team members. You also need a schedule for updates, meetings and reports. This will make both you and the team feel more secure in the project’s progress.
Micromanaging the tech partner
It’s undoubtedly tempting to closely watch everything your technological partner does. You have more at stake, and may feel the need to always know what’s going on. Sometimes it can be even worse if you have enough technical knowledge to micromanage your contractor, forcing them to complete tasks in a certain order, or even in a certain manner. This is a fantastic way to let the team know you have zero trust in them, and to negatively impact their productivity while upping their stress levels (as they’ll have to spend time and effort on explaining their choices to you). When taken too far, such an approach can lead to missed deadlines and increased costs. Remember that your partner has delivered many other projects throughout their career, and if you force them to work in a certain way, you won’t be able to take advantage of their know-how and processes.
DevOps and post-launch support
These days, software development is split into several elements: back-end, front-end, and operations. DevOps is one of the best approaches to managing project operations and infrastructure, with optimization and efficiency in mind. Some software agencies offer DevOps support for each of their projects, some don’t. If you work with a partner that doesn’t take care of this, remember that you’ll need someone on your team to take over the job.
Post-launch support, on the other hand, is something we believe software agencies simply should provide. There are some companies that quickly produce code for the projects, end the cooperation with a successful delivery, then refuse to provide support because it was never a part of the agreement. Their developers may already be deployed in other projects, and you’re left to deal with bugs or scaling issues on your own, while real users judge your business based on the experience.
Security and data protection
With recent legislation pushing businesses to put more resources into data protection, security has become crucial to project’s success. Yet many software consulting firms don’t include it in their offer. This means that you need to hire someone for the job, or outsource it to another contractor. Both options are viable. You simply need to find the one that suits you best, and a software agency that will accommodate your needs.
Testing is an integral part of software development, at every stage of the process. Omitting it is almost never a good choice, so if your potential partner doesn’t provide quality assurance, reconsider working with them, as this can lead to lower code quality. Good QA isn’t just about preventing bugs after launch. It also speeds up problem solving during the development process and helps developers focus on doing their job rather than on finding and eliminating issues. It’s a cost-efficient approach to building a stable, scalable software product.
If you need a team that always strives towards transparency and technical excellence, talk to us.
Developing your software project with the right people can make all the difference for your business.