I am not a startup

Or, at least, I’m not a startup anymore. This is a startling realization for me, particularly given my deep Silicon Valley background, but is critical to how I think about my time.

I am not a startup
Photo by Héctor J. Rivas / Unsplash
This piece was written as part of my 2022 Q2 and Q3 Review.

Or, at least, I’m not a startup anymore. This is a startling realization for me, particularly given my deep Silicon Valley background, but is critical to how I think about my time.

Somewhere in the last ~year my situation changed significantly. Financially I’m in a relatively stable spot, and with cash reserves, investments, and a trickle of part-time income from my coaching role with Spike Lab, I shouldn’t need to search for purely money-making opportunities for a while.

That is to say that the nature of my struggle changed somewhere while I wasn’t looking. Somehow it no longer seems existentially threatening to have a product fail the way it might be for a true startup. If Midana failed tomorrow, I wouldn’t be screwed. I’d probably feel bad about having spent so much time on a dud, and I’d take some time to sulk. Eventually I’d get over it, though, and then I’d get right back to work on something else. I probably wouldn’t go find a “real” job. Nothing much would change.

Hell, if I struck it rich with Midana tomorrow still nothing much would change. I don’t know that I want to work on Midana and only Midana for the next 5 to 10 years of my life—too little of my soul is captivated for that. If Midana made me a rich man, I’d feel vindicated about the time I spent on it. I’d probably take some time to celebrate. I might buy a few nice things. Eventually, though, I’d get over this, too. And you know what I’d do then? Yup. I’d get right back to work on something else. Midana would stick around—I’d continue improving it as I see fit to. But I’d probably start working on something else in parallel.

My vision for the future seems to have changed. Sure, maybe one of these days I’ll accidentally birth a unicorn and I’ll be forced to make some hard decisions. Barring that, though, I’m starting to imagine myself building, maintaining, and operating a whole fleet of products, potentially all on my own. It’s an ambitious idea. I’ll admit to feeling a bit daunted by the challenge. But it’s exactly my kind of crazy :). I’ve always been in this for the Ironman, not the 5k fun run.

As the long-term goal comes into focus, I’m realizing that I’m operating all wrong. Once again I’m forced to unlearn and rethink many of the things I learned in Silicon Valley—in many ways the paradigm no longer fits.

By necessity, VC-backed startups are in a race against time. They have to sprint from milestone to milestone praying that they can eke out enough success to prove their worthiness for continued investment—for continued existence.

As a result, an early-stage startup is forced to cut corners, particularly where technology is concerned. You’d have to be crazy to invest too deeply in a long-term future that you may not survive long enough to see, and you can’t afford to spend precious and limited engineering resources on things that aren’t mission critical. Thus the engineering culture almost always values speed over robustness, at least until robustness starts to affect speed (spoiler: it always does, eventually). I spent most of my career working in, for, and as startups, and this is the story that I’ve seen, lived, and perpetuated over and over again.

Most startups sprint to create one product of any value. They can only afford to plan, build, and architect for a single product because if they fail, they die. They may dabble, they may experiment, and they may pivot, but ultimately they are all-in by nature.

I am not a startup. I don’t die if one product fails. In fact, I already know that I want to build n products, and I hope for n to be large. I’d be crazy not to invest in a future I’m certain I want to bring about. I could frenetically build n products startup-style, but the resulting mess would be harder to maintain and harder to scale, especially in parallel.

Instead, I need solid, common, foundational bricks that can be laid down for every product. I need to limit the amount of effort I duplicate in the long-term, both in building and maintaining products. I need to think more deeply about patterns and architecture. I can afford to sacrifice short-term speed for the robustness that translates into speed in the mid- and long-term.

Don’t get me wrong, from a product standpoint, I do still want to operate like a startup. I’d like to stay hungry. I’d like to stay lean. I’d like to understand my users before I create things for them. I’d like to release early and often. I don’t want to build monolithic products full of untested features I have no idea whether or not anyone will ever use.

From an engineering perspective, though, it’s time for a paradigm-shift. I’m tired of writing variations of the same things over and over. I want to write solutions once, and use them everywhere. I’m finally in a place in my career where I can feel that I have the power to realize that. And I’m finally in a place in my life where I have the luxury of time to try.

Subscribe to Daniel Chiu

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.