Multiple Test Accounts, Minimum Viable Company, The Hot-Swap Startup, Optimizing Bugs Fix Policy, Poor in Tech, Engineering Culture, and Extreme HTTP Performance Tuning
Hello there - I hope you have an awesome weekend.
If you haven't joined yet, you can subscribe right here:
It’s already been a year since I started the newsletter.
I’m going to continue for now, but I may have to re-allocate my time elsewhere.
Fantasy Angel Fund #1
$3M fantasy angel fund - $50K checks - 60 seed-stage startups - * new check
The full list is here.
“Before attempting to scale your minimum viable product, you should focus on cultivating your minimum viable company. Nail down your value proposition, find your place in the broader ecosystem, and craft a business model that adds up. Nail it and then scale it. In other words, true product-market fit is actually the magical moment where three elements click together:
As you can tell, great product features constitute just one-half of one-third of the whole puzzle. Moving into “growth mode” while missing any of these elements is building your company on an unsound foundation.”
“Isn’t this just another “full-stack” startup? Yes, hot-swap startups are all “full-stack” in that they own more of the stack of delivering their service than just software. That said, most full-stack startups still require their customers to “trade” some advantage for other disadvantages (again, with Warby Parker — before they had stores — you had to wait to try on the frames at home, but you got a better price and a modern experience). The same is true with Uber (can’t just hail one on the street), Netflix’s original DVD service (wait for the envelope to arrive), Airbnb (no room service), etc. So a hot-swap startup is a special kind of full-stack startup.”
“I am sure you are familiar with the following scenario: a user is reporting to your Support team that something is not working for him as expected. Your Support team investigates the issue and agrees that there is a bug in the system. They open a JIRA bug to the R&D department with all the information they have collected, as expected from them. But then… a furious argument begins on the ticket. Support is saying that they think R&D should solve this bug within a week. The Customer Success Manager is saying this is a critical customer just before renewal. Therefore we need to make all of the effort to solve it within 48 hours, but R&D doesn’t see this as an urgent matter and thinks the bug should be solved within 30 days. Who is right?!”
“I knew I was the only poor person at my tech startup because on the day I left they told me to put my equipment on someone’s desk on my way out the door. I packed everything up carefully, wiping it all down and trying to make it look as good as new. The guy I was meant to leave my Macbook ($1200) and my headphones ($350) with wasn’t even there. There was no security, no oversight, no locker and no inventory list. Nobody had walked me away from my desk to keep me from stealing pens or staples or secrets. Nobody watched me at all, or asked to check my bag on my way out the door. Because they have never been poor, they had no idea what I might do. Why would I steal, when everyone clearly has enough? What even is scarcity? Why drink yourself to death tonight when there’s another sponsored event a week from now? Why eat like there will never be enough, when there has always been more than enough?”
“This post will walk you through the performance tuning steps that I took to serve 1.2 million JSON "API" requests per second from a 4 vCPU AWS EC2 instance. For the purposes of this recreated quest, we will ignore most of the dead ends and dark alleyways that I had to struggle through on my solo expedition. Instead, we will mainly stick to the happy path, moving steadily from serving 224k req/s at the start, with the default configuration, to a mind-blowing 1.2M req/s by the time we reach the end.”