It’s 10:30 pm on a Thursday as I’m writing this and I’m stuck at Helensburgh train station for an hour because I didn’t plan exactly how I’d get back to Sutherland. To make matters worse, the air is thick with flying cockroaches and I’m hoping I don’t panic and throw the laptop away if one of them lands in my lap.
It’s got me thinking about the benefits of planning ahead and how a lot of us fail to use foresight when developing our first application. We tend not to think that far ahead even though we are trying to build something we’re hoping will work for years to come. As an app developer, I have seen many entrepreneurs who, from the start, just didn’t get the plan right.
In order to survive and remain relevant, at some point in time they ended up having to cut their losses and throw away everything that had already been built so that the application could be rebuilt from scratch. Usually this was because their application didn’t do what they wanted it to do. It may not have been flexible enough or had been built on the wrong technology. Or, worst of all, it may have been handed from one developer to another to another with each one not following their predecessor’s footsteps, resulting in a large inefficient mess of code.
This blog is for those who inevitably have to throw away everything and start over. Don’t beat yourself up over it – it’s not necessarily a bad thing and there are literally millions in the same position as you.
If you absolutely have to rebuild, and cannot work with what you have, here are a few tips:
#1 Rebuild as fast as possible
Even if you’re still fixing bugs on the current software or (God forbid!) trying to add enhancements, have someone working on the side building the new product for you. Every day you delay you are risking customers going to the competition because they either have features that your app doesn’t have, or they don’t have the bugs that your app has. Once they’ve turned their back it’s very hard to get them back onboard.
I am a perfect example of this. A while back I downloaded a chess app on Android that was built by a very big gaming company. It looked good but after I had installed it, I realised it lacked a very important feature I was after: it didn’t allow real-time multiplayer gaming. Because of this, I immediately uninstalled it and installed another one. This one looked a bit crappy – the interface wasn’t as good – but it did have real-time multiplayer gaming. Now, even if the original app develops that feature, I won’t download it because I’ve already grown fond of the app I’m using.
#2 Learn to let go
It’s very common to make mistakes when you’re starting a new business. Don’t get so attached to the current application that you can’t let go. Have a mindset that allows for growth and change and consider that there may be more to lose if you stick to the current application instead of scrapping it and starting again.
There’s a good analogy for this in the game of poker. Poker players are the best people to teach us how to count our losses and let go. In this card game, you have four chances to make a bid. Once you’ve made a bid, that bid belongs to the table. If you’ve overestimated your hand or underestimated your opponent’s hand and have already placed a bid, you are faced with a choice: either increase the stakes to bluff your opponent and risk losing all your chips, or cut your losses and fold and lose what’s on the table.
In the scenario of a nonfunctional app, there’s no bluffing. Your product either does or doesn’t do what it is supposed to do. It either gains more clients than it loses or vice versa. So if you know that continuing with that app means you will end up losing it all, the only choice is to let go and start again with a new product.
#3 Don’t repeat the same mistakes again
It might be an expensive lesson, but that old application is a lesson nonetheless. Whether you choose to learn from it or not determines the success and fate of the next app.
If you used an overseas developer and communication was an issue, use a local developer this time around. If you dealt with a developer who at some point in the process wasn’t up to the task, practice due diligence the next time by asking for references from existing or previous clients.
Don’t be stubborn and ignore advice from your developer. If you insisted on using a particular technology despite your developer’s opinion, you can’t blame the developer for the app not living up to your expectations. Try and let go a little and trust the developer to do what he is best at. If you clashed with a developer, don’t persist and try and make a bad situation better. It could cost you in the long run. Shop around next time and make sure you pick a developer you can rely on and whose opinion you trust.
#4 Don’t wait until it’s perfect.
Once you have the new app doing what the old app was capable of doing, do the migration straight away. If you wait until the new app has every awesome new feature you think your customers will love, you may never get it out there and onto the market. It’s possible that you might never run out of things to add to the product and that’s great – it means it will stay relevant for a long time. However, while you’re busy cramming every feature you can think of into your app, your potential customers are busy downloading your competitor’s app. Get your app on the market first and then fine-tune new features and introduce some in version 2 and more in version 3 and so on.
#5 Be involved
If you were not involved in the creation of the old app and ended up with a code that has no documentation or you have no idea what technology the developer used, then you need to be more involved this time. It doesn’t just make it easier if you want to switch developers if/when you need to, it also protects you in the unfortunate event that something happens to your developer. Who knows, your developer could get hit by a bus or close down the business and then you are stuck with a product that has no documentation.
Ask for documentation, mockups, flowcharts and entity diagrams. Make sure you’re on top of everything your code is doing. If you don’t have a tech partner you can rely on to know the code of the product inside out, then get a second opinion on the documents that the developer gave you.
And lastly,
#6 Don’t beat yourself up over it.
Once you have made the leap to start again, regardless of the damage your application and/or customers have suffered, don’t waste time blaming yourself (or anyone else) for what’s happened. Instead, understand that almost no one actually gets it right the first time. Treat it as a valuable lesson and make use of your newly acquired knowledge by putting your energy into building a revamped version of your app.
