Elsewhere, I've written about how the Scholarcy MVP was built with a micro-budget, and shared lessons learned from an unsuccessful innovation fund bid. In this post, I'll share some key learnings from my first-time experience of working with an offshore company for outsourcing the development of the Scholarcy web library.
With Scholarcy, I took an API-first approach. This has proven to be a good strategy, as it provides separation of algorithms and data processing from user-facing functionality, while allowing a variety of new client applications to be built on top. For example, the Chrome Extension pretty much consists of an HTML template and a bunch of API calls. It was also borne out of necessity: I had the skills to build the machine learning models and the back end, but not the front-end web/mobile apps. Finally, it allows the possibility of licensing so that others can integrate the API into their own applications and services. Right now, only about 20% of possible API functionality is in use in a client application, so there is plenty to build on for at least the next 12 months.
My introduction to outsourcing was the result of serendipity. While I was building the API, I received a cold contact pitch on LinkedIn from a web developer and designer based in Ukraine. I had received many similar approaches on LinkedIn, but this message stood out as friendly, direct, clear and well-written, but not at all pushy, and his portfolio looked impressive. At that time, I'd just started thinking about what the web app might need, so we started a conversation.
The web developer signed an NDA and I sent him some initial requirements. To his credit, at this point he realised that my requirements were outside his skill-set, and was open about this, but could introduce me to another Ukrainian company who would be able to help. Following introductions, discussions and a further NDA signing, I received a detailed estimate from the new developer, along with a services agreement. I was impressed at this stage by the amount of care and detail put into drafting the documents that were to form the basis of our collaboration.
There's an element of risk when two teams, previously unknown to each other, separated by thousands of kilometres, engage in service transaction. The client worries about whether the work will get done to the required standard. The service provider worries whether the client will move the goalposts or refuse to pay. Establishing trust is of the utmost importance, as is formally agreeing the responsibilities and expectations of both parties. Trust is not something that happens just once, but is an evolving process. In brief, mutual trust was gained and thus successful project delivery was achieved in the following ways:
- we agreed fair payment terms, which included an upfront payment to begin development
- we communicated daily via Slack with weekly project update meetings
- we set up a shared, private repository so we could keep track of both functionality and quality
- we set up shared access to staging servers, mail and payment gateways for testing end-to-end functionality
Rather than go through a blow-by-blow account of how development proceeded, I'll instead detail the most important factors that led to the successful completion of the project.
Before committing, have initial Skype conversations to agree the goals of the project
This is a good way to build mutual trust and understanding. Find out about previous projects that the outsourcer has worked on and make sure they have a clear idea of what you want to build. Show them a demo of existing progress if possible - this could be your MVP, interactive mockups, or user flow diagrams, for example.
It's important to have an upper bound on how much you are able and willing to spend. Be realistic and do some research. If you have a small budget, limit the scope of the project. In this case, I had a budget of around $7K. It may not always be advisable to disclose your budget up-front, but you should have a realistic idea of how much you expect the work to cost, so that you don't waste your time or theirs.
Before you engage, have a clear set of requirements and user journeys
You need to detail exactly what you need and what the user's journey should be, from landing page, through registration, confirmation, log in and onboarding. List all the interactions and what the expected outcome is for each. A good outsourcer will help you put this together if you are not sure.
Expect the outsourcer to ask a lot of questions
This follows on from the previous point. If they are not asking questions, I'd consider this a warning sign that there is insufficient understanding or interest in the requirements.
Agree a fixed price, but ensure the estimate includes both costs and days of effort
The estimate should not just say $X, it should be broken down into days of effort for each requirement milestone. It should be clear how the cost estimate this has been arrived at. The days of effort should allow contingency for a certain number of changes to be made during the project.
Run the estimate by someone who has delivered a similar project before
In my case, I had a fairly low, fixed budget which my developer was able to accommodate, but I still ran their estimate by a friend of mine to confirm it was realistic and the days of effort were reasonable.
Have formal Statements of Work with agreed milestones
Ensure you are clear on what will be delivered when, and what the acceptance criteria are. Formalise a process for terminating the agreement if milestones are not met or accepted. Arrange the milestones to reduce the risk to both parties. For example, a first milestone might be a small task that you can use to evaluate the code quality and overall expertise of the developer.
Good project management
Set up a board that maps the milestones to tasks in the requirements, and keep it up to date. In this case, both the outsourcer and I were happy using Trello, and we still use this to keep track of maintenance and bug fixing, several months after the original project was completed.
Communicate daily
This is much easier if you choose a developer in a similar timezone (say ± 2 hours). For this project, we set up a private Slack channel for ongoing, daily discussions and messages, and had a weekly Skype call for milestone updates.
Keep control of the source code
You don't want to be in a situation where a product is delivered but you don't have the code. Ensure that the code is delivered for each milestone, or better, ensure code is checked into a repository that you control.
Complete, accept and pay for the first milestone before continuing with the next
Ensure you are happy with the first tranche of work before committing to future milestones. The process for this should have been agreed in the Statement of Work.
Pay promptly
It should go without saying, but once you have accepted the milestone, pay the supplier straight away. Big companies can be slow to pay because of bureaucratic processes, but as a lean, fast-moving startup you don't have this excuse - so pay on time. Payment by milestones reduces the risk for both parties, and being a prompt-paying client will be rewarded many times over when it comes to bug fixing and maintenance.
I hope you found this post useful. Drop me a line and let me know about your experiences of outsourcing!