Let’s team up.
When mistakes are your best weapon
Glenn Bull, founder and CEO of Skilitics, discussed how their failures helped improve the business at the recent Canterbury Tech Summit. This resonates with us at Custom D, when developing we believe the quicker we get it wrong, the quicker we can make it right.
Here are 3 quick pointers Skilitics have learnt from;
1. Plan for everything.
Plan for everything, then plan on everything going wrong or as Glenn put it 'Plan on your office going up in flames at least once a month and make sure you can recover from it quickly.'
Really consider your backup options and make sure that you can continue working even if you and your team are not able to connect to any of your hardware from the office. Backups should always be setup for as many redundancies as possible - consider including one that is in a different geological zone to yourself (having offsite backups that are not accessible due to something like an earthquake where your offsite backups are suddenly not accessible does not help.
Even with the best planning and preparation something can go wrong. After business growth necessitated a move to larger premises, they planned the move carefully, upgraded their insurance, made sure to have 3 tiers of backups (developers machines, offsite backups with 2 separate individuals and the servers themselves). The move was planned to run over 5 days (Friday till Tuesday) and the distance – literally around the corner. Everything seemed perfect.... sadly even with all that planning, moving day was scheduled for February 22nd, 2011. By the time the earthquake struck, the servers were already in the new building, along with both external backups!
2. Understand your target market.
Make sure you understand your target market and entry point correctly, The easiest way might not be the right way. A quick and cheap location does not make it the right place to start. Starting an ice selling business in Alaska simply because you can get a premises there at a good price does not help if you are needing to ship the ice all the way to Australia.
Glenn illustrated this point with another hurdle Skilitics faced when they entered into the US market. After some investigation they settled on San Fransisco – the timezone was friendly and there were the welcoming arms of NZ business groups to get things started. Luckily for him an associate asked him “Where are your clients based?” The majority were on the East Coast, so a quick rethink saw them settle in New York instead!
3. Know your limits.
Plan on your software being x10 more successful than your biggest hopes and build accordingly, coding it to handle what you expect it to get, only limits its capabilities and growth potential.
It's important to understand the limits and capabilities of your product.
Having signed up Walmart as a new customer, Skilitics where caught unprepared when Walmart decided they wanted to deploy to ALL of their stores on launch-day! At the time Skilitics were't able to cater to a deployment of that size and meant they had to rapidly rethink and refactor in order to scale to the extent required.
What we can take away:
1. Make sure you have at least 3 tiers of backup, with at least one of these in a different geographical area, that way even if your offices burn down along with the rest of the city, you can still get your backups and be back up and running. It's also a not a good idea to have 1 person holding both backups, a better solution there would have been to have a secondary person to hold the second backup at a seperate location while he was away.
2. Do your due diligence in making sure you are setting up in the correct area, - consider where your competitors & clients are. Also consider that you should plan according to growth requirements, it does not help for you to get a premises that is in a completely different timezone to the majority of your clients, nor one that caters only for your current team size as when your team increases in size - you will once again need to look for a new premises.
3. Consider the best case scenario for your software at all times - rather spend the initial time catering for a large adaption to using it initially and that way when you have a sudden growth spurt of users, your software can continue on. We have had a few learning steps on this as-well with our own developments, such as using an interval based ajax call to refresh data on a site being triggered once a minute per user on a site causing the server to get congested vs an upgrade to use node sockets which drastically improved performance and scalability.