Sugarmate

Sugarmate’s Founder Turns His Side Project into a Business on Heroku

Heroku’s managed platform, data services, and add-ons enable Sugarmate to serve thousands with a lean team.

Around 30 million people worldwide live with type 1 diabetes. For many, managing the condition means taking finger-prick blood tests several times each day. There is an alternative, however. Continuous glucose monitors measure sugar levels automatically without drawing blood, opening up new possibilities for how people manage and live with diabetes.

That’s where Sugarmate comes in. Created by serial entrepreneur Josh Juster to help manage his own condition, the Sugarmate platform combines a Heroku back-end with web, mobile, and smart speaker apps to provide life-changing alerts and analysis for people living with diabetes. And, thanks to Heroku, that personal project has turned into a business serving thousands worldwide.

An Apple Watch, iPhone, iPad, and laptop showing the Sugarmate app

Heroku was the obvious platform for building Sugarmate

Josh Juster is no stranger to building thriving businesses on Heroku. Over the past few years, Josh has used Heroku to build and launch apps in areas as diverse as home automation, video editing, and fashion. Thanks to the success Heroku has helped him achieve in his business life, he naturally turns to the platform when he has an idea for a new personal project.

Sugarmate started just like that. Switching from finger prick testing to using a continuous glucose monitor gave Josh an insight into how that new stream of near real-time data could change his life.

First up, he wanted to check his most recent glucose reading by glancing at his Apple Watch. So, he built a simple Rails app, pushed it to Heroku, and then shared it with the broader diabetes community. People were excited and Sugarmate was born.

The founder’s dilemma: build features or grow the userbase?

Josh’s vision went beyond the Apple Watch. He wanted to make sure users always had access to their readings, no matter where they were or what they were doing. So he built Sugarmate on multiple platforms, including iOS, Mac OS and the web. Sugarmate users can ask Alexa for their latest reading, have it displayed inside their car, or even have their home lighting turn on or change color in response to changes in their sugar levels. One feature that Josh felt particularly strongly about was one that he named the “Below Normal Call.”

For many people with diabetes, night can be an anxious time. Even when someone is asleep, their blood sugar level can become dangerously low. Josh realized that Sugarmate could use its constant stream of readings to wake the user with a phone call whenever their blood glucose levels were outside the safe range. Introducing such alerts changed Josh’s level of responsibility as an app creator. If users were to rely on Sugarmate to feel safe overnight, then the platform had to be robust and scalable.

At this stage, many startups face a dilemma: focus on operations or features? When their app runs on bare bones virtual machines, this can be a tough decision. If the team spends their time creating new features, then they’re forced to curb user growth so as not to expose all the inefficiencies and quick-fixes in their code. Even then, they must consider the ops impact that any new features introduce. If they choose to focus on ops, they can prepare their app for growth, but at the expense of allowing the product itself to stagnate.

Thanks to Heroku, the Sugarmate team could avoid this dilemma altogether. By deploying their app to Heroku, they could use platform tools to easily scale their app’s dynos vertically and horizontally without needing to image VMs, apply patches, or suffer early morning pager alerts. Heroku freed the team from the day-to-day ops burden of managing Sugarmate’s servers and infrastructure, giving them time to develop the new features that would take Sugarmate from side project to successful business.

Managing the platform as a small team has been challenging, but fun. Running on Heroku has made it totally doable. Josh Juster, Founder, Sugarmate

Postgres with MemCachier and Redis worked better than third-party NoSQL

Like many people dealing with high volumes of inbound data, Josh considered non-traditional data stores to replace PostgreSQL. However, after experimenting with NoSQL, the team switched back to Heroku Postgres. They found that not only were they able to easily scale their Postgres database, but it cost less to run than the NoSQL alternatives.

We spent a lot of time experimenting with NoSQL solutions outside of Heroku, but they ultimately weren’t the right choice. We found that Heroku Postgres was more performant and offered better value for Sugarmate’s core use cases. Josh Juster, Founder, Sugarmate

The solution to the problem of ever-increasing data ingest lay in Heroku's managed data services and ecosystem of third-party Heroku Add-ons. Today, Sugarmate's Ruby on Rails backend runs on 30 Heroku Dynos, with Heroku Postgres as the primary database.

Sitting between the dynos and the Heroku Postgres cluster are both Redis and Memcached. The Sugarmate team uses the MemCachier add-on to manage and scale their Memcached cluster automatically, and they’re in the process of moving from a self-managed Redis instance to Heroku Data for Redis.

A phone showing the Sugarmate app with a graph and calendar

Hassle-free scaling with Heroku Add-ons

When it comes to compute power, the Sugarmate team has manually increased the number of dynos as Sugarmate has become more popular over time. Keeping on top of the demand has been straightforward thanks to a number of monitoring tools, including Heroku Add-ons Librato, Honeybadger, and New Relic.

Redis plays a crucial role in handling inbound data. As readings come in, Sugarmate adds them to a Redis queue, which is managed by the Ruby job scheduler, Sidekiq. Sidekiq then fires off the process of sending alerts, updating statistics in Sugarmate’s database, and pushing updates to the user’s various devices.

The power needed to process readings is relatively predictable, meaning that the team can manage their app’s dynos manually as new users join. However, some scenarios require dedicated processing resources. For example, when a user requests a report in the app, Sugarmate uses a third-party tool called HireFire to automatically deploy a new Heroku Dyno specifically to process that report. Once the report is delivered, the dyno shuts back down.

Sugarmate runs entirely on Heroku. What's great about that is it just scales really well. As the user base grows, we can add more and more dynos to handle the growth with little additional effort. Josh Juster, Founder, Sugarmate

With Heroku, Sugarmate has grown from side project to business

Building Sugarmate on Heroku has allowed Josh to turn a personal project into a business venture that, so far, has handled billions of blood sugar readings and is improving the lives of thousands of people living with diabetes. Heroku’s products and tools have given Josh the freedom to develop new features for his app and take in ever more data, all as a lean team and without external investment. The next step for Josh is to monetize Sugarmate by offering a premium, paid service.

Heroku makes it easy to manage app operations. As the app grows and Sugarmate needs to scale, I know that we’re in good hands. That’s why I intend on using Heroku for the long-haul. Josh Juster, Founder, Sugarmate


Read more about Josh’s experience and the Sugarmate app on the Heroku blog: Improving the Lives of People Living with Diabetes.


Inside Sugarmate on Heroku

At the heart of Sugarmate is a Ruby on Rails app, deployed on 30 Heroku Dynos and relying on a partitioned Heroku Postgres cluster. For autoscaling dynos, Sugarmate uses the third-party service, HireFire. When it comes to data caching, Sugarmate uses both Memcached, autoscaled with the Heroku Add-on Memcachier, and is in the process of porting its Redis instance to Heroku Data for Redis. For monitoring, Sugarmate uses a mixture of Heroku Add-ons, such as New Relic, Librato, and Honeybadger.