Foy Savas
Principal at Longtech Medical, Co-Founder at Auxoid, Former VC at AlphaPrime
autodidact, factotum, polyglot

Subsidy Chips

  • Don't get hung up on mining chips only making insignificant profits for end users.
  • It's not about making money for end users.
  • The business model is subsidizing connected devices.
  • In this case, so called "mining chips" represent a larger class of "subsidy chips" that could forever change the pricing of electronics.

  • Distributed computing projects like Folding@Home have long established the power of grid computing.
  • But until Bitcoin, it was unclear how grid computing could make money.
  • Bitcoin mining (how Bitcoin transaction get cleared) changed that enabling grid computing to turn a profit.
  • Apropos, this prompted rogue developers to embed mining code in trojan-like games.

  • So, if Bitcoin is the first and not the last example of profitable grid computing, then it doesn't matter that 21.co's first chips target Bitcoin.
  • What matters instead for these chips is only where and why:
    • Where: any connected device.
    • Why: to finance device cost or complementary subscription fees.

  • For example:
    • A new connected refrigerator may come with subsidy chips.
    • It's also notably cheaper than the non-connected models.
    • Of course, the subsidy chips produce income for the manufacturer, but use more power at home.
    • Extra money paid to your energy provider comes to represent one leg on what effectively amounts to the financing of your refrigerator.
    • Finally, if and as your house becomes green energy enabled this cost may never reach your wallet.

  • Long term, if all this plays out, here's what I expect:

Avoiding the Fatal Pinch

  • PG's essay The Fatal Pinch is about startups that have:
    • Raised money and now have high burns.
    • Have not met existing investors' expectations.
    • Need to raise more, but can't because they're seen as failures.

  • PG gives you advice toward getting out of the fatal pinch.
  • Let me help you avoid it altogether by understanding investor expectations.

  • VC is about grabbing future cash flows.
    • Real winners in a VC portfolio yield returns above 20% IRR.

  • The easiest way to model a startup's cash flows is as perpetuities.
    • This is because your revenue should be roughly monotonously increasing.

  • Present Value of a Perpetuity = Dividend / Required Rate of Return
    • Dividend = Present Value * Required Rate

  • Startups don't pay dividends, but if you consider:
    • the dividend as new revenue generated after an upcoming round
    • and the present value to be the money invested during an upcoming round

  • Then you can use this simple test to see if you should raise your upcoming round:
    • Will X in cash enable us to increase revenue by at least 20% of X?
    • If yes, raise.
    • If no, you're setting yourself up for a fatal pinch.

  • Btw, the 20% IRR use here is a low cutoff for success.
    • The IRR of unicorns is closer to 40%.

  • Someone told you "it's about long term cash flows, not short term revenue".
    • Don't let seed stage dynamics set your expectations for later rounds.
    • Institutional VC holding periods just aren't that long.

  • Someone told you "we need to focus on month-over-month growth in \".
    • All startup metrics worth considering are just proxies for cash flow.
    • Even a good cash flow proxy becomes a vanity metric if you fixate on it.

UUM a New Code Metric

  • Fanaticism around writing "clean" code bothers me
    • balance is needed
    • careless code stales development through overwhelming technical debt
    • immaculate code stales development through compoundingly delayed release

  • A spectrum of required cleanliness exists for code
  • Highest-to-lowest required code cleanliness tends to apply as follows:
    • high performance algorithms
    • compilers and hardware drivers
    • core user space applications
    • ...
    • changing business logic
    • changing presentation code
    • unsaved code in your text editor

  • I'd like to define a metric for this continuum
    • (one likely already exists, but unfortunately hasn't bubbled up in popularity)

  • UUM := Uses Until Modification
    • while this metric is independent of business value, it's still a clear factor of business value
    • the UUM of jointly modified code should be equal to the greatest UUM value of any particular code being modified
    • code with greatly differing UUM values should be separated (by the way, this is what I understand to be the high level rationale behind design patterns like MVC)
    • the lower the UUM, the less you should worry about code cleanliness
    • no matter the UUM, code should be reasoned as functioning properly
    • if use of the code grows (and optimally it does), later releases entail higher UUM

Change from a Distance

  • I can't help but think these two quotes related:
    • "Give me a place to stand and with a lever I will move the whole world." – Archimedes
    • "Real artists live their own lives in parallel. It’s the artist who transforms his times." – Pierre Bergé

The Last 512 Generations

  • Generations often better meter human history than years
  • That said,
    • smartphones were first manufactured 1 generation ago
    • Internet protocols were first standardized 2 generations ago
    • electronic computers were first programmed 4 generations ago
    • telegraphs were first commercialized 8 generations ago
    • calculus was first developed 16 generations ago
    • mechanical clocks were first fashioned 32 generations ago
    • books were first printed 64 generations ago
    • coins were first minted 128 generations ago
    • writing was first systematized 256 generations ago
    • farming was first practiced 512 generations ago