Note: I’m currently trying to get this experience made as maybe a case study in business school. That will require making this shorter,  which will lose information. That’s why I’ve published the full version on my website.

Looking for the second part? Click here.

It’s fitting that the longest post I’ve ever written so far would be about the longest project I’ve ever undertaken. For the past two years, from about November 2019 to November 2021, I had been working on my first startup ever. While there were periods of hiatus, it was the personal project that got me through my first two and a half years of Brown University and through the COVID pandemic.

But alas, at the end of the day, it ended up like 90% of its brothers and sisters – in failure.

So, this blog post has two purposes.

First of all, it’s a medium of reflection. I’ve made a lot of great connections through this process, and I’ve also learnt a lot of entrepreneurial lessons. I can’t hope to write them all down here; that’s both difficult and unnecessary. However, what I don’t think is unnecessary would be explaining some of the specific things that brought about this startup’s downfall. This would both solidify my lessons and also serve as an answer to anyone else who wants to know why we failed.

During my time writing this post, I met a man on a train from Boston to Providence who was the founder of a consultancy firm and the vice chair of one of Boston’s entrepreneurship networking companies. I love it when these types of random interactions happen; I always get nice nuggets of conversation or ideas. He told me that I shouldn’t think of this post as a post-mortem, but as a reflection. “Parts of Emit will live on in future startups,” he said.

This leads me into the second reason for writing this post – failure stories are important. There’s a twofold danger to only learning from successes. Firstly, you often won’t hear about as many things successful companies did wrong because they aren’t as interesting/exciting/inspirational to talk about as things they did right; their mistakes might not even be as known because their consequences were overshadowed by the things they did right. Secondly, it doesn’t give you a full picture to judge your decisions with. If you have a portfolio of only success stories in your mental vault, and you’re trying to decide if you should do something those protagonists never did, how do you know if they never did it because it’s something to avoid, or because they simply didn’t need to/want to?

So, this post is going to be somewhat of data dump with reflections afterwards. It is going to be pretty long, because there’s so much in Emit’s failure story that I don’t want to perform lossy compression and compromise on the learnings.

Oh, and one more thing. I don’t do affiliate links here, so no link here is sponsored or monetized. Click away!

Okay, I’ve set the stage! Let’s get going.

 

What was Emit?

Emit had a number of pivots, but it was always centered around tackling the problem of imperfect information. Essentially, Emit was a platform that was centered around making it easier for college students to spontaneously find things to do on campus, with a focus around things that are happening within hours.

The Emit team and I thought of the app as a discovery platform for events and opportunities to meet new people. Event broadcasts were called flares, and they could be sent by anyone. If the sender wants as much visibility as possible, flares can be sent to all nearby users’ feeds. Otherwise, they can be sent to specific friends’ and groups’ feeds.

Events could be anything, from club meetings to a cappella recitals to impromptu frisbee games. Flares could be viewed either on a map or on a conventional list feed. They contained time, location and live participant information, as well as anything else the sender desired.  Joining a flare also lets you chat with others who joined the event, and flares are automatically cleaned up once the event is over, ensuring that only flares for relevant events are visible.

Emit was never meant to be just for colleges, but we thought colleges were the ideal environment for this type of product (also it was the environment we were immersed in). So, we intended to grow it in that environment before expanding to other use cases.

Some screenshots of Emit:

 

Emit’s Chronological Story

It’s important to have knowledge of Emit’s entire timeline before going over its strengths and weaknesses because everyone would have the ability to apply hindsight.

The Mustard Seed

Emit started as an unnamed solo project that I started in the later months of my first semester at Brown University in 2019. At the time it had a much more specific target – food. I was tired of the tediousness, awkwardness and inefficiency of finding people to have lunch with during the busy weekdays. Texting people would often result in ghostings, “no”, or “I already ate.” Moreover, it’s tedious to have to text a bunch of people on different platforms asking if they want to join me; I also had to regulate how often I texted each person so I don’t irk them with daily texts for lunch meetups.

After one ghosting too many, I decided that this was a problem I wanted to dedicate time to solve. I immediately identified the problem as imperfect information about who is available to eat, and started planning the platform that would solve that. This platform would make it easier to have spontaneous food-based get-togethers with friends. To gauge interest, I started talking to my friends about my plans; feedback was almost unanimously positive.

I started researching the possible cloud platforms I could use to build my stack^[1] and settled on React Native + Google Cloud Platform^[2]. In December, I started programming the smaller parts while architecting and planning the larger parts of the platform and settled on the name Biteup (pronounced similar to “meetup”). I also made pitch decks to pitch to friends, mentors and my Presidential Scholar’s cohort. These were not investor pitch decks – I had 0 interest in investors.

Some early sketches of Emit:

 

Christmas break was spent learning all the nuances of Firebase while also starting the implementation of some core features; this continued into the spring semester.

In late January 2020, I decided that this could be a very serious entrepreneurial project, and decided to talk to someone from Brown’s Nelson Center for Entrepreneurship. I ended up meeting Danny Warshay – the meeting didn’t go the way I expected.

I pulled up to his office very excited and bubbly, and showed him my pitch deck and working prototype. I don’t exactly know what I was expecting. Maybe some secret sauce advice, or even just idea validation. Instead, he told me that I was doing it all wrong. He said I was clearly talented and passionate, but I was operating within my own world and hadn’t properly researched the users I plan to serve. I was setting myself up for failure. I told him I had been pitching to people and that feedback was overwhelmingly positive. He cautioned me that the positive responses were invalid because I was using the wrong feedback gathering methodology. He advised me to do better anthropological research into Brown students to see if Biteup is even needed.

I somewhat knew that he was right, but frankly I didn’t feel like putting myself out there. I was comfortable living in a mindset where my code and passion for the project were the only things that mattered. Like almost everyone else, I felt like an exception.

Nevertheless, I conducted a short episode of interviews. Insights were not forthcoming. I did realize, though, that the problem I was trying to address didn’t seem as urgent to others. Regardless, I figured people would come around when they realized how much easier Biteup made things.

I continued on steadily with development. By the time Brown evacuated its campus due to COVID, Biteup was more than a minimum viable product.

The later part of spring and all of summer were spent on polish and extra features. I also developed a brand identity and hired designers for a professional logo. The logo process was surprisingly expensive, involved, long, and interesting; I’ll touch on that later on.

The Wall

Biteup was shaping up to be a pretty impressive personal project, and I had gotten a lot done despite occasional haituses. COVID, however, presented a particular problem. It was quite literally one of the few things that could have prevented me from finally getting this product into people’s hands. The next semester was going to be completely remote and the one afterwards, unbeknown to me, would end up being hybrid with limited physical contact. Biteup simply wouldn’t thrive in such environments. The more the magnitude of this barrier became apparent, the less feverishly I worked on Biteup.

It was also around the summer time that I started consuming more media on entrepreneurship, like the How I Built This podcast. Building Biteup and treating it as more than just a technical side project was challenging yet fulfilling and made me consider entrepreneurship as a career.

I was not on campus during the next semester (sophomore fall 2020). This semester was completely virtual, and I had no idea on how to progress with Biteup. I had hit the wall. So, I spent my time learning about entrepreneurship in general through workshops, talks, podcasts, videos and zoom meetings.

This impasse ended in late December with an email from a fellow student. Brown’s entrepreneurship center had mentioned me to 3 students who were thinking about solving a similar problem to Biteup’s. Their names were Nate Goodman, Brandon Li and Eyal Levin. I nonchalantly agreed to meet, and I was pleasantly surprised and refreshed. These guys were the first people I spoke to who understood Biteup as deeply as I did.

They had already started a long round of student interviews to better gauge the problem space – they were doing the interviews Danny had suggested to me so long ago. We were a good mix – I had the platform and they had already started some of the more user-centered work that I hadn’t done. So, we decided to join forces. We continued the rounds of interviews, decided to generalize Biteup to more than just food meetups and started giving the app a UI overhaul to fit its new generalized purpose. This overhaul process also had its own round of feedback interviews in-between design and implementation.

 

The Launch

Finally, sophomore spring would be Biteup’s launch date. The semester was hybrid, but with Biteup being generalized to any type of physical interaction, we thought we could slip into some of the cracks and gain some traction. During this semester, we also worked on Biteup for course credit. So, we had the guidance of our professor Jonathan Jannotti (AKA JJ) and worked in the same course as other entrepreneurs, such as the founders of Zaar and Hometown Academy. From the course and from our own network, we were able to interact with the founders of DownDog, Monthly and Pangea (amongst others) for advice. This constant exposure to external entrepreneurial stimuli acted as a source of many reality checks.

A lot occurred in that semester, as would happen in the first months of any startup’s launch. We changed the name from Biteup to Emit, and released our product to the Apple and Google app stores. We started our first targeted download campaigns. We started by slipping business cards under all the dorm doors of Keeney Quad, the largest freshman dorm at Brown University. It was fun, but proved ineffective. Next, we had a few sessions of going to the main quads and giving out candy to anyone who would sign up for the app in front of us. We got a couple hundred downloads from that, and about 100 accounts.  That, in our books, was a success.

As the adage goes, “You only succeed in what you measure”. So, we started adding analytics to our app. For part of the semester, we also experimented with Emit being a platform for virtual meetups by hosting a couple game nights. We got few attendees, and the virtual experience was clunky., We surmised people had had enough zoom fatigue from classes that they also didn’t want to participate in more virtual experiences for leisure. Then again, it was hard to tell due to sparse usage.

 

Most importantly though, we started seeing how people actually used and perceived the app. We started seeing people’s confusion when we were explaining its value proposition.

“I’ve heard about you guys but I don’t really understand what you guys do.”

“What’s the difference between this and a group chat?”

We started seeing people’s light bulbs turn on (or stay off) after we explained it further.

“Oh, that’s a really cool concept!”

“I wish more people were on it, then maybe I’d use it.”

We started seeing more problems with UI and making over-the-air^[3] updates. We started experimenting with more features, including friend recommendations, contact book integration, or public groups (before that, all groups were invite-only). We got a lot of feedback from multiple sources, and had to start prioritizing and scheduling features that mattered. Our Asana lists were getting pretty large as a result.

As we hosted game nights on the app, and as a couple of people also started making their own flares, we started to see that some of our assumptions about people’s motivations to make or respond to flares, and how often they’d even be able to do that, were wrong. In some respects, which I will detail later, we started seeing that people had less reasons to respond to flares than we expected. It also became clearer to us how difficult it is to overcome the network effect as a new startup.

 

Recovery Mode

By the end of the semester, we had made some victories, but also been presented with many existential questions about Emit. Why was retention so low? How can we make the value proposition clearer? Many people didn’t know how to justify Emit’s existence in the face of group chat platforms. How can we make it easier/more worthwhile for users to use the app when not everyone they know is on it? We’d learnt a lot about the power of analytics, user journeys and intentional iteration, but we had such little user interaction that we couldn’t really determine if the problems of low retention and an ambiguous value proposition were due to the network effect or from a fundamental flaw in Emit. This poor understanding of our problem made it hard to find solutions. So, when other founders gave us advice, we couldn’t really see how they could fit in the puzzle.

We saw the next semester (my junior fall) as our best shot at attaining some level of market fit at Brown. We thought that people were going to be eager to do things after a year of COVID restrictions, and if we failed to get it right in the face of such an opportunity, our chances afterwards when people revert to normalcy were slim. Many startups’ successes are highly dependent on their timing, and while the time during COVID was the worst possible period for Emit, the time after COVID’s peak might be the best.

With the departure of Eyal from the team, the rest of us were determined to fix Emit over the summer in preparation for the fall semester. My remaining co-founders joined Brown’s startup accelerator Breakthrough Lab  (AKA B-Lab), while I interned at Amazon and committed to working on Emit after-hours.

A lot happened that summer. Frustratingly, much of it got us nowhere until the tail end of the summer. Initially, we were a bit scattered about what it meant to fix Emit. After all, we weren’t exactly sure what was broken. So, we tried simultaneously fixing as many things that could have been broken, even if we were skeptical of the significance of some of the things we focused on.

We held interviews for UI designers early on, and almost contracted one. Eventually, we dropped it. UI wasn’t a fundamental problem, and as Adam Alpert told us “If your product really solves a problem, people will hit themselves with a brick to use it.”

We considered exploring other markets beyond the college environment to see where else Emit could fit in. A product like Emit thrives where there are lots of people in a close geographical area that want to meet in subsets for whatever reason. After some brainstorming with a B-Lab mentor, Jason Harry, we decided to try the tradeshow industry. We imagined Emit as a platform for people to have a better understanding of what’s going on in large trade shows. After talking to trade show organizers though, we dropped this too. We simply lacked intrinsic interest in  tradeshows, and also concluded that Emit would need to be a very different product to satisfy their needs.

One interesting thing that occured is that Emit began to be used by some interns in my Amazon internship cohort in Seattle, at least for a while. They used it for the opposite reason Brown students did. Instead of having too little information about what was going on, the Amazon interns had too many channels for events (i.e., Slack, Discord, Snapchat groups, word of mouth). Emit acted as a great centralized platform designed just for events, and some folks loved the simplicity and readability of it.

Truth be told, we didn’t really know what to make of this new type of motivation and we decided to treat it as a serendipitous anomaly. Nevertheless, we tried to take advantage of it by attempting to get interns to take Emit to their colleges and help its propagation. So, we ran a sweepstake to increase usage and hopefully get some new users to talk to. We only got a couple of responses, but tried to keep in touch with the folks who genuinely liked the app. Our efforts eventually withered when interns started getting comfortable in their cliques.

 

 

One pivotal thing we did early on was to implement and release public flares. Public flares were broadcasts that could be sent to appear on the feeds of nearby users, not just people you know or members of groups you’re part of. It was a feature that was repeatedly requested for in the previous semester, and it added a completely new dynamic to the platform. It also, eventually, became the catalyst for us to critically think about our value proposition.

We began to appreciate that public flares showed more value than its predecessor (we called those private flares). It became easier to explain to users what made Emit different from group chats. Over the summer, we sought to form partnerships with lots of clubs, and the value of Emit became more convincing when we portrayed public flares as a recruitment mechanism. Public flares also made new users’ journey smoother, since they could immediately see public events upon signing up without having to join any particular group.

 

We initially brought in public flares as a secondary feature to grow our userbase, under the assumption that eventually people will start to make their own groups and social networks and resort to using the classic private flares. The problem was, the introduction of public flares no longer made Emit an app about doing spontaneous events with friends. It made it an app about doing spontaneous events with people who are more or less strangers.

 

That was a value proposition change. Another pivot.

 

We eventually came to terms with this pivot over time, particularly after we forced ourselves to refine our value proposition in preparation for Product Hunt^[4].

Brandon and Nate deserve credit for being the spearheads for navigating this pivot for the team; I had less bandwidth at this time.

While all this was happening, we were also thinking about (and sometimes implementing) new features, like scheduled flares, editable flares, sending flares to non-users via SMS and anonymous accounts. We also started developing a feature for users to join flares only after a certain number of other users expressed interest, so you can avoid the awkward situation of being the first to commit to a flare. This feature was never released because the semester started before we could finish it.

It was a packed, difficult, sometimes worrying, but ultimately a fun summer. While balancing my internship, I was being a PM and technical lead of the Emit team. We had several code reviews over Github, and regular progress reports in the morning where we tracked progress over Asana. We were having to grapple with the pivot, new features, what we should/shouldn’t do, and how this pivot will affect Emit’s trajectory and brand.

Despite our pivot, we remained uncertain of our success. Many of the decisions we had made were based on thought experiments and founder-to-founder conversations (though we had conducted some interviews with users). We needed a new launch to see if this new Emit could attain market fit. As the summer ended, and our co-founder Nate left the team to start his full-time job at Amazon, it was left with only Brandon and I. We got ready for one last go.

 

One Last Chance

About a week before the semester began, Brandon and I decided to start “faking” the supply of flares. Every morning, Brandon would look through Brown’s underutilized event noticeboard (Today@Brown) and post flares for interesting events. Generally, artificially creating supply is a common tactic digital marketplaces use to get off the ground; we decided to give it a serious try.

Our months of Zoom calls with different clubs and organizations had resulted in at least a few that we were reasonably confident would try out Emit as a recruitment medium. However, it wouldn’t be until Brown’s activity fair one week after the start of the semester that clubs would start having meetings. We attempted to use the booths of these promising clubs as advertisement sources during the fair, but it didn’t really amount to much. About 2-3 weeks later, it became apparent that none of those clubs would be of much help. Most didn’t really follow through with their commitment of posting their events and getting their members to use the platform.

Following this failure, we decided to try and make Emit a party app. We figured that if we could market Emit to party organizers and goers, it would be a gateway to get Emit into people’s hands for other purposes. We wanted to target Providence College, which was much more of a party school than Brown. So, we hit up the Old Irish Social Club – a bar nearby the College. We met no Providence College members that night; the bar was taken over by Brown students! We ended up meeting one Brown student who was well into the party scene and was willing to help us test out the party domain at Brown.

At around the same time, we also teamed up with a TikTok star (Over 4 million followers at the time) who was willing to help us use her fame and knowledge to get Emit into the party sphere of other schools.

Simultaneously, we started getting some press. A bit of a distraction, honestly. We had an article written about us in Brown’s main newspaper, and also had a video-pitch to a virtual crowd of investors and entrepreneurs as a way to conclude B-Lab (which actually ended 2 months prior).

By late October, it was clear to us that our party-app approach wasn’t working. The fellow from the bar underdelivered. We also discovered that people prefer the preserve of exclusivity in their party invitations, which Emit was pretty antithetical to. Moreover, our TikTok star was unfortunately unable to affect our analytics that much, or get us into other schools through channels like Barstool.

Momentum was very low at this time. For the first 3 weeks of October, only about 70 flares were made, the vast majority of them by us. There were only 43 views, meaning a flare had a 50% chance of never being tapped by anyone. To top it off, there were only 2 people who officially joined a flare in that period.

 

 At this point, the light at the end of the tunnel was becoming increasingly faint.

 

Throwing in the Towel

Brandon was still trying to go strong, but I was starting to come to terms with my premonition that we’d reached the end of the road. Keep in mind that for two semesters I had been taking entrepreneurship courses and reading several case studies about failed and successful businesses. Whenever I thought about Emit’s progress, the dissimilarities with the successes worried me.

To either confirm or debunk my fears, I decided to have a call with Boon, one of the investors that we had met at the B-Lab video-pitch.  As I did with most people I spoke with, I was planning on taking his advice with a pinch of salt.

That call completely confirmed my fears. He was frank about the fundamental issues he saw about Emit, and why he thought it would not succeed. We’ll get into those in a couple of sections later. To me, it wasn’t that he was just listing issues. It was that some of the problems he saw as blatantly obvious had taken Brandon and I months to find out. It was a wakeup call to me about our porous assumptions and weak assessment abilities. After that call, this was the last nail in the coffin. I was ready to end Emit.

I told Brandon about this call and about our few options left: keep trying, sell the code, or just stop Emit all together. We agreed that we’d stop, but only after trying one more thing. A grasp for straws, honestly. About a week earlier, we had gotten in touch with  Small Victories, an organization that threw massive popular college parties in Providence. We wanted to be their vendor for last-minute tickets. We figured if we could link flares to their events and get Emit popular through them, we could expand afterwards. Our pilot was somewhat successful, we sold out in a couple seconds. But that was because they gave us less than 10 tickets to sell. They simply didn’t really need us; talks with them later on confirmed that.

5 days later, on 6^th November, Brandon and I met up and agreed to end it all. In the days that followed, I sent a final email to our users, set the app on auto-pilot, deleted plenty of our cloud infra that was no longer needed, and open-sourced the code.

We drew the curtains – the show was over!

 

 

What went wrong?

If you made it this far, thanks for reading. In Part 2, I’ll go over some of the many things we learnt while running Emit, and also give a critical analysis of what went wrong and where we could (and couldn’t) have done better.

See you there!

 

 

^[1] A stack is the set of technology tools and platforms used to build software.

^[2] React Native is used to build mobile apps with Javascript, Google Cloud Platform is a cloud computing platform.

^[3]These types of updates do not require developers to re-upload their app to the Google and Apple playstores, making update deployment much faster.

^[4] Product Hunt is a popular platform for announcing launched (or soon-to-be-launched) startups. This Product Hunt blurb was written as we were still navigating what the value of Emit was.