This is an open story submitted by the founder of Padel Tennis Pro. We’re always looking for stories like this: ping us at [email protected] if you have them.
Join our mailing list to learn how to build as he has.
—————————————————————————
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?
Padel Tennis Pro with code(love)
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. They 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, lessons 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. They will 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 some will leverage this fact. They will refuse to continue on a fixed price basis, and request that you switch to a pay per hour project— this happened to me three times with three separate developers throughout the course of this 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
A company says it is based in a certain location, or even has an office in that location, but beware: it 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 of actually building your mobile application 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.
Maidan with code(love)
#3: Aim for a MVP
A common theme for those planning to outsource an app is to plan out a grand 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 mobile application 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 where I knew about the technical process behind creating a mobile game. 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 $35/hr, 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.
Learn code with code(love)
There is no protection offered by the freelancing websites for outsourcers using an hourly pay method. If the developer spends his time badly building your mobile application, 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 clearly had its up and downs and was a great learning experience, it also took a lot more time and resources than I had expected. A rule of thumb that I now advocate is to triple your initial cost expectations and timeline and then halve the number of features that you want when you want to build a mobile application. That will provide a more accurate picture of how the project will likely pan out!
You can find the game here: www.georiot.co/padel
