IIn n mid-2013, I was a software engineering student with a lot of ideas, a lot of energy, but not a lot of experience. I began teaching myself how to make iOS apps and had released a few bug-laden apps that helped solidify a lot of the concepts and practices relevant to developing on a mobile device. The main idea behind The Sugar App is a simple one, but one that hadn’t been pursued by anyone at the time. Open the app, search the menu for bodega-style snacks, pay, and have the items instantly delivered to you by a courier nearby. 5-years later and this style of app exists in any form you can imagine. Uber Eats would be the closest example to the bigger, long-term vision of this sort of app - although the hyperlocal facet always appealed to me and is something that Uber couldn’t attempt operating at the scale that they do. I’m extremely proud of the level of fit and finish we were able to capture during this products release. It laid the groundwork for a lot of my understanding of how to create a seamless customer and courier app built into one, utilizing the same infrastructure across web and mobile, and also was the genesis of SMessenger as we quickly realized that the most important part of this app was the messaging system between the courier and the customer.

To be honest, the genesis of the sugar app came about during a bout of intense studying in a crowded library. Once you get into a work-zone, where you seem to absorb 10 times more information and appear to be 10 times more productive, you don’t ever want to leave it. Not to go to the washroom, not to go get a snack, not to mindlessly waste time on social media. What happens when you do want the kick of caffeine to hit overdrive, or a little sugar therapy to extend your study session? You could pack up your stuff, head to the nearest snack shop, and buy a severely overpriced bag of chips from the university. Okay, now you’re satiated and ready to head back to your work-zone and pick up where you left off - except the library is still over-crowded and you can’t find a place to work. Anyways, you get the idea - and thus this simple idea becomes useful.

As with all ideas - it seems easy enough at first. A mobile app for the customers, a server to facilitate orders and messages, a messaging interface, and there you go - a prototype ready for market validation. I got started with this framework in mind and began designing the interface for the mobile app - and whether out of inexperience or a philosophical lean towards simplicity this is the first and almost final iteration of what the app would look like.


It was simple - a list of the treats currently in stock, a cart, and a checkout option. Again, I’m stressing the fact that it was simple because this simplicity ultimately led me to add more features and elements to the ecosystem without thinking about the consequences - and my first introduction to the well-known problem of feature creep. Anyways, I spun up a quick server on AWS - created the single endpoint the app would communicate with and created the list of treats that I could update through the command line mysql interface. I was almost done - I just had to create the messaging interface (Again I lean towards simplicity but ultimately value the level of control provided with custom solutions).

A brief aside - I had dabbled with the Android app studio a couple months earlier while working on the Watchville app - and decided that my skills were good enough to create the native Android version of the app simultaneously. To an extent I was right at the time - almost 30% of the downloads (yet only 5% of the total orders) were from the Android ecosystem - but this exercise was a forum for which I was learning - not necessarily building a business. So I spent a weekend mimicking the design and the elements from the iOS app into the Android app.

Now it was time to create the messaging interface. This was the most difficult part of creating the ecosystem - and the base for which I built SMessenger on.

Now it was time to create the messaging interface. This was the most difficult part of creating the ecosystem - and the base for which I built SMessenger on. I began by associating each mobile device installation with a unique identifier - there were no user accounts as the whole app experience was meant to be as seamless as possible. Each user would only have one chat room so instead of creating a mysql table to store the messages each customer installation would generate a text file where the chat would be stored. The app didn’t require a highly available and optimized chat backend. In perspective - for the scale the app would reach - the text file method worked perfectly. It sped up development time, allowed for multiple couriers to message one customer should they order multiple times - all to say a good choice.

I, along with everyone else, have always loved the iMessage chat bubble interface. Whether through constant advertising or purely good design, this was the interface I wanted for the app experience. Implementing this cross platform was difficult to say the least, but unfortunately I was determined for this to be part of the interface. I say it was difficult, but that’s just because it required opening up Photoshop and creating the chat bubble variations for both sending and receiving - and designing like this was time consuming, repetitive, and annoying.

Next on the list was facilitating the order. Again, this element also fell victim to feature creep - as I wanted the customers to only select, pay, and receive their order. Preferably I didn’t even want them to facilitate a conversation with the courier, as this communication would indicate friction. So I decided to add one more element to the ordering process - confirming the customers location on campus and adding the ability to add a comment or note to the order. This feature also doubled as a verification for delivery radius - minimizing undeliverable orders.

With all the pieces in place, I began submitting the apps to their app stores - and waited for their approvals. In the meantime we bought some product in bulk (Costco, Walmart) - increasing our low margins - and worked on some marketing tactics. We printed flyers, postcards, plastered campus with them, and painted the the campus advertising board with the apps colours and logo.

We gathered over 2000 downloads within the first weekend.

When the app hit the app store we began our marketing and gathered over 2000 downloads within the first weekend. It was surreal - students using the app, ordering products, couriers delivering around campus - and it was my first taste of what it felt like creating something from nothing. A magical weekend, but ultimately not feasible in the long run.

There were 3 main problems with scaling. We needed full time couriers (Me, Ben, and Cole) - we needed products (a place to store our products), and we needed profits. Given some monetary investment in the idea - we entertained joining the campus incubator - the app could have expanded beyond our university campus and then, given enough scale would have returned a generous profit. At the time I believed this would be something that would eventually be tackled, and fast forward 6 years and it has been - by companies with huge war-chests of money, and an uncanny ability to lose it every day. This idea is still one that brings joy, optimism, and a sense of possibility whenever I think about it.