Outsourcing software development can be a very confusing affair for the uninitiated. Dozens of clients have come to us with misconceptions and botched projects that needed serious fixing, so we decided to make a quick outsourcing guide which details some of the points to keep in mind when engaging an outsourcing company for your development needs.
Do your research
Going shopping before you know what to buy is a great way to end up with junk. It is important to have a sort of baseline checklist that should be covered before you even begin the search:
- Have a product concept, and write out the requirements in clear, accessible language. The more details the better, as it will help firms determine a general estimate and come up with a team composition that best suits your project.
- Be prepared to audit the actual code a development firm can provide. This means being knowledgeable in development yourself, or hiring someone who is capable of evaluating the code you’ll receive from the dev firm.
- Have some general timelines in place and a budget in mind. Instead of thinking in terms of a fixed price project, try and set some milestones and determine a budget for those goals in order to cover the ongoing expenses of building and maintaining an app.
- Be ready to commit to a single development partner. One of the biggest risks of developing software is “switching horses” midway through building a platform. Conduct due diligence and commit to a single development firm for the long-term in order to maximize your resources and development cycle.
Follow these guidelines and it will ensure a solid start in whatever development project you have in mind. Reaching out to firms prior to having this information ready will just result in them asking you for it anyway, or worse, promising you that it’ll be handled “later” after a contract is signed (and it’s too late to back out!).
Keep the NDA’s simple and to the point
It’s not necessary to impose draconian NDA’s on people just to discuss a potential partnership. Product owners are always worried that someone is going to steal their million-dollar idea, and are wary of engaging any third party companies without first ensuring that they are covered with a ironclad NDA. However, NDA’s are a two-way street, and we’ve turned away potential customers in the past due to incredibly oppressive legal clauses present in these agreements.
An NDA is essentially a legal risk that the outsourcing company is taking entirely on themselves by signing in the hopes to build trust with a potential client. Although many clients fear that their ideas and code are in danger of being stolen by a nefarious outsourcing firm, the fact is that most normal development companies have no interest in stealing your business.
Software development firms focus on software development - that’s it. They aren't interested in the business domain, marketing, or even product design, at least in terms with reading what customers want and appealing to their desires - that’s up to the product owner (i.e. the customer - you!) So you should not need a draconian NDA with extreme fines and nebulous legal wording to protect you from every possible angle. If anything, such an NDA will scare away legit dev companies, because they won’t want to deal with the hassle.
An NDA should be straight and to the point - don’t share code, don’t share proprietary data, and a duration of two years after the termination of the contract. That’s really all you need.
Plan on being very involved in the process
There is a large degree of participation on the side of the individual or business employing a development firm to build a project. Building sophisticated platforms is rarely a “turn-key” affair. Even the simplest apps require a great deal of business logic understanding to do properly, which the product owner will have a far better grasp of compared to the engineers, at least initially. Good software development requires constant feedback from end users and the product owner.
Time and again we’ve seen product owners who take a hands-off approach to developing a platform, passing it off to a third party development firm which assures the product will be built to spec despite knowing very little of the business sphere and true desires of the product owner. This leads to miscommunication, wasted resources, and substandard products that miss their target audience. The key lesson here is this - developing an app is a big commitment, both from the engineers and the product owners themselves.
One should be prepared to spend a fair amount of time working directly with your developers to make sure the product turns out the way you envision it. This can be done through a variety of ways - creating a set of technical documents/requirements prior to engaging a software firm, participating in regular standup meetings during the development process, and getting acquainted with the technology-side of development to help better understand the engineer’s point of view.
In short - the more you invest in the process, the less time you’ll waste and the more true to design the product will become!
Prepare for the long haul
Many would-be startup dreamers have a picture in their mind as to what the ideal development cycle should look like - a few months of intense expenditures on development to release the product, then a “maintenance cost” to keep the app running while the owner reaps an ever growing amount of revenue for their completed app.
This is, to put it bluntly, a pipe dream. Successful apps - and businesses in general - are always improved and developed, otherwise it would be too easy for a competitor to create a newer, more optimized version of the same platform and claim a larger part of the market share. Ask yourself - what major modern day app is truly “finished,” making money, but no longer in development? Even industry giants like Facebook, Uber, and other household-name apps are in a constant state of evolution.
In reality, the monthly development costs do not suddenly decrease after a product is “finished.” As your app grows in popularity, competitors will inevitably appear, and you’ll need to keep on top of the latest features to meet the needs of your constantly growing (and demanding) customer base.
Therefore, it’s important to understand this facet of software development right from the start. A good app requires constant maintenance, improvement, and development to stay competitive. It is not like building a house, where there is a high initial cost and then light maintenance from there on out - it is more like building a farm, which needs to be nurtured and cared for regularly in order to produce a good yield (of satisfied, repeat customers, in this case!)
Keep it agile, and favor flexibility with your engagements
Unless you are able to predict with an extremely high degree of certainty what exactly your project’s requirements will be, then you should stay away from fixed price engagements.
Often we will receive inquiries from startups or established businesses that are building a new product, but who will insist on a fixed price contract model. This is a recipe for disaster for a variety of reasons which I covered in this article, but the main reason is this: Every time project requirements change (and they usually do), you’ll need to renegotiate the contract, which uses a ton of time and resources - both yours and the devs.
The major reason why product owners dislike this approach is its potential for abuse by the developers. Much like a scrupulous taxi driver who takes unnecessary detours to increase your fare, product owners worry that a developer working on a T&M contract is likely to stretch out the project as long as possible, and drain the product owner’s bank account in the process. However, with any good development firm, this concern is completely unwarranted. Here is why:
The developers themselves are eager to see a project through - and they will get paid whether the project finishes early or late. If anything, a stretched-out project is a huge demotivator for an engineer. this will likely lead them to getting bored and quitting, which is the worst possible outcome for a development firm - good developers are worth their weight in gold!
Outsourcing companies live and die based on their reputation. Competition is so fierce in the market that it is essential to build a list a respectable list of references that will vouch for their abilities. A company that alienates customers by dragging on projects will quickly find themselves at the bottom of the heap compared to their competitors.
Speaking of results, a development firms are judged primarily on their projects which are in production. Clients like hearing how long a product took to reach its first release or to become a functional MVP. If a company stretches out projects, its only hurting them in the long-run as their future clients will quickly figure out how whether or not they can meet deadlines. Remember - it only takes a quick call to a former customer to determine whether or not they can work quickly and produce deliverables.
As mentioned previously - staying constantly engaged and in good communication with the engineers will provide more than enough assurance that development is going the right direction.
Own your code: Code repositories and how they work
You should always be in control of your code, regardless of your personal technical expertise. One of the biggest red flags we see when engaging a new customer is when they come to us with a half-complete project built by another firm… but they don’t have ownership of their own code. Now what does that mean and why does it happen?
Often when a non-technical product owner engages a developer to build them an app, what they receive (and see) is the finished product - the total sum of all that code which the product is composed of. However, in many situations, the owner is not in control of the code that makes his or her product - essentially, they are getting a picture of the house they paid for, instead of the actual house.
This is all well and good (to continue with the metaphor) if the house is in great shape, and you plan on selling/renting it out to others. But what happens if you’re not satisfied with it? Can you go in and change things yourself? Or hire someone else to replace the previous builders? Not without the original source code, you can’t! Essentially, your code is held hostage by the people who wrote it. If you don’t like the result, there’s not much you can do besides begging and pleading the original developers to change it. Not a good situation to be in!
Any development firm worth its salt will provide complete access for the source code to the product owner at all times, regardless of whether that product owner intends to dig around in it themselves. It should be a natural part of your contract with a developer to have ownership, so that in case things go sour, you still have control over what was written (and paid for), and can show it to a third party for review.
Conclusion
If you were to summarize all these points into a single sentence, it would essentially be, “conduct due diligence - and be involved.” Engaging a development firm for a project is a real commitment which will inevitably cost several thousand dollars to see through. Therefore, it’s worth doing the research beforehand and asking questions before signing a contract and getting in deep with the development process.
We hope this outsourcing guide provides some insight on how to get started off on the right foot. When in doubt, just remember - ask questions, do research, and pick your partners carefully - the future success of your platform depends on it!
