One of the things that we do best at Bright Inventions is helping startups build their first MVP. It's pretty common that founders select us as their technology partner and rely on us to turn their vision into reality. We enjoy this kind of challenges and over the years have started to understand quite well why - simply said - startups like to work with us. However, this note is purely intended as a set of generic things to look for in a technology partner.
It really helps when seeing your IT partner in person doesn't take half day of travelling. Software development is one of those activities in which a lack of communication between parties can result in heavy costs further down the road. Most of the time Slack, Google Hangouts, JIRA, etc. work perfectly but there should be times that you can just all sit together in one room and make sure you're well aligned. Misunderstood or missed requirements are easy and cheap to fix in the early phases of the project but very expensive later on. Start project with a workshop and keep meeting on a regular schedule to validate work in progress and realign your expectations.
Since you're going to be working together very closely it's vital that you both share the same values and that their working culture is close to yours. Do you hate when somebody is late for a meeting? Are you obsessed about keeping discussion to the point? What is your definition of "done"?
Vet your potential partner before any agreement is signed. Make sure you can keep up with them on a personal level. You don't have to be best friends but there needs to be solid grounds for mutual appreciation, trust and understanding.
You run a startup and therefore things change rapidly. Each day brings new ideas, things to check out, more requests from the clients. You should be able to share it all with the developers working on your product without having to go through any soft of legal layer. If adding even the smallest change to the feature set requires signing an annex with them - it's not worth it. If there are things that you would have no problem asking your in-house developer but for some reason are prevented from asking the same from developer working for your partner company then it's not worth it neither.
You should be able to work with them as if they were part of your team. Effectively they should feel that they are a part of your team. There's a catch: you also need to treat them as a part of your team.
In order to make the above possible it's good to work out a simple to understand payment model. You might like the benefits of a fixed-price approach but in reality that would quickly limit the scope of changes that you can reasonably request from them. A sensible approach might be to work in sprints and have them charge you a fixed amount after each sprint. It lets you refocus after each short iteration and nobody will make any fuss over requirements changing from sprint to sprint. Your vision will evolve and your partner should adapt.
It's all too easy to find a partner who would just blindly follow your requests. It's much harder to find one that would put your ideas to the test and challenge you. One that would truly care about your ultimate goal and would openly discuss their insight until your (or their) point is validated. Let's say that you want to add full offline support to the app you're building (which is usually a tall order but doesn't seem so). They can either sheepily follow or convince you that there are more pressing issues in the backlog that would benefit your users more.
Sometimes you come to them not with a problem but with a ready solution. It's better if they are not afraid to point you out misassumptions in your proposed solution and are openly against executing something that doesn't make sense. If you've chosen the right partner they will surely have more technical experience than you have and they will also have some business experience from the past projects.
Before you start relying on a development partner you absolutely need to make sure that it's a company that maintains a stable team of high-quality programmers. You don't want them to restaff your project team every few weeks. You need to have a sense of stability and be sure that the people who work on your project won't get reassigned willy-nilly to another gig. Also, if there's any way you can get more familiar with the individual developers who will work on your project (their personal blogs, conference talks, etc.), it's a great plus.
People who will work on your project will have to come up with different sorts of the estimates. It starts with a high-level estimate before the kickoff, i.e. how many sprints might we need to accomplish a given feature set. Then there are estimations made during sprint planning and estimates made on the go when you check with developer how much time they need to complete a given task. It's very hard to check but you'll be much better of if you can trust the estimates coming from them. If you realize after the first couple of sprints that their estimates are way off, you have to openly discuss it and expect them to be more realistic. You make business decisions based on the estimates you get from them. Obviously, you always have to plan for some buffer but you can't accept things taking twice the time they estimated. An estimate is not a promise and it's not a commitment but it should mean something.
You need to be able to track progress easily and on a regular basis. It starts with the source code repository. Be sure that the code gets pushed to your GitHub or BitBucket account. Make sure there's a continuous integration system that builds all of the components after each code change and that automatically deploys it or pushes for testing. Make sure that continuous integration system stays deployed to machines that you control so that you can still use it if you stop working together.
Choosing the right partner for working on your MVP is a leap of faith. You need to feel good about your decision and have full trust in them. It might be hard to find a partner that meets all the criteria listed in this note but at least make sure that they won't have problems challenging you if they disagree. They might be right.
Originally published at brightinventions.pl