A Retrospective on MacroFuel

The second startup that I have worked on, MacroFuel Food, closed its doors in April 2017.  My experience with MacroFuel built upon my learnings from my first startup, daapr with additional lessons and new situations that ultimately evolved my understandings of entrepreneurship and of products.  I worked on this startup with Gus Rietsema (CEO), Max Tave (CMO) and Charles Lee (CSO).

About MacroFuel

MacroFuel is a complete meal replacement in drinkable form.  It is made with real food ingredients and has the of the nutrients of a well-balanced meal.  It comes in a powdered form that is quick and simple to make, just mix the powder in ice-cold water, and you have a healthy, on-the-go meal in about 30 seconds.

MacroFuel started in a Cornell University Entrepreneurship class that Gus and Max took at the same time.  The class involved coming up with a company idea, then building a business plan around it.  MacroFuel came into existence as a response to companies like Soylent who had a good idea with meal replacements but had unfamiliar ingredients (like Methylsulfonylmethane) along with poor branding and multiple recalls.  Building the business plan in class showed Gus and Max how making a meal replacement company actually was not as far-fetched as one might think.

The idea formed into a business plan, then into a real formula, then into a Kickstarter campaign, and finally into an online storefront.

I joined the company as it was preparing for the Kickstarter campaign.  I worked to help build out the web presence for the campaign, and create the technology vision for MacroFuel post-Kickstarter.

MacroFuel was a very different venture for me than daapr.  Daapr was a social media platform, and the entire focus was on technology.  MacroFuel was a food product, and the company focus was primarily food and secondarily technology.  We believed that technology could be the factor that gave us an edge against our competitors like Soylent, Ambronite, and Huel, so that is where I invested the bulk of my time and energy.

Technology Vision

From a technology perspective, the vision was to create a seamless experience between the food product and technology experience in order to create an ecosystem that surrounded MacroFuel.  The technology vision looked to include the following experiences: Company Website, Storefront, Administration Dashboard, Company Blog, and an Engagement Platform. 

Company Website

This vision first started with a company website.  The website was meant to describe the product, be an information hub for content that is related to the product, and be a marketing centerpiece.  When customers, suppliers, and investors wanted to know more about MacroFuel, the company website was meant to be the answer hub for their needs.  The site also was the company's first means of reaching out to customers.  It pushed for visitors to subscribe to our newsletter and pushed discounts on first purchases to encourage sign-ups and purchasing.

Storefront

The Storefront continued the technology vision by presenting a simple, direct method for purchasing MacroFuel.  The Storefront was optimized for mobile and desktop shopping in order to allow for purchases on all devices.  It focused on putting product imagery in the forefront to create a visually engaging experience.  Bulk discounts were also highlighted in order to encourage greater purchasing quantities for the potential savings.  Checkout was broken down into simple steps to allow for streamlined purchases.  PayPal integration also allowed for adding confidence for customers who were wary of a small, new brand.  Finally, a profile page allowed users to check past orders, tracking shipments, and share referral codes.  The referral process automatically applied a 20% discount for users at checkout who referred 2 new customers to MacroFuel.

Administration Dashboard

The Administration Dashboard allowed the team to track orders in the pipeline.  Email notifications were automatically generated to the team when an order was placed.  The Administration Dashboard also allowed for simple exportation of unfulfilled orders into CSV files for our storage and shipping provider Shotput to consume for fulfillment.  The dashboard also allowed for various filters and searches based on an order's attributes.  Finally, the dashboard sent automated emails to customers with shipping information once Shotput returned tracking information.

Company Blog

The Company Blog added to the technology vision by creating more MacroFuel content for customers to consume.  The blog added new material to disseminate to customers and influencers to learn more about MacroFuel.  It also fueled the company's Search Engine Optimization (SEO) strategy to acquire more traffic and potential customers through keyword strategizing.

Engagement Platform

Unfortunately, the Engagement Platform never did see the light of day.  The vision for this product was to tie everything together and to help create an incentive for people to post on social media about MacroFuel.  I had envisioned a feed in which customers could see and share MacroFuel content from every customer.  The idea behind it was to build a rewards program that surrounded purchasing and sharing MacroFuel.  Social media posts, referrals, and purchases would all earn points.  (The referral program did exist through coupon codes, but the concept of points had not been created yet.)  My goal was to help foster a community surrounding MacroFuel and turn our most avid customers into our top marketing agents.  If we could incentivize and reward our customers for promoting MacroFuel, we could ideally have very cheap and successful marketing.  The dream behind the Engagement Platform is the biggest reason why I custom built the Storefront and Company Website.  I wanted to be able to create a shared user account that had a unified source of customer data across experiences so that we could always make our customers feel welcomed and in a single cohesive experience.

The Infrastructure

I was the sole designer and developer on MacroFuel (I did the primary design work with input from Gus on some user interface tweaks).  The infrastructure for MacroFuel built upon my learnings from daapr.  I started with Amazon Web Services (AWS) from the start to avoid potential scaling issues and because we had free AWS credits.  I also used Compose for our database to avoid having to worry about backups and scaling, and our domain name was through Namecheap.

Company Website and Company Blog

The Company Website and Company Blog were written in Ruby on Rails in order to utilize server-side rendering necessary for Google to crawl the site.  The technologies that I used for the other applications were not SEO-friendly because they were all JavaScript based and rendered on the client-side.

All images and other assets were hosted on Amazon S3 and served over Amazon CloudFront.  Traffic was routed through Amazon ELB and server management and deployment was done through Amazon OpsWorks.  The application was hosted on Amazon EC2 and the database was on Amazon RDS using PostgreSQL.

Storefront, Administration Dashboard, and Engagement Platform

The Storefront, Administration Dashboard, and planned Engagement Platform were written in Meteor and React hosted on a combination of Amazon Web Services and Compose.  The configuration was almost identical to the Rails applications, with the notable exception that the database was using MongoDB (the default for Meteor) so I flipped out Amazon RDS with Compose.  I chose Meteor and React so that I could build a single application that can work across devices.  Meteor has a tight integration with Cordova, which I was going to use to port the MacroFuel Technology Experiences into applications for phones.  Later, I planned to use React Native to have a native experience.  I also wanted to leverage Meteor's WebSocket technology with live updates for the Engagement Platform.

Each application had its own subdomain, Load Balancer, and Application Server Cluster, but all applications sourced the same database.  This had the potential to be a bottleneck later down the road, but I used this configuration for a few reasons:

1. Having all applications use the same database allowed me to more easily create shared user accounts across applications.
2. MongoDB is a NoSQL database; it can scale horizontally, so the issues that one might face with many applications reading from a SQL database were not as drastic.
3. Compose would take the burden of scaling a cluster for me (they do both vertical and horizontal scaling for their Elastic Deployments). 

Learnings

Applied Learnings

I recently wrote about my first startup, daapr, and I directly applied these specific learnings from daapr into MacroFuel:

1. Build mobile first.  Although we did not have a native app experience, the entire platform was built with phones in mind.  The design was mobile-first, and the technologies were chosen to easily get onto phones as an application.
2. Know every part of the [technology] product.  This was particularly easy because I built everything by myself, but I made sure not to leave anything to chance like I had originally done with daapr.
3. Don't be afraid to try new things.  With daapr, I originally stayed away from technologies and problems that I was unfamiliar with.  Compared with daapr, I had a better idea of what I was doing, but I made sure to make the best decisions for the technology product and not let unfamiliarity hold me back.
4. Keep the team small.  The core MacroFuel team was only ever 4 people.  We at one point had more people contributing; however, we made sure to prioritize our energy and efforts on the company and product as opposed to scaling the team when the company did not need it.

Gained Experiences

MacroFuel was about selling a product.  This was both similar and different from daapr.

MacroFuel and daapr were similar in that I was selling an idea and a vision about a product.  They both required convincing customers and users to look at how they approached an activity differently.  For daapr, it was changing the way users browsed and shared article/video content.  For MacroFuel, it was changing the way customers approached finding and consuming quick meals.  The biggest difference between these companies, was with daapr I only ever asked someone to sign-up and play with an app, but with MacroFuel, I was asking for people to give us their money.  

Asking for money was a bit anxiety-provoking.  This first started with the Kickstarter campaign.  I felt uncomfortable at first; even felt guilty at times.  I was asking people to invest their hard-earned money into me, an idea, and a company that was unproven and in unchartered territory.  I was even asking people whom I knew did not have that much money to take a risk, and try our product.  In a broader perspective, the ask I made was small, maybe $20-50 dollars, which is nothing compared with potentially asking an investor to put in thousands (or millions) of dollars.  Raising money was a good experience for me to be exposed to and hone.

Asking for money continued past the Kickstarter.  I still had to help drive sales to the e-commerce store that I built.  As time went on, I became more comfortable with this notion but is not something that came easily.

MacroFuel also helped me to gain experience actually making money at a startup.  Daapr was a fledgling social media company with the goal to acquire a ton of users, then monetize later. With MacroFuel, the company had to monetize now. Gaining a background of actually driving revenue from the get-go was a big change for me and a great step forward in my entrepreneurial ambitions.

Working on MacroFuel also gave me a product outside of my first personal website that I owned the end-to-end experience in all aspects.  I owned the designs, the engineering, the analytics, the architecture, the infrastructure, and the product in every capacity.

Different Approaches

As I reflect on my experience with MacroFuel, there are a lot of things that I did way better than I did with daapr; however, I have found several ways that I would have done this startup differently.

1. I would be more heavily involved in the business.  I leaned on my partners to write, edit and update the business plan.  If I were to do it again, I would get myself more involved in this process.  Moreover, I contributed to the plan at a high level, gave feedback on it, and weighed in on opportunities it presented; however, I did not look at the financial models in-depth, I did not contribute to the accounting, and I did not participate in the opportunity assessment of the market we were looking at.
2. I would completely re-prioritize the steps I took in the technology vision.  I focused a lot on the future of the company, like how we scale our stack and increase engagement.  The issue was, that we needed a customer base to start with before anything I built had significant returns.  I put my technological ambitions first over the company needs.  Realistically, the company did not need a custom built store and website to get started.  My original gut feeling had been to use something off-the-shelf like Squarespace or Shopify, but I became so wrapped up in the technology vision that I lost sight of the fact that the technology did not mean anything at our infant stage.  If I were to do it again, I would use Squarespace or Shopify for the site and store, and then focus all of my energy on Search Engine Optimization.  What the company needed was to be able to find customers across the internet on a minimal marketing budget.  I would have used research and data to understand what kind of content we should generate for our target customer segments, then find the ideal sources to get links from to drive traffic to the site.  The company needed more traffic and customers, not bold technology solutions.
3. I would more clearly identify our target customer within our team.  We had originally wanted to be used by everyday folks, then young professionals, then targeted more fit individuals, then bodybuilders, then Obstacle Course Race athletes (like Tough Mudder), and so on and so forth.  I personally was really in love with the young professionals demographic, but the reality was that we were not making enough sales there.  Each member of the team had a different vision of who the target demographic was.  It made our branding weaker, and our marketing efforts less effective.  I would do a more thorough opportunity assessment at the start to best understand whom we should target.  This would mean finding any data possible that could help point us in the right direction and even working to get surveys in front of more people to better understand what our customers wanted.  Our customer discovery was not thorough enough, hence why we struggled to find our target customer.

---

In the end, I learned so much from MacroFuel, and I am glad I did it.  Gus, Max, and Charles were great partners, and I look forward to seeing where they head next.  I made progress on my learnings from daapr and gained more learnings from MacroFuel that I will apply to my next venture.  

Remembering daapr

The week of July 17, 2017, my co-founder Aaron Schifrin and I shut down what was left of the very first startup I worked on, daapr.  Although we stopped working on daapr at the end of 2014, we had kept the site up an running because some of our users still played with the platform, and we also kept it as a memorable portfolio piece.

Daapr was a social media platform exclusively for sharing article and video content with your friends.  The idea behind daapr surrounded focus-based social media platforms; the way that Twitter emphasized statuses, and the way that Instagram focused on mobile uploads, daapr's goal was to showcase article and video content with your friends without the clutter that was associated with Facebook.  Daapr provided a clean, stylish user interface that aimed to promote discovery and engagement with user curated content.

As I took the time to shut down the platform, it gave me pause to sit and reflect on the experience as a whole.

My Role

My time working on daapr spanned across my last 2 years of college at Cornell University.  I was originally recruited to work on daapr as a frontend engineer by two of my friends who were already working on the team.  As the product and company grew, my role rose to Chief Technology Officer and a manager of the company.  I had to grow from a role of simply writing frontend code, to one of defining the product vision with the leadership team, working on growing the size of the team, executing on the product vision, and also managing the members of the engineering, design and marketing teams.

I had to evolve my role in daapr from that of an individual contributor to one as a leader of the company.

My daapr Story - Technological Learnings and Personal Growth

tl;dr This section covers my daapr saga and what led to specific technological learnings I had.  I break out exactly what I learned from this company and experience in the MY LEARNINGS section following this one.

When I joined daapr, I had basic programming knowledge in Object-Oriented Programming with Java, and Web Development in HTML, CSS, PHP and some JavaScript.

The original team built the first version of daapr in PHP using CodeIgniter and Masonry to build the Pinterest-like grid.  We chose PHP partially because we were familiar with the language and did not want to spend time learning a new programming language, but in retrospect it was more because we were nervous to go learn a new programming language that we did not understand.

My first technological learning was getting the first version of daapr to kind-of work.  This was my first project that I had worked on outside of school-based curriculum, and it forced me to expand my understanding of HTML, CSS, and hacking together JavaScript.  Shortly after we had a kind-of working Minimum Viable Product (MVP), the code broke, and my development partner left the company.

From here, Aaron and I had to decide what we were going to do.  We went from our original four partners down to two, and we had a broken product with half the knowledge of it gone. (Simultaneously, I was also very concussed from a soccer injury at this point in time, so I was not firing on all cylinders.)  We decided that despite the situation, we wanted to continue moving forward with our vision.  We went on a hunt on around our college campus to find a backend engineer that was smart enough to build an app outside of a class project, who also happened to be daring enough to work with us.

This led us to Connor Strynkowski, who ultimately helped bring us back on track for building daapr.  Upon further research, I decided to take my second step into growing my technological knowledge, and step outside of my comfort zone with PHP, and move in the direction of building daapr with Ruby on Rails.  The team chose this based on feedback from our peers in the co-working space THE POPSHOP with supporting evidence that the original version of Twitter was also built Rails.

The first attempt at building daapr with Rails went very poorly.  I left Connor to build the backend on his own, and planned on coming together to hook it up to my frontend code that we had used for the PHP version of daapr.  When Connor and I met to piece it all together, I looked at Connor's code and saw that he had written a lot of Ruby, but had not used the Rails framework at all...we had nothing that was usable.

This was when I had my third major technological and leadership learning, and that was that I needed to be knowledgable in every piece of the application we were building.  I did not need to be an expert, but I needed to know enough to make sure that everything worked together properly.  It was at this point that Connor and I embarked on Michael Hartl's Rails Tutorial, which has been the most pivotal learning experience in my education and career thus far.

Simultaneously with development, Aaron had applied the team for Cornell's eLab program to help the company grow its business acumen and give it credibility.  During the fall of 2013, the daapr team attended an additional weekly class sponsored by eLab on how to grow one's company.  We spent the weekends doing customer discovery interviews in random spots on Cornell's campus to better understand potential users that we wanted on the platform.

In December of 2013, Connor and I finished building the second version of daapr, and we launched the first alpha of daapr built on Ruby on Rails (hosted on Heroku).  During our winter break, Aaron, Connor and I signed users up for the alpha and started gathering feedback on the experience.  Now that we finally had a working product, many students on campus were very interested in joining the team.  We went from not being able to recruit anyone, to having too many people that were interested in the company.  We ended up expanding the team to include more engineers and a business development team to help with marketing and user reach out.

As the team grew, my role grew.  I conducted the interviews for the engineering team, and would train them on the technology stack and product.  Aaron would train and manage the marketing team.

Through 2014, more people joined the company, our user base grew, and the product continued to develop.  We originally launched with only being able to add posts, view posts, follow users, and view profiles.  Through 2014, we expanded to add discovering users to follow, liking posts, resharing a post (sharing another user's post on your profile while giving credit to the original user), commenting on posts, and notifications.  Daapr was built from the ground up with responsive design in mind for an optimal experience on all devices, but we did not start developing native mobile apps until 2015.

During 2014, I was splitting my time between managing our Heroku deployment, building the frontend code, helping debug the backend code with Connor, on-boarding our new engineers, and still managing school and internship interviews.  Towards the end of the 2014 school year, we were fortunate to add Anton Gilgur to the team, which allowed me to focus more on the leadership aspect and allow Anton to take over frontend development.  Anton worked to overhaul the frontend code that I had written to run faster, and expand upon the initial React.js components that I built to have the whole site built on React. This allowed for transferring state between components and a more uniform architecture. (React was very new when I wrote the initial components, and Anton wrote daapr entirely in React was before even Facebook used it for their site.)

Aside from Anton and Connor, the team had other engineers who I was working on training in order to contribute at the same rate as Anton and Connor, but for the most part they were working on smaller pieces until they had ramped up on the necessary skillsets.  Meanwhile Aaron was managing two teammates working on business development, which encapsulated customer reach-out, in-person marketing, and email marketing.

During the summer of 2014, the team went to different destinations for internships, which forced us to work and meet remotely.  The platform was costing us too much money to run on Heroku at scale, so this led to my fourth major technical learning.  I spent the summer learning how to deploy Ruby on Rails applications in a scalable architecture on Amazon Web Services (AWS), which by no means was a trivial feat, because despite AWS's prevalence, their documentation (especially for beginners) was lackluster at best.  This led to me writing my own guide for deploying Ruby on Rails applications in a scalable infrastructure on AWS.  It is titled Deploying a Ruby on Rails Application with Amazon Web Services OpsWorks The Idiot’s Guide to Migrating a full stack Rails Application from Heroku to AWS: A Guide made by an Idiot, for Idiots.  That summer was a test of fortitude for myself and the team.  I had to keep pressing on after repeat failures deploying daapr to AWS successfully.  The team also had to learn to self-motivate in order to continue working and meeting while remote.  This period of time ultimately showed who on the team would put in the time and energy to get things done.

As development expanded from 2 people to 3+, I started to understand the importance of writing requirements for oneself and for partners in order to ensure that everyone understands what needs to be built, and to ensure that everyone works on the correct tasks.  The team encountered significant growing pains on this; the engineers would casually chat about what each person would build and the service-level contract, but without an organized planning session and written requirements, individuals would frequently come together having different deliverables than what was expected.  After my summer internship, I started running sprint planning and adopting elements of Agile Development for daapr to help cut down on the wasted time from miscommunication on deliverables.

Development on daapr continued, and customer outreach grew.  Over 20 people worked on daapr throughout its lifespan.  Aaron did pitch competitions that gained us recognition and small amounts of cash, while the marketing team did fraternity and sorority outreach on Cornell's campus and started a campus ambassador program that spanned across the country.

Ultimately, growth and engagement hit a stall.  Aaron and I realized that we had made a fatal mistake.  Our original idea was that users would want to browse daapr on their laptop while they were at the library taking a break from studying; however, while we were interviewing and pitching users post-launch, we learned that everyone wanted a native app on their phone.  Although the site was completely responsive and worked remarkably well in one's mobile browser, native app usage for social media was skyrocketing, and our users wanted to browse daapr while they were bored on-the-go (like on the bus, or eating food at the dining hall).

In a last-ditch effort to restart daapr's growth, we hired an iOS engineer who went to Cornell to build out a native app for daapr.  Development continued and customer outreach persisted, but at the 2-year mark, Aaron and I started to burn out.  Managing the product and team was taxing.  We also had our personal lives, school, and job hunting.  

Moreover, Facebook had become the dominant player in news, videos, and media around the 2-year mark of daapr (2015).  Previously, Facebook had been predominantly filled with statuses, photos, and social games, with some links, but there had not been a focus on media in the content or user experience. As daapr was getting started, we could see that Facebook was making changes to place focus on the news, video and media content, but we figured that Facebook's users would never see it as a source for that type of content; we were very wrong on this notion.

Ultimately, after 2.5 years or working on daapr, user growth was declining, engagement dropping, and the team and leadership were frustrated and exhausted.  Aaron and I decided that it was time to call it quits, and stop working on daapr.  Unfortunately, we never ended up launching the native iOS app.

The company folded amicably.  Everyone understood that the product was not progressing the way that it needed to in order to prove itself as a viable full-time job, and there were no hard feelings.  It was a sad ending, but everyone felt like they were ready to move onto something new.

My Learnings

I learned a ton from daapr, arguably more than any of my college courses.

I learned:

1. How to be a leader for a team
2. How to manage people
3. How to build a product from scratch
4. How to make product-oriented decisions and prioritize features, tasks, and risks for the product and the company
5. About customer discovery
6. How to form customer problems and go after them
7. A lot of new technical skills that made me extremely more qualified for the workforce than I had been before working on daapr
8. How to develop technical architecture
9. How to have partners and how to balance differing visions, goals, and priorities in order to form them into a coherent team vision, set of goals, and set of priorities
10. How to pitch an idea and sell the vision to friends, family and complete strangers
11. How to speak confidently and authoritatively on a subject

Although daapr ultimately did not turn into a wildly successful hit, I had so many invaluable learnings that it was totally worth the time and energy.

My overall conceptual learnings:

1. Every technical product has to be thought of from a mobile-first perspective.  Mobile usage is continually increasing, and desktop usage is on the decline.  Building without prioritizing mobile first is an extremely costly mistake.  A mobile app may not have made daapr a wild success, but it would have taken the company further and made it more popular.
2. Really understand the customer problem that you are trying to solve.  If we had understood our users better earlier on, we might have seen the need to develop a native application earlier.
3. Keep the team small.  The largest the team was at any given point in time was 14 people (over 20 worked on it throughout, but some folks came and left).  It was fun to say that we had such a large team; however, when I look back, my time would have been better spent focusing on the product and a few highly productive teammates.  What ended up happening was that my time was spread thin managing people that were not putting forth the same contributions that I could have made if I was doing my own work on the product.  Everyone who worked on daapr was great, and I loved every minute I spent working with the team, but ultimately when the company is young and the product needs significant work, time spent on a large team can be costly.
4. Know every part of the product.  I originally tried to stick to what I was comfortable with, which was the frontend code.  I learned the hard way that I had to have knowledge on the full stack.  This helps with managing the team, auditing progress, and overall being a successful and knowledgable contributor.   I did not need to be an expert in each aspect of the product, but I needed to know each part proficiently.
5. Hands down, the most important thing that I learned from daapr, is that it's OK to not know what the hell you are doing.  As long as you are determined, just go after it; plunge into the problem that you are trying to solve, and figure it out.

The Product

The Infrastructure

The Memories

Thanks to everyone involved.  Below is a list of folks that I worked directly with at Cornell, but the people involved extends past these names below (listed in no particular order):

Aaron Schifirn, Connor Strynkowski, Anton Gilgur, Austin Gage, Nicole Hamilton, David Wiesenfeld, Peter Simon, Alice Meng, Maggie Yunjie Bi, Sean McNeil, Hong Jeon, Kevin Chen, Gwen Petro, Brendan Miller, Eric Appel, Tyler Nebel, Mateo Acebedo, Jesús Tacho Elizondo