Ankur Sharda explains how Scalingo helps his team develop Tuggle, the platform to power on-demand commerce, while he’s living between the US, Australia and Thailand and enjoying green curry.
What is Tuggle Doing
Tuggle is building the platform to power on-demand commerce. Currently consumers have the choice between buying in-store or buying online. However there’s a third option, which is to make an online purchase from a local retailer and have the product delivered from the local store.
In the future I see this as being the dominant form of commerce. However to make it really work someone has to build a platform that tells us what products are available where, and whether or not they are in-stock. This is what we’re doing. I’ve already tried partnering with on-demand delivery companies in Perth, and that’s their major headache - knowing what’s available and whether it’s in stock. Hence they are stuck mainly delivering from restaurants for the time being.
Alpha, Beta etc.
We’re going to do this in three stages. First we’ve built a simple search engine for local shops, we’ve done this for Australia at tuggle.com.au and the USA at tuggle.co. Since launching in early 2015 we’ve had 600k+ users. Although there are definite improvements we can make, we’ve know it works and is technically feasible, we just need to keep improving it.
Our process is highly automated, the retailer has to do almost nothing, I think this is the key to making something like this work. Otherwise it’s unlikely anyone would bother with such a small company. But now that we have something, it’s easier to get people’s attention.
Stage two is where things get interesting and this is beginning pretty much right now.
We’re now going to integrate with Point-of-Sale systems to provide real time stock inventory at local stores. Stage 1 and 2 work together. We can combine the “instore record” which has live availability and price data with the “rich record” that contains photos, images, descriptions and categorisation to provide a useful tool for shopping locally. Most people look at me blankly and ask, “how is this even possible”. It’s a good point, usually there’s no way to map between the rich record and the instore record. This is one of our key innovations, we can do this using a probabilistic algorithm, rather than requiring specific stock keeping unit (SKU) identifiers.
While we’ve validated at a small scale, to make it work in practice things are going to have to get serious. It’s time to build a bigger team and look for serious funding. So we’ve got fun times ahead.
Stage 3 is when true on-demand commerce becomes possible. Once we have the ability to search local stores and know what’s available now, then on-demand delivery companies like Uber or GoJek will be able to offer local products for sale through their own apps, powered by our APIs, and we’ll take a small cut off each one. But by embedding our service into their apps, gives us potentially huge distribution channels.
A Brief History of This
Prior to building Tuggle I worked in a field called eResearch. My job was to figure out how to make research data discoverable. In Australia there is a large national project run by the Australian National Data Service (ANDS), which seeks to build a repository of original research data. Part of the job was to extract data from research equipment and feed it into the ANDS repository. I started to get very interested in solving problems of taking many messy” data sources and combining them into a single clean and queryable stream of data. Using basic machine learning to match up metadata schema and semantic web ideas were all things I was experimenting with, but like with any such project it’s not wise to be too experimental. So I kept those ideas away for something exciting.
At the same time I was constantly needing to find where I could buy certain products, but couldn’t. So I would just delay or defer my purchase and I knew many people were in the same boat and retailers were suffering because of it. Online doesn’t suit me for a lot of things and offline was too difficult and time consuming. I was sure there had to be a better way that combined the two and the time I’d spent thinking about data issues suggested it could be done more easily than it at first seemed. I knew someone would eventually make it happen, and couldn’t think of a good reason why I shouldn’t be doing it.
When we break it down the Tuggle app is quite simple. It uses Java powered by Play Framework, that connects to a MongoDB database (also on Scalingo). Java is not most people’s first choice, and I can understand why, you do have to write a bit of extra code. I’ve also looked at Scala, and I suspect I might migrate to Scala and Play 2 at some point in the future. But for now I’m quite happy.
I was initially using Heroku with another cloud Mongo DB provider. But that was a bit expensive and restrictive and having two separate services lead to a lot of mental overhead. I was looking around for alternatives. Scalingo had the right pricing, flexible container sizes and the fact that MongoDB was natively part of the scalingo offering sealed the deal.
The things I’ve really like are the design of the dashboard UI - with Heroku I was forever clicking around waiting for it to load, Scalingo gives you what you need and loads faster. In particular being able to read logs in the browser lets me check things from a mobile phone. The new metrics panel also gives great insight into what’s actually happening, and the support is top notch. Whenever things go wrong I know I can get a solid answer very quickly. Leo’s (CTO) help has saved quite a bit of time, and now everything seems to just work, without having to think of it.
For someone like me, who can write code, but gets sweaty palms when he sees the word CHMOD this is exactly what I need.
When you combine price, performance, features, flexibility and support Scalingo is overall significantly better than the alternatives, and I can see it’s constantly improving which is great.