At the end of Q1, I announced I was shutting down my first startup LineTimes. It's been a few weeks since then and I wanted to do a full reflection on the project before I moved on to start something new.

LineTimes

LineTimes was a website that showed real-time wait times at grocery stores in NYC. I created it based on the observation that lines were ridiculously long at peak times in NYC (40+ mins pre-covid, 2+ hours during covid) and that people probably wouldn't be so inefficient if they had data to show them that.

After 3+ months running LineTimes I can pretty confidently say that's not true. But this story is about the journey, not the destination.

A failed startup

Startups are risky ventures. According to Investopedia the failure rate for startups was 90% in 2019.

To hedge this risk, I created a system of win / lose constraints to force myself to stay within reasonable bounds for risks and costs. These constraints helped me understand that LineTimes wasn't on the path to winning and was detracting from my other ventures. It was time to shut it down.

Primary reasons LineTimes failed:

1. No proof of value
2. Bad value:cost

Failure reason #1: No proof of value

I created LineTimes with a win constraint of 100 recurring visitors (4+ times / month). This was mainly for the first milestones - if I could show the project could bring in 100 recurring visitors then I knew that it was providing some value.

I settled on this constraint by thinking about how I could prove LineTimes was providing the value I wanted it to provide. I came up with trying to track whether people were actually using this to make their grocery store runs more efficient. Based on 1 grocery run / week, we'd need 4+ visits / month to prove this was useful.

After 3+ months, LineTimes only received 52 new users. That comes out to about 17 users / month, far less than the 100 users / month I was shooting for.

I tried a few different methods of gaining traction:

• Talking to friends and fam about the site
• Posting on my socials
• Featuring the site in my blogs and videos
• Making a sign and standing in front of long grocery store lines

Launching my first real business of the year:

LineTimes - a site that calculates wait times for stores in your area.

Now live with Trader Joe's locations in Manhattan. https://t.co/iAgOpn3HCz pic.twitter.com/a6hp28M2bl

— Hamilton Greene (@SIRHAMY) December 19, 2020

But in the end it didn't draw the interest and engagement I was looking for.

Failure reason #2: Bad value:cost

Now just because a venture isn't in a win state, it doesn't mean it should be killed off immediately. For instance, what if we have a site that gets nearly 0 visitors but doesn't cost anything to run? For something like that, leaving it running has little downside.

Ah but LineTimes didn't cost $0 to run and its cost plus its !winning led me to ultimately shut it down.

As a general rule, I like to determine whether something has a good value:cost ratio based on whether it's profitable or not. If it's profitable then it could reasonably run for a long period of time without much downside. If it's not profitable then it's taking resources away from other potentially profitable ventures.

LineTimes was pre-revenue so it's a little weird to put it to the profitability test but the general rule holds that its value should be higher than its cost (and thus profitable).

I wrote a detailed breakdown of LineTimes' costs and found that it cost me ~$90 / month to run.

• $50 - cloud hosting
• $40 - data / api costs

$90 isn't that much money in the grand scheme of things. But I'm big on the fail fast and cheaply train and that was far more than I was willing to pay for 17 users / month.

For some additional perspective, my total Projects budget is $200 / month. Which means this one bad bet was effectively siphoning half of my capital resources. Spending half my budget on a project that couldn't prove its value seemed like an iffy choice.

So I killed the project. It didn't have much value and cost too much.

Though it sucks to kill a project, I think it's worse to over invest in bad projects. By killing a bad project you free up resources (money, time, headspace, etc.) to work on new, potentially better projects.

If you systematize this fail fast and cheaply process, you end up trying out a lot of different projects with minimal investment in bad ones. I think that's a strong strategy for success - and a driving philosophy for my habit of building a project each month.

Reflection

I do a lot of reflection as a way to understand where I am, how I got here, and figure out how to do better in the future. So naturally I wanted to reflect on my failed project, analyze what went wrong, and modify my systems to build better projects next time.

Win / Lose Constraints

I had a win constraint but no lose constraint for this project. It turned out fine because my project was so costly that it ran up against my implicit lose constraint (going over my Projects budget). But if it had been just a little less costly, I may have let it run for many more months.

In future projects I'll set an explicit lose constraint so I can find and divest from bad projects sooner.

Talk to real users

I had a lot of data that showed me that LineTimes wasn't providing much value. But I didn't have much to go on to tell me why it wasn't working as I intended.

Talking to users would've given me a lot of insight on what was working and what wasn't. Further, it could've told me if I was solving a problem that didn't exist and alerted me to a possible lose scenario much sooner.

This would've been easy to implement - particularly as I was already out and about advertising for LineTimes - but something I never executed on.

Use better, cheaper infra

If LineTimes had been cheaper I could've let it ride for a few more months before killing it in case it just needed more exposure. This could've been a pro / con depending on the ultimate outcome but the fact remains that the cost of this project was prohibitive.

During my reflection I did some analysis on LineTimes' hosting costs and found that I could likely have hosted everything for ~$10 / month (down from the actual $50 / month). With the external APIs it would've still costed around $50 / month to run LineTimes but for many projects without this dependency, that'll bring total cost down to $10 / month - vastly expanding the number of projects I can run with my budget.

Fin

So that's the story of LineTimes and why I felt it was the right time to shut it down. It wasn't the ending I'd hoped for but I'm trying to make the most of it by learning from it and applying those learnings to my future projects.

I share regular updates on my projects / ventures here on the blog so if you liked this, consider: subscribing for updates.

Always Hamproving,

-HAMY.OUT