Five more reasons why buying software development could save your startup (Part 2)
I hope you read my colleague and namesake’s post about how buying software development could save your startup company. I’ll add to the list with five more reasons, which are more from the business point of view. Toni’s post was based on the CTO’s experience in a startup called Headsted, mine will be from the CEO and investor point of view. Recently I chatted with several investors in the Arctic’15 conference, and the message was clear. If an entrepreneur is planning to spend the invested money in its own development team, the investor will quickly move on to hear another sales pitch. Why, you ask?
Think about a good profile, write the job description, try to get visibility to the post, reply to good applications, appropriate comments and dumb questions. Interview, interview again, give the technical tests (if you have the know-how), negotiate about the contract… Usually you understand the price of recruiting only after you’ve done it once. Or if you were able to handle that, the second and the third times are going to be dreadful, and the first foul you make in recruiting will bother you in your sleep.
Recruiting is an investment that can also be done by a contractor. Or actually it has already been done by a contractor, and I’ve never heard about contractor billing for gathering a team for its client. If one would, I’d change the contractor.
A startup usually develops its software step by step, and sometimes the time between the steps can take months. After the demo you start begging for money from investors and searching for initial commitments from clients. After the MVP there’s a (soft) launch trying to establish permanent clients and gather user experiences. It’s typical that up to a certain point, a startup should go all in trying to create the most impressive software they can.
At this point it is easy and usually necessary to set a contractor aside, because your bank statement is probably on the red before the next round of cash flow from investors and clients. But if you have hired a contractor, they will keep on clearing the (less important) backlog, waiting for a reimbursement for their work on payday.
Toni already referred to the productivity of an experienced contractor, but I’ll add to that. A development team in your own payroll will create their own processes, exploring new tools successfully and not so successfully. This may take weeks or even months and using services you have to pay for will add on to your already big pile of expenses. For example Headsted, with their visitor analytics ended up trying two costly services (+integrations) before doing it by themselves.
An alternative option would be to hire a contractor who would use the tools they have found effective, and share the access to its client. It would take about a couple hours and the rest of the time could be spent on what matters, the product.
A contractor naturally has, or should have, confidentiality but previous projects have usually taught something that can be shared. An international service with a monthly fee — how to deal with taxation? A mobile app with an emphasis on marketing — How to get it through AppStore reviews? What should a prototype be able to do in order to get a positive reaction from investors? How to write a good application letter to Tekes?
These are big questions, on which outsiders readily give advice. You can also get good advice from a contractor who has fallen into a pitfall with a previous client and now knows how to avoid them.
User behavior isn’t what we expected and now the focus should be changed from web to mobile. The chosen technology doesn’t scale. That feeling, when the whole product development team should be replaced because of a change in focus. It might be that even a contractor would have to change people in the development team, but it would come within the company instead of having to recruit externally.