For a year and a half, starting in early 2018, I iterated on a startup idea focused around recipes and meal planning. The app, which I called "Toast," began as a knowledge graph for recipes and food data, inspired by the limited 'migraine diet' options my wife was exploring. I wondered if, by analyzing the relationships of foods and recipes, we could create an app which could seamlessly discover recipes which met the constraints of various diets, or even substituted allowed foods for you.
Creating a Food Graph
With this initial idea in hand, I began building. I started with a GraphQL API served from an Elixir backend powered by a Postgres database. I quickly realized my approach wouldn't scale well for the kinds of relationship-focused logic I was interested in doing. Then I discovered graph databases - beginning with Neo4J, and eventually bouncing to OrientDB and then ArangoDB. The novel properties of graph databases propelled the idea even further than I'd originally dreamed, as connecting various points of data became trivial and intuitive. I rewrote the entire backend around the graph, shifting my stack to NodeJS, where I felt more comfortable.
Building a Progressive Web App
As I continued to explore options for the backend, I also refined my React abilities on the frontend. I adopted Material UI as a base component framework, played with branding and visual design, and converted my initial web app into a full-blown PWA, migrating the codebase to NextJS.
Although I've been a frontend-focused developer for the past 5 years, I was still able to learn and grow in a variety of new concepts, including server-side rendering for SEO, integrating with native device functionality like push notifications, animating content, and building truly responsive layouts across all device sizes.
Recipe Scanning and Ingredient Recognition
As my tinkering expanded into a full-fledged product, I also added a microservice which used a headless browser to "scan" recipe web pages, identifying ingredients and extracting relevant information like title, images, and cook times.
I also experimented with machine learning to try to create a model which could parse and extract foods, quantities and units from ingredient line items. Although my model wasn't as successful as I hoped, it did further my goal of continually learning new things.
Pivoting into a Content Platform
Gradually, the focus of the project shifted from data to the practical needs of meal planning from week to week. As I began to analyze the competition in this space, I knew I would need to think deeper to differentiate. I began to identify a major design problem in the way recipes currently work on the web: advertisements.
Internet ads have only become more intrusive over time, and the already (sometimes) stressful task of cooking is a bad environment to have a popup block the next instruction step. Yet, authors need advertisements as they hope to turn their food blog into a profitable business. There's a fundamental conflict of interests between the content creators and the users.
With this problem in mind, I envisioned a content platform for recipe authors which would allow them full control of branding, custom domain usage, and state-of-the-art features for free. The platform would mimic the Spotify model: users pay for subscriptions, and the profit is distributed to creators.
Ultimately, while I still believe in this business idea, I decided I'm not at the right place or time to start a business, and I have opted to put Toast on the shelf. I have no regrets about how much I learned--not only did I create and deploy a full suite of microservices and a full-fledged React app, but I also discovered a newfound affinity for graph databases and had the opportunity to iterate and refine a product I'm proud of.