Provocative title! Substantive points to back it up? > Early versions of a product are often prototypes that are intentionally meant to be rewritten or heavily

Provocative title! Substantive points to back it up? > Early versions of a product are often prototypes that are intentionally meant to be rewritten or heavily refactored in the near future. Cool, but surely a check of basic physics is in order for certain ideas? (see: uBeam) > Because getting a product in the hands of users is a top priority, even great engineers will intentionally take shortcuts and accumulate technical debt in order to launch sooner. Agreed for the most part. I see technical debt as incurring a price to get to market faster. Sometimes the price is too high, though I'd wager 9 times out of 10 it's the product-market fit that would kill a company faster. > The ability to scale with success is important, but designing products for high scalability from Day 1 is usually a mistake. ("Premature optimization is the root of all evil." -- Donald Knuth) Sure, but I don't think this is technical diligence necessarily. To me, the diligence would be researching whether or not the product/service could scale, either by seeing other examples of similar companies, understanding how AWS works, understanding manufacturing processes, etc. > "CTO" is an ambiguous title at small companies. > Because code is likely to be temporary and the CTO's role is likely to change quickly, it's not obvious what should be measured during technical due diligence. Ok... but can one not measure or research the person (and team's) ability to create technology or manage those who can? > (An aside: in addition to tech diligence having questionable value, many seed stage founders consider it overbearing and passively resist it. Given that engineering resources are scarce and that there are plenty of investors who write $100k+ checks after one or two short meetings, founders often prioritize "lighter-diligence investors" instead of submitting to an hour or two of technical grilling.) Jesus Christ I need to move to California already. > in today's world of SaaS tools, APIs, and cloud infrastructure, most startup ideas don't have significant technical risk. That means technical resources are rarely the cause of success or the reason for failure. That's actually a very fair point. In the specific domain of web product companies that are leveraging the heavy lifting of others, a few Business Bros can get very far. But does this cover ">95% of startups" ? > A quick skim of CB Insights' collection of 150+ startup post-mortems reveals that only ~5% of post-mortems referenced a lack of technical ability/execution. Yes but did none of these startups have any technical due diligence? Maybe they did, and that's why the rate is so low. > But for a typical consumer app or SaaS tool, technical risk is low enough to be ignored. Sure, just double-check that the engineers on the team did more than a coding bootcamp. > On the recruiting side, a technical founder needs to be someone who can do recruiting and someone whom other engineers want to work for. This is especially true in today's hiring market, which is extremely competitive. The best ideas won't go far if a company can't attract enough talent to launch a product. This sounds like a great reason to vet the technical prowess of the team. > Notably, these tests don't require having a technical background. Oh come on now. A GitHub filled with shit code and poor technical decisions on past projects would completely escape you folk. > Instead, they require the ability to read a resume, common sense, EQ, and a few reference checks. Reference checks maybe. Everything else you can get duped. Even reference checks. > If you're a seed investor and you're doing tech diligence on a company, you're most likely wasting your time and the founders' time. Perhaps for your narrowly defined web product startups, which apparently are 95% of startups. But when someone starts talking to you about drones delivering packages, all of a sudden it might be nice to be able to draw some free body diagrams and verify the feasibility of a payload claim. > A well-built product that doesn't solve a problem will always be inferior to an ugly, buggy product that addresses a burning need. Sure, but I don't think this logically leads to the conclusion "technical diligence is a waste of time". Overall a pretty meh post. Focuses on a narrow subset of startups for which, it's mostly true, the tech is a commodity. I don't even consider web products to be "technology" anymore quite frankly.. Not until you need to scale some sort of real-time computing with millions of users and build your own datacenters.