5 months -> 5 weeks -> 5 days: How we launch products 30x faster
After just 5 days of working on the Language Cafe, it’s already available to the public.
In stark contrast, our first product Mist took a whopping 5 months. We started in March and didn’t launch until September that year.
In that span, we launched another product called USC Dating Club which took about 5 weeks.
5 months -> 5 weeks -> 5 days.
How have we gotten so much faster at shipping product? What do we know now that we didn’t know when first starting our indie app studio?
Conceptualizing “MVP” in new terms
At some point in the average entrepreneur’s journey, they’ll learn the term MVP. They’ll quickly find out it stands for “Minimum Viable Product”, make the connection in their head, and move on. From here on out, they’ll continue to use the word MVP in referencing the first version of the product they build and share with others.
But the term MVP obfuscates away the real meaning. It probably reminds you of Most Valuable Player, which is an extraordinary high quality athlete. Extraordinarily high skilled person, just like an extraordinarily high quality product, no? Plus, without repeating the word “minimal” you generally lose sense of the importance of “minimality” in the concept.
To me, MVP had become “the first version of a genius startup that will soon blow up.”
What it should really be is “a barely working prototype that I’m not super proud of but at least I got it out the door and into someone’s hands.”
Once I began explicitly framing the product as a “Barely Working Prototype” as opposed to an MVP, my approach to the whole process started to change. I spent less time on irrelevant things, more time coding, and reminded myself that the whole goal is to get this into someone’s hands.
To misquote Nikhil Vaswanathan, “if you’re finally ready to share your creation with the world, you waited too long.”
Less time on the unimportant
Early on there were days where I would spend hours and hours working on small features that were so irrelevant in retrospect.
Founders and YC people always talk about how you should build the absolute minimal viable product. But that’s always talked about in general terms. What does that look like in the day-to-day?
Part of this is building a sixth sense to determine what’s even worth working on in the first place.
Another part is building the muscle to overcome sunk-cost fallacy. To be able to catch yourself 30 minutes into working on some feature and realize “this is not worth the time, let’s set this aside and move in.” No matter how many books you read on sunk cost fallacy, it takes trial and error to instill it within yourself.
Xcode > Figma > Notion
It’s cool to get excited about an idea and spend time thinking about how awesome it could be. That is, until one month later you still have nothing but a bunch of Notion pages full of text.
A slightly better version of this is going into Figma and spending time designing all these cool features. This is generally better than conversations and notes because you have a tangible to structure your ideas around and you’re actually producing something. But you’re still not making something someone can use (at least, not until Figma-to-Code comes out).
Most importantly, you need to actually build something. Code needs to be written. Nothing can actually be used until then.
I have hundreds of ideas laying around in Notion. I have dozens which have been translated into Figma projects. But I only have around 6 shipped products. There is a clear funnel from Notion to Figma to Xcode, and it’s best to lean into the IDE as much as possible.
(Of course, you can replace these apps with any other notes, design, and coding tool of your choice. The analogy still holds.)
Leaner MVPs
Mist (5 months) arguably was a beefier MVP — we were building an alternative to a popular Instagram account for missed connections, so the product was in effect competing with Instagram. The real wisdom here would have been to not pursue this idea because it wasn’t so original and idea-to-MVP time was relatively quite high.
USC Dating Club (5 weeks) was also more technicality complicated because of the real-time location sharing and matching.
Language Cafe (5 days) was relatively simpler, only interacting with a few external APIs and two internal Apple frameworks and providing a focused UX.
Some MVPs just require more work, even to be minimal. SpaceX simply requires more time than Flappy Bird.
Code Capital
It used to take me hours and hours to make small progress when coding. I would spend my time
- Referencing documentation
- Reading through stack overflow posts
- Messing around with code that still wouldn’t work
Now, my development time is sped up in two ways
- I have the know-how to code it. And the know-how to deploy it. It doesn’t just stop at coding. It’s all the random ins and outs of deploying things to the internet that has nothing to do with your data structures or algorithms classes.
- I literally have the code for it. I’ve probably already written code for something similar which I can reuse. This is one of the most understated benefits of building your own stuff. You create your own personal codebase which you can reskin whenever, wherever.
Progress over Perfection
Speeding up shipping speeds by 30x is crazy, but it’s possible when going from total newb to experienced entrepreneur.
The old adage “Progress over Perfection” once again rings true. Push yourself to ship as soon as possible. Don’t spend 5 hours making the Settings screen beautiful. Believe me, it’s not worth it.
