Notes to self

Reflections on my 24h startup challenge

I completed a first startup challenge I set for myself. 24 hours and 30 days to build an MVP and find people to try it. How it went and what’s next?

Why but why

I ship quite slow, because I am more of a perfectionist when it comes to my projects:

  • My book Deployment from Scratch should have been a 5-month project, but ended up taking me over 3 years.
  • My Rails SaaS template should have been a 2-month project, but I haven’t shipped 1.0 yet.

This needed to change. I needed a challenge to focus on building what’s important and shipping it. Something similar to hackathons I always participate in at work.

There are plenty of startup challenges out there (like quite famous 12 startups in 12 months) but I wanted to do something smaller, more constrained. Something I can do while working or while on vacation.

In the end I came up with an idea to ship a startup MVP in 24 hours.

But I introduced a change from a similar hackathons; One can spend the 24 hours as they see fit within a period of 30 days. This is important for my mind to wonder and think or for any marketing effort to materialize.

Challenge

Here’s the basic rules of the challenge:

  • 24 hours in total
  • 30 days period
  • 10 people should try it

Although I would love to introduce a monetary goal of selling a subscription, this would be quite hard. Besides selling a very rough version of the product, you would also need a payment processor approaval. So I kept it simple.

Idea

There were couple of ideas I was thinking of. I looked up products that have one simple core feature that can be delievered and makes the product useful already.

And I won’t lie. One of the ideas was a Twitter tool since I spent a lot of time on it. But I am happy I haven’t gone this path for obvious API pricing changes introduced on Twitter during the time of my challenge.

So what did I pick? I picked a server monitoring tool. My idea to differentiate was to do some monitors current products lack and offer a pricing scheme that could work better for people.

I thought it’s also something I could offer to people buying my book as one should always think about distribution too.

Research

I started by a small business research, identified close competition, and selected one to try. I found out most products charge companies for team members, so that would be one vector to join the market.

Then I wrote down what the MVP should be; An uptime monitoring with an email notification and a status page.

I also realized the generous free plans make it almost impossible for me to get people exited about this. And that’s where I think I made a mistake. I continued without reevaluating the MVP.

I should have built a monitor others don’t have, not the one core feature everyone offers for free.

Execusion

After identifying the MVP I went ahead and started to build.

I prototyped the biggest challenge of the MVP. The uptime statistics. I ditched an effort to learn about time series databases and I learned how to do it with the date_trunc() function in PostgreSQL. That I can say was a good call.

Then I employed my Rails started kit and the deployment script from my book to have the site up and running quickly. I used Sidekiq Scheduler for the worker interval checks and the rest was basically your average CRUD.

I called my statup Upbeat and put it on upbeatbot.com. I kept it open by allowing regular users to create a free plan.

Marketing

The biggest marketing was to tweet the whole challenge in public.

The initial post received 2 retweets, 5 quotes, 83 likes, and 14 bookmarks. Nothing mind-blowing, but it generated 16.5K views that didn’t cost me a dollar.

I also submitted post to some subreddits and to Indie Hackers website. Most of that flopped.

The only other thing that worked was to genually ask what monitoring tools people use rather than simply promote Upbeat.

Time breakdown

I spent 20 out of 24 hours:

  • Idea research.. 2h
  • Isolated prototype..2h
  • Basic CRUD.. 3h
  • Worker.. 1h
  • Deployment.. 2h
  • Emails.. 2h
  • UX improvements.. 1h
  • Status pages.. 3h
  • Fixing bugs.. 2h
  • Marketing.. 2h

I haven’t used the last four because of my vacation, but they would be spent on marketing.

Results

I built the MVP and got 12 regular signups (and one spammy one). So far so good.

However not everyone created a monitor.

One of the reasons for that is that I had a bug that I fixed by another bug. While my Rails SaaS kit has great code coverage I haven’t written any tests for this challenge to save time. In the end this cost me. If you already find an early adopter you should make sure they get good experience.

Most people were not thrilled about another uptime monitor.

I don’t blame people for not wanting to try a subpar product instead of going with something established with a free plan as well.

Lessons learned

1, Differentiation is king.

I made a mistake of implementing a subpar version of what’s already out there and free.

I need to focus on what’s new and different next time if I want to attract early adopters and get people more exited.

My approach could still work well in the long-run, but wasn’t great for a quick validation.

2, Building in public is still great.

Forget nay-sayers. I got an amazing response on Twitter and there were patient people that helped me resolve my bugs.

3, Tests are important, MVP or not.

It’s very hard to find someone to test your product, don’t waste it! Write more tests even if it’s a throwaway MVP.

What’s next

Right now I am taking some lessons from building Upbeat to improve my Rails template. That’s already something that made this challenge worth it. After that I’ll likely do a one more pivot of Upbeat, so stay tuned.

Check out my book
Deployment from Scratch is unique Linux book about web application deployment. Learn how deployment works from the first principles rather than YAML files of a specific tool.
by Josef Strzibny
RSS