Moving Travllr from concept to reality

Over the past few months, we've been busy researching market opportunity around Travllr. Testing our proposition built around and working toward finding a good market fit.

How far to take research?

Whilst the process has been a great success and there's been all round positive feedback, we've found that interviewing people with only a concept didn't give us the clear results we were hoping for. The vast majority of people said they would use the product, but in reality, Travllr customers will experience friction through having to adopt a new behavioural change of not using a travel guide and saving to Travllr. 

We've reached an impasse. With our current path not delivering the information and insights we need, do we invest more time into creating a higher fidelity prototype, and money into wider research? Or, do we start work on delivering an MVP to market. Then test and iterate on insights from actual customer use.

In contrast to conventional Lean Startup thinking, we've decided to invest our time into taking the product into build. We believe having an actual product that customers can truly interact with will provide far higher quality insights, allow us to move forward faster, and provide an opportunity to search for funding based on real business learnings. This stacks up considerably when you factor in that we have the necessary skills in-house to do this at no cost, just time.

Engineering through Lean

Whilst moving into build requires a different skill set and process, it's critical we maintain a lean approach to all functions. If we over invest in heavy duty, new technologies, best suited to a full-scale product solution. We'll be bogged down in upskilling and learning. What we want now is to use the skills and technologies that we know (and love!). Keeping things quick and simple, then only refining and improving when there's a clear business need.

Our guiding principles for technology selection are deliberately slim. Anything we choose to use needs to fulfil these basic principles:

  1. Be familiar
  2. Be proven
  3. Be secure
  4. Enable speed (for the team we have now)

Our final technology stack

After a wide review, we've reached a decision on our beta technology stack. It combines familiar languages with innovative approaches and will hopefully deliver rapid results. 

  1. Cloud hosting - Digital Ocean
  2. Cloud management - Laravel Forge
  3. REST API - Laravel Lumen PHP framework
  4. Codeception and Selenium - Automated unit and browser testing 
  5. Browser extension - Standard HTML, CSS and Javascript
  6. Website - React
  7. iOS mobile application - React Native

We chose Laravel Lumen and Forge as they offer huge community support, a low learning curve, and, Lumen, in particular, is designed for lean, rapid development.

Digital Ocean will provide hosting based on stability and scalability, but they've also introduced a London region, which will provide peak performance for our initial beta target market in and around London.

Facebook's React and React Native frameworks allow the use of one language for all UI development, Javascript. React Native has a number of aspects to it that aids rapid mobile development.

Strategically, this may or may not be the solution for +3 years but for our immediate needs and first-year ambitions, it prevents us from wasting time learning new languages and provides a platform to quickly scale the team with an easy-to-hire skillset.