Like most start-ups, there comes a time when important decisions are made on the choice of technologies for product development. Where there are a plethora of options, the straight rule of thumb is to go with whatever the team collectively is familiar with. However, if a team is yet to be formed, it makes things interesting. Well, it makes the journey that much more rewarding!
We went through the same hair-splitting discussions and eye-drenching searches, like most start-ups, to make sense of what is out there and what’s best for us now and in the future. Here’s a brief summary of our experience and I hope it might be of some help if you are on the same page.
- The very first step for us was to define exactly how our software would be used and the people who would use it. This was perhaps the most difficult step as we had to drag ourselves away from searching the web for inspiration. Best advice here is to shut yourself in a room with a ream of white sheets and a dozen pencils and think about how your ultimate end-users would use your software, how would they prefer the layout to be, what colours would inspire them and how do we intuitively guide them to complete a task and so on.
- Once we had a clear idea of our end users and how they might like to use our software, we set about creating mock-ups of how our software application might look and what the user experience would be (well, it would serve you best if you hire a decent user interface designer to convert your crude MS paint screens and hand drawings to something pretty. You could do it all yourself but a second pair of trained eyes can add finesse/critique to your thoughts).
- Then we set about writing detailed use cases and wireframes to break down the user journey for each screen and each task. Making it ultra-simple was our philosophy, everything users see on the screen had to have a purpose and they should need no more than a few clicks to complete a task. We wanted to do away with exhaustive menus and instead have Apple like workflows to improve user experience.
- Once we had visualised how our application would look and work, only at this point did the million dollar question kick in: “what technologies should we use to build this stuff?” The choice was aplenty to say the least.
- We laid out the various technology stacks (User Interface, Server Side, Frameworks, IDE, Plugins, Database etc) and made contacts with friends and experts in this field (Q&A sites like www.stackoverflow.com was extremely useful in our quest to find relevant answers). The key take-away was that we could achieve our application development in any of the technology stacks.
- We figured we couldn’t do it alone. Looking at who could help us, we further figured, quite early on, either there weren’t enough people with the experience we were looking for or there were too many after big money that we could, as a start-up, ill afford. Some just plainly rejected us as we were tiny with no pedigree (I mean there were just 2 people and less than a year old and no office space). While this made the job a bit tricky it also opened our eyes to a particular technology that was quite employer friendly (I mean we didn’t have any difficulty in finding good talent in this part of the world).
- Once we got on with bringing together a team of like-minded people, we read more on the preferred technology stack; of its community, features and frameworks that we could leverage. Eventually we narrowed down on a set of technologies that we thought was a good fit for our current and future developments. The team was already well versed with most of the technologies and it was pretty much getting the design translated into code from there on.
- There will, I am sure, from time to time, be suggestions to change technologies or frameworks mid-way. Either by experts who care for your work or by cowboys who don’t understand the way you look at the world. Unless there is a clear benefit over what has already been chosen, be stern to park it. Once a technology is chosen, ruthless execution should be the order of the day.
Choosing technologies is probably not exact science. There is an element of intuition to it. Perhaps the important lesson we learned was to know our users and their preferences so as to make the technology work for us as intended. Looking back I guess we could have succeeded in any of the technologies. Looking to the future, however, we think we made the best decision.
