The hardest problem is not always technical execution.

Elm Food, my food and symptom tracking MVP

A little over a year ago I was reflecting on my career as a Software Engineer and came to the conclusion that I wanted some more control over what I worked on and wanted to feel the responsibility of being in full control of a project form ideation to delivery. I wasn’t in a position at my day job to walk in and demand full autonomy on a project of my choosing, and I don’t have the financial resources to quit my job unnecessarily to pursue my own project.

Given the constraints I decided to dedicate my free time after work and on weekends to a project that was personal to me.

I have a relatively sensitive stomach, which became even more sensitive over the previous summer. Faced with this, I started using various food tracking apps in the hope of drawing a correlation between what I ate and how my stomach felt.

Some of these apps even attempted to solve the exact problem I faced, but their analysis was deeply flawed, and their reports were full of false conclusions.

Being a Software Engineer I approached the problem the way I normally do. I exported the raw tracking data and built a python script that did simple statistical analysis and exported a spreadsheet with all the foods I’ve tracked and their correlation with good and bad stomach symptoms.

This first report brought me to the realization that the salads I started to eat on a daily basis in order to ease my stomach problems were directly correlated with an increase in stomach issues.

I cut out salad, my stomach improved slightly, and I was determined to explorer this further.

Next, I scoured the internet to find anyone else using the food and symptom tracking app I used. I found a woman willing to run my analysis on her data. She appreciated the spreadsheet I gave to her, but had some trouble deciphering it. Still there was some insightful information she found useful. A few more people were willing to share their exported data, but most struggled with exporting the data and emailing it to me.

There was a technical understanding boundary between me and collecting the data I needed. To continue with my MVP, I needed to build an easy to use app which would provide my algorithms with the data needed to generate reports. Those reports also needed to be presented in an easy to understand way; a spreadsheet with correlation stats was not going to work for most people.

I went down the road of learning Swift and iOS programming. All was going well but it was going to take me several months before I could deliver. These were new technologies to me.

I needed to leverage my core skillset and deliver this faster. I reconsidered my approach. What was I trying to build? A polished iOS app? No. I was trying to build an easy to use interface for logging food and symptoms, and for viewing reports. I could do this much faster by building a mobile website with an Azure cloud powered backend. These were skills I already had.

Elm Food landing page

Within a week I built out the tracking functionality of my application and released it as a beta. The reporting functionality was not complete, but I needed at least a week of tracked data before I could generate useful reports anyways.

On the report section of my application I put up a notice:

“Our algorithms require a week’s data before we can display your results.”

This gave me a week to complete the report processing service.

The reporting engine was complete six days later and on the seventh day I took down the notice and started allowing users to view their reports.

Early users were happy with application, but I struggled to find new users to onboard. Many were not tech savvy and still confused with its usage. One user wrote an angry email asking why my useless app was unable to tell her what foods would give her symptoms BEFORE ever trying them.

I’m a Software Engineer. I have not worked in healthcare. I have not worked extensively with non-tech savvy users. I made the mistake of thinking that if I could build something, the rest would figure itself out. Turns out engineering is not always the hardest problem.

Several users continued to use the application on a regular basis, but the numbers dwindled, and I shut it down three months after launch.

By no means did I consider it a failure, I learned quite a bit, but for now it sits in my GitHub repository gathering dust.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.