As many of you have, hopefully, seen; our Game Wizard has been released to the wide world. Hopefully everyone is finding it as useful as the infographic which it is based on. I thought in the blog post I’d talk abit about the development process.
The data was actually very easy – we already created it for the infographic. Luckily, since we know the games well enough, creating the data for the infographic wasn’t that hard either – it was just a matter of taking the time to develop the various trees and making sure we didn’t double-up.
In this case, I went outside my usual developers for the site and used another 3rd party. I had been talking to them for a while now on a few other infographics and they had shown me the work they had done before so I figured they could do this well enough. The quote they provided was acceptable too, somewhat on the higher end of what we wanted to pay but decent. I decided not to try the oDesk / Freelance job site this time as I wanted a design that would be coded decently well and previous experience had shown that results from such sites were widely variable.
With this local design company, we had to go through a couple of design changes, mostly tweaks to the original design they sent us. The major issue came when they started trying to hook the design / information up to our sites database. Unfortunately, Magento is an extremely complicated e-commerce platform and while I had asked them their experience (and received assurances of competence), they actually had no idea what they were getting into. Instead of a 1 month delivery date, it took over 3 months with numerous back and forths. One last, major issue, was the huge delay in displaying products when an item was finally called. In the end, we decided to take the application as it stood.
Once we got the files, we took the final application and brought it to our usual developers (Collins Harper) and had them code in a cache system. It should be running properly now, with a cache set-up to run once a day to keep load-times for product pages nice and fast.
In the end, we got an app, but it wasn’t what we fully wanted. Unfortunately, the budget has now been spent.
The Final Product
So, you’ve seen the app/ It’s not what we wanted – the front-end is nice, but there are certain aspects of the backend that we really wished had been done.
- It’s not possible for us to integrate the design into the main site without ripping the entire code apart.
- There is no backend so all changes have to be hard-coded. This was definitely not part of our intention.
- The code is extremely simple for others to steal. Considering the work we’ve done, we aren’t particularly thrilled with that. It’s not something we asked for, but it’s something we need to think about next time.
Firstly, we should have made sure to get full clarification (and double-check again and again) when we agreed to the work. We thought we had an agreement on a few aspects of the business – like the backend CMS structure – but didn’t.
Secondly, double-check the credentials of the developers you use. In particular, the software / the systems that you use – make sure the developers you hire really do know how the system works and what can / can’t be done. If not, you’ll just add a lot of headache to the development.
Thirdly,if you have access to a developer you trust, work with them beforehand to develop a structure / developer brief. It’ll make your life a lot simpler and make the first issue much less of a contention.
Lastly, for me – I think I’ll go back to testing out outsourced developers for one-off projects like this (at least if CH is busy).