Padel Tennis Pro was intended to be a cheap, three-month endeavor to build a new mobile game. With gameplay mechanics not totally dissimilar to the early 2000s classic ‘Curveball’ – how hard could it be?
Nineteen months, five fired developers, one rushed Kickstarter campaign, one AppStore rejection, many sleepless nights and an international political crisis later…. and… it’s finally ready.
For the growing number of people who are planning to outsource the development of an app to a freelancer, let this be a warning. It is not as easy as it seems. Companies on freelancing websites such as elance and oDesk regularly tout example portfolios, which in reality they had nothing to do with and make promises which they certainly don’t intend to keep. My first set of developers did precisely this; laying shoddy foundations that would continue to plague the project almost two years later.
Don’t be put off though. Plan your project carefully and with the right team, it could well become that huge success that you were hoping for. Here are some lessons that should help you along that dangerous path to achieving your grand vision. They are lessons that I have learned the hard way:
#1: Fixed Price Contracts: A fixed price project is not anywhere near as safe as it may seem. In principle this seems like a great deal: you put funds in escrow and only release them when the code reaches certain milestones. However, there is serious information asymmetry at work here and developers will frequently refuse to continue until you release early milestones and insist that they have done work “behind the scenes” that you can’t see yet. They will assure you that it is hidden in existing code. Obviously, the disputed work hasn’t been done, but by the time you find out, it is too late! As the project continues to progress the power balance swings in their favour as your committed investment increases and their knowledge of the code becomes a unique asset. Developers are aware of this and will also just refuse to continue and request that you switch to a pay per hour project, which happened to me three times with three separate developers during this particular project. At this stage, you need to decide if the cost of paying someone else to get up to speed with your existing source code will be less than the additional likely cost of an hourly job. Not an easy decision to make.
#2: Sub-outsourcing: Just because a company says it is based in a certain location, or even has an office in that location, does not mean that your work will actually be carried out in that location. Twice during the course of this project the company that I was paying to complete the app were little more than middlemen. They subsequently outsource the work again to freelancers that they don’t actually employ, usually based in other countries where the cost is lower. They take their slice of the fee, the outsourcing website takes a fee and you are left unsure who is actually doing your work, their level of skill and even in what legal jurisdiction they are operating in. Without delving into exact detail, being subjected to several layers of outsourcing meant that my project crossed the Russian/Ukrainian border at a time of extreme political tension between the two countries. It was an interesting scenario and not one I would wish upon anyone else.
#3: Aim for a MVP: A common theme for those planning to outsource an app is to envisage a grand, feature rich, complete with bells and whistles end-product. This is time consuming and expensive. Instead, I would recommend starting out with a clear vision of your minimum viable product (MVP) and aiming for that. This will allow you to get it out to market faster and cheaper, ultimately checking whether this product is something that the market actually wants. If there is demand, you can add features at a later date.
#4: Learn some code: Having already released many apps, some of which I had made entirely myself, I was in a position of some knowledge on the process of creating an app. With that said, my knowledge of the game engine being used to create Padel Tennis Pro was next to zero. At one point, one freelancer spent three days, at a $35p/h rate, adding a simple animated shark fin to the background of one of the levels. Had I known more code, I would have noticed he was ripping me off. Had I known more I also would have been able to point out to him that the shark fin would also be moving in the wrong direction without having to wait three days to test the build to find that out. There is no protection offered by the freelancing websites for outsourcers using an hourly pay method. If the developer spends his time badly, that is your problem and you need to foot the bill. You will note that the backwards shark fin did not end up making it into Padel Tennis Pro v1.0 🙂
Overall, while the project was a great learning experience, it also consumed far more time and resources than I had expected. A rule of thumb–mentioned by one of our MBA entrepreneurship lecturer—and which I have subsequently adopted is: triple your initial cost expectations and your timeline and then half the number of features that you want. Applying this logic will provide a more accurate picture of how the project will likely pan out and can set your expectations at a more appropriate level.
You can find the game here:
Sam