14 ms·

Startup Technical Diligence Is a Waste of Time

287 points by lpolovets 10y ago

thomasrossi 10y ago
I relate with most of the points, also from my experience with due diligence (bought by the vc from an external consulting company) they cannot say all is good, since if it fails then they could be blamed, they cannot say all is bad otherwise you'd just need to sell once and you prove them wrong, so pretty much the outcome is always in between. That due diligence was really not worth the money spent.
payne92 10y ago
While intensive technical due diligence at the seed stage is rare (for the good reasons cited in the note), I wouldn't make a unilateral assertion that it's a waste of time. Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence). I find a light / informal discussion about technology to be really helpful. What's been built gives a sense of the real (vs stated) tech skills on the founding team (we all tend to reach for what's most familiar). For example, if the first version is built on the Microsoft stack, you might want to know that. Finally, code meant to be thrown away always hangs around longer than expected.
- peterbonney 10y ago
  "Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence)." The article specifically addresses this: "There are, of course, some companies with real technical risk: SpaceX, Zoox, Rigetti Quantum Computing, etc. But for a typical consumer app or SaaS tool, technical risk is low enough to be ignored." And of course it never hurts to ask a few questions - you can quickly find out if the technical team is on-the-level without examining their entire commit history (and as he suggests, on-the-level can mean lots of different things in the context of an early stage software company, not just "10X engineer"). I think his point is that obsessing over technology when the technical challenges are insignificant compared to the business challenges is silly, and likely to lead to lost investment opportunities.
  - p4wnc6 10y ago
    Doesn't this mean, full stop, that good developers should not even consider working for such start-ups? You know from day one that your contribution is not valued, and that if you are hired it's because management viewed you as a bargain basement sort of developer who could get the (easy, insignificant) tech job done and no more. I don't see how the premise of the post can coexist with the phenomenon of clamoring to "only hire the best" and obsessing over e.g. HackerRank interview submissions or something. Also, what of acqui-hires? I've seen and been part of some big corporate acquisitions in which a company buys a start-up that is not doing good work and has a stupid product, solely to get their 10-person engineering team and then drop the other employees. In which case that start-up succeeding mostly by not giving a shit about any actual business problem and just hiring a group of excellent engineers.
    - peterbonney 10y ago
      "Doesn't this mean, full stop, that good developers should not even consider working for such start-ups?" No, I don't think so. Just because you're not doing novel computer science or engineering doesn't mean you aren't doing interesting work, or that your work isn't valued. I think the point is that from an investor's perspective you aren't going to learn much from poking around the code and saying "why'd you use this library rather than that library?" I can offer my own personal perspective on the value of developer talent as a quasi-technical (I'd say on a good day I'm maybe a 0.9x engineer, most days more like 0.5x :) co-founder of a SaaS company that definitely isn't doing any ground-breaking computer science. To me, the value of a top-flight engineer isn't that they are going to overcome a problem so hard that no "normal human" (like myself) could ever solve it. It's that they are able to look at the fairly vanilla problems we are facing (usability, scalability, etc.), see better solutions than I see, implement them faster and more robustly, and avoid pitfalls that are obvious to them but aren't obvious to me (because I lack the experience to spot them). Maybe we could hire someone cheaper to do the same work, but it would be half as good, take twice as long, and be four times harder to build on in the future. So to me, having top-notch developers is a business issue, not a computer science issue. Let's face it, even at companies that are doing novel computer science, most of the work that most engineers do is going to be pretty mundane from a CS perspective: Google may be doing amazing work at the boundaries of technology, but someone still needs to maintain the mouseover behaviors in Gmail... Which is not to say that development work not at the boundaries of technology is inherently uninteresting! I think most people who code (even sub-par coders like myself) get off on a lot of things other people would consider pretty boring, like (in my case with some work I'm doing right now) figuring out a reasonable stop-gap way to manage state when creating a new object that requires putting some hooks into multiple third-party APIs. This is not a novel problem, but there are a lot of ways to solve it, and it made me happy to implement one that is simple and fails in a reasonable way even if it isn't maximally flexible/robust. Of course, not all founders/managers/executives "get it". And those that don't may opt to just hire the cheapest while paying lip service to hiring the best. But I think (shamelessly tooting my own horn) that people with some experience in the weeds, or with personal exposure to the range of engineering talent out there in the world, recognize hiring sub-par talent is a false economy. And of course there are all sorts of other factors that go into choosing where to work: can I stomach working with these people every day, does the job fit with my personal life, is the executive team technically illiterate and prone to giving us impossible tasks, etc. TL;DR: Engineers can be highly valued even when their work isn't "novel" to the point of requiring technical DD at the time of an early stage investment (there are those of us out there who recognize the value of craft), technical work doesn't have to be groundbreaking to be interesting, and making the choice to hire top-notch talent is usually a business decision, not a technical one.
- josh_carterPDX 10y ago
  I was waiting for someone to mention Theranos. The challenge there was that Elizabeth wouldn't share the tech. With anyone. They shouldn't have gotten a dime in funding.
mbesto 10y ago
I do technical diligence for a living so I feel like I should chime in. 1. Many of my clients are unsophisticated when it comes to technology, regardless of whether they buy a "tech company" or not. Yes this includes both PE and VC clients. When a PE firm makes an investment in a tech company (and take 51+% of the company) they need to be confident the technology will hold up. About 90% of my work is PE, with the other being 10% in VC (mostly Series A +). Believe it or not, many commercially successful companies do not always use "today's world of SaaS tools, APIs, and cloud infrastructure". And even if they do, just because you use AWS doesn't mean you've setup a VPC correctly, you have multi-az setup, or sensitive data isn't encrypted at rest. These can have potentially costly (i.e. lose customers / brand recognition) consequences. (case in point -> https://news.ycombinator.com/item?id=11999712 https://news.ycombinator.com/item?id=11999712 ) 2. If you're a VC, and especially an early stage one, then no, due diligence isn't necessary. At all in fact (including finance, etc). You're thesis isn't aligned with careful analysis, it's spray and pray, so diligence isn't a worthwhile endeavor. I wonder if something prompted the author to write this or if it's just a random rambling. I thought it was pretty well understood that doing diligence at the angel/seed stage was almost unanimously worthless. 3. Tech due diligence at the later stage of VC, if done right, has more to do about scalability of operations and processes then it does about the specific tech. When you put $50M into a company, spending $50k is a pretty good safeguard. 4. Tech diligence, by the right partner, could have certainly identified risks at Theranos or uBeam (assuming there are some there), but that's precisely what it is - risk. I'm pretty confident the investors in these companies understand the risk, they simply just don't care, because the potential outcome will return their whole fund and some. Do this 10 times and one bet is bound to pay off. 5. I always try to remind entrepreneurs, VCs are finance professionals, not tech professionals. While some may have made their way into VC because of their previous technical ability, there are also many who do not. And just like when you stop coding for 6 months and get "rusty", so do previously technical able VCs who get older and out of touch.
- yborg 10y ago
  I would hardly consider "spray and pray" to be a "professional" approach to investing, although this aligns perfectly with my experience with many VC firms. The key skill there is sales ability with the types of investor that also allocate large amounts of other people's capital on the basis of gut feels and lunches at expensive eateries.
emblem21 10y ago
How to run a startup in 2016: * No homebrewed tech allowed. It's too "complex" * We should only use off-the-shelf libraries and SDKs because bar-to-entry isn't a real investor risk ("Just trust me, I'm a charismatic CEO who played golf a few times with the best friend of the college roommate of the guy who helped the guy close Series A for Baidu") * Soft skills, soft skills, soft skills! Smiling > coding * I don't know what technical debt is, but I'm sure we can safely rewrite our core product from scratch in between Series B and Series C. Product owners, customer support teams, and quality assurance re-on-boarding is a money problem, not a leadership problem. * Security audits? I have no idea what those are, but lets incorporate IoT into our product suite somehow. That seems hot right now to VCs. Bubbles. Bubbles everywhere.
- JoeAltmaier 10y ago
  Re: No homebrewed tech Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not smart enough to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.
  - ben_jones 10y ago
    "Can that corner be cut?" "Well technically yes, but..." "Good, cut it" .. 2 years later .. "How could we possibly have been hacked! We had security right?!" .. points behind at ten miles of cut corners ..
    - moron4hire 10y ago
      The problem was that the corner could not actually be cut. If the answer is, "yes, but we won't hit our performance targets," then the answer should have been "no, we won't hit our performance targets." Your management can't help it that you said it was possible.
arcanus 10y ago
Anecdotally, I'll mention that for the two founder level pitches/seed raises I've been involved in, there was absolutely no technical diligence at all. Nor was there really any technical discussion at the YC pitch (we did not get selected, admittedly). I've always conjectured that this is why vetting the team is considered such a critical element. For instance, I have a Ph.d. and so I've found people just assume I know what I am doing in terms of tech and algorithms. This can be a disadvantage when I want honest feedback, actually. Most VCs are much better equipped to discuss the business related aspects than anything technical. In fact, I would be hard pressed to evaluate most start-up technology outside my fields of study, because it becomes so specialized so quickly.
- vidarh 10y ago
  My experience is that technical due diligence is much more likely to be thorough in cases where someone is acquiring a slower growing, more established business. If you're buying a startup, chances are you're buying into the idea and the team much more than the current technical solution, and if you're right the margin for error on the cost side are huge, so you can afford taking the risk of having spend extra cleaning up a messy code base. Apart from rare areas where solving a particularly hard problem is part of the value, the underlying tech is a distraction if the team is good and the idea is good. But if you're buying a "boring" established business with a moderate growth rate for its market position and revenue, whether or not you'll end up spending 20% on top of the acquisition cost over the next year fixing crumbling infrastructure suddenly matters a lot more.
- ridgeguy 10y ago
  My anecdote tracks with yours. Ours was a materials startup, no code involved, but totally dependent on a then-new type of plasma chemistry. Intel Capital brought over their Wall of Faces (mostly technologists) for a "tech DD meeting". They asked almost no tech questions. All the questioning went to our business model, transition from custom proto to volume mfg, and building protectable IP. Our tech PowerPoint stack remained unrun, and I was very glad we'd stayed up all night doing 5-year financial pro formas. I.C. invested. But I was surprised at how little they vetted our technology before signing the terms sheet.
jacquesm 10y ago
The main reason why investing in start-ups is hard is not because of the ones that die, it's because of the ones that remain afloat but only barely so.
theseatoms 10y ago
Because odds are high that you'll fail, in which case you default on your technical debt.
- grandalf 10y ago
  Technical debt is a temporary leveraging to achieve productivity at the expense of ultimate quality. So assuming the business failed for non-technical reasons, or if the business succeeded, both are examples of why to use technical debt as a strategy. The case for not acquiring technical debt is when a business fails because it can't pay down the debt or fails because it is bitten by the debt in some way.
  - afarrell 10y ago
    "Technical debt" is actually an unhedged call option
    - theseatoms 10y ago
      Exactly. (An unhedged short call option to be more precise.) And a startup is a long call option. So a startup can bootstrap itself to a certain level of success by mortgaging its higher-upside states. What would this look like in practice?
      - grandalf 10y ago
        It happens all the time, not just via technical debt but also via management debt and various other leveraged choices. For a young startup to be successful, it needs to offer evidence to investors that additional funding will lead to exponential revenue or market share growth. Those are the hard things. Building code without taking on technical debt is actually easier than building it with just the right amount of technical debt for the business's uncertain future. In my opinion, the kind to avoid is sloppy, non-strategic technical debt, such as what you often get when developers are burnt out and need to complete aggressive milestones so that management will be satisfied with the rate of development. This debt tends to break modularity and lead to bad system design, whereas stategic debt can simply mean building a quick and dirty black box for desired functionality that has clearly defined interfaces that can likely remain once the debt is removed and will not necessitate a rewrite of other modules. Similarly, management debt can be strategic if it teaches young or inexperienced managers useful lessons that they grow from and apply as the company grows. But management debt that results in burnout and high turnover also gets rid of the valuable lessons and lets someone with slightly more experience make some of them again.
chris_va 10y ago
There isn't a distinction made here between product+technical diligence (e.g. is something possible to build given the funding sought) and execution+technical diligence (e.g. is the team building it the right way). I would argue that the former is always important. I agree that the latter is less important, but with some caveats. The number of engineering hours put in during the first year is going to be a tiny fraction of the second year, etc, so tech evaluations will change drastically over time. The author argues that this makes them a slight waste of time. However, I've been very successful in using rough technical diligence in the early rounds as a proxy for measuring the decision making abilities of founders. This is hard to measure, so I still find technical diligence useful. You have to know the constraints they are working under, and not hold technical debt/differences of opinion (like homebrew vs stock) against them, the purpose is different. Just my 2 cents.
DonHopkins 10y ago
I understand the reluctance to evaluate a startup based on a prototype, but there are prototypes that are designed from the start to be incrementally refactored and replaced, and there are prototypes that are monolithic dead ends in hell. There are people who use technical debt to get to the next level so they can repay the debt, and there are people who use technical debt like Donald Trump uses bankruptcy court to screw people who trusted him.
lima 10y ago
And then you get hacked and your customer data is leaked.
20andup 10y ago
"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)" He is using the quote wrong. A scalable product and an MVP are build entirely differently. Both scalable product and MVP can have technical debt, but I wouldn't say the scalable product is the optimized version of the MVP.
eldavido 10y ago
What about cases where "poor technology execution" is the root cause behind "we didn't move quickly enough" or "we didn't build the right features" because you didn't move quickly enough, and the product architecture made change too difficult?
hywel 10y ago
"Most startup failures were caused by building the wrong product, or lacking strong sales skills, or not having a viable business model" <- the first one of these is the biggest cause of startup failure, and is technical. Startup technical diligence needs to check for a minimum level of ability and beyond that, ability to find the right direction to build in. The idea that what product you build is not the responsibility of the technical team is almost certainly why you think there's no point in doing technical diligence.
zxcvvcxz 10y ago
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.
wslh 10y ago
Probably most of the time technical due diligence is not necessary but this is not my experience working with startups where the commercial success is strongly connected with a technical solution. Some examples: i/ An startup wants to enter as an automatic security escrow in a Bitcoin multi-signature wallet (please forget for a moment this is about a sector with too much hype). If you do a basic analysis you will realize that multisig wallets are well supported but there is a missing link: there is no standard out-of-band way to setup these wallets and you should do many manual steps. These manual steps add a lot of friction for user onboarding and undermine the startup success. ii/ A security startup wants to integrate their app inside Microsoft Outlook via an add-on. They are confident because they look at the API and it seems you can extend Outlook but they discover very late that a specific feature can't be achieved. iii/ An startup wants to virtualize Windows applications (e.g. VMware ThinApp) using binary instrumentation and/or filtering drivers. They will find that some few but critical applications (e.g. legacy Java applets) require an ad-hoc solution for specific issues that significantly increases the development costs.
tobyc 10y ago
Technical due dil doesn't just need to look for poorly architected systems and bad code. It should also look for code that's prematurely optimised and over-engineered. If an early stage team is building a massively complex microservices based product, using a new type of database and deploying it via kubernetes — where a Rails CRUD app on Heroku would easily satisfy requirements for years. Then someone seriously needs to ask the question as to whether using bleeding edge tech is necessary, and whether it will impact the ability to iterate and hire.
- LoSboccacc 10y ago
  Due diligence is less about code and more about robustness, licensing and operating costs. Common questions are what would happen if the data storage failed/datacenter went dark and do you have an up do date list of all libraries used, yes including copypasted stuff out of stack overflow. Due diligence != code audit. Sure if you get in that level detail for the td then it's a waste of time, but otherwise knowing that the tech team is not sitting on a landmine it's kinda important
- ilaksh 10y ago
  'Massively complex' -- ok I agree on that part, you want to avoid that. But as far as microservices, its totally possible to do that in a way that doesn't add a bunch of complexity. As far as new databases versus relational, a new database can make it easier to iterate (no/easier schema migration) and hire (can't prove this but I believe there are many people like me who got sick of relational dbs after many years and are just happy to deal with different types of problems.) Something like kubernetes if done correctly can really help smooth things over because many apps have specific external dependencies which without a tool like that are hard to automate 100% and so create drag for new hires especially.
vasilipupkin 10y ago
I actually disagree with this. Of course, building the wrong product and having poor sales/marketing and all that other stuff matters a lot, BUT if the startup's technical people are weak and cannot quickly iterate, then this startup will bleed money really fast, while not being able to quickly modify the product as needed. So, I would say, you need to do technical diligence on the founders, but not necessarily on their code
- ilaksh 10y ago
  I've worked one at least two or three little startups where they were iterating fast but the code never really worked (core functionality broken) and the non-technical people' didn't even find out until I came in to 'fix a few bugs' and found a pile of spaghetti which could not possibly function correctly. So just be careful how you define 'iterate' and how much emphasis you put on 'quick'.
  - vasilipupkin 10y ago
    exactly, so that's what happens when a startup tries to iterate quickly, but doesn't have the right technical people who can pull it off.
franciscop 10y ago
> "The ability to scale with success is important, but designing products for high scalability from Day 1 is usually a mistake." In my opinion, and having helped dozens of startups (friends or work), this is the biggest mistake I've seen. Engineers love to make things that scale, while business logic imply to leave it for when it is actually needed. I'd say it's #1 waste of time in a startup (in Spain). Also, when doing so mostly it's done without measuring anything, just doing it "for the sake of it".
heme 10y ago
In my experience as a software developer... Technical diligence, and technical debt, only matter in the way they affect revenue & growth. Technical people are usually more acutely aware of how they will be crushed by the current debt they are accumulating. Business is more acutely aware of how the business will fail when growth goals are not met. Both things should be everyone's concern. Striking that balance, and communicating serious pitfalls and shared goals should help give perspective.
kang 10y ago
The world very soon is going to be the opposite of it, where you just release software and wait. An anonymous person launches a company without any capital, registration, employees, marketing, sales, which is ipo from day 1 and the founder is a billionaire just by releasing a piece of code. With blockchains it is possible to do so.
lpolovets 10y ago
(I'm the post's author.) Just to clarify a little bit, since I didn't make this explicitly clear in the article: there are certainly questions about the technical side that are useful. One example from the blog post is trying to understand if the tech team's experience lines up with what they're building. If the founders are 2 infrastructure engineers who are trying to build a social app, or if they're mobile devs who are trying to build a streaming database, then that's a yellow or red flag. Another example: I've gotten a lot of value out of drilling in a tiny bit when people make bold technology claims. If someone says they've developed cutting edge ML, they rarely expect an investor to ask about it. When I ask them what "cutting edge" means, if I hear words like linear regression or decision trees, then my bullshit detector goes off -- but not for technical reasons. It's not bad at all to use simple ML models, what is bad is misrepresenting your tech, because then I start wondering what else you're misrepresenting. But for most (seed) VCs that I've met, technical diligence means asking an engineer they're friends with to talk to a CTO they're thinking of investing in. The engineer asks about system design, infrastructure decisions, deployment environment, coding practices, etc. and then tells the VC if they think the tech stack is robust. (VC: "Ah, they're using AWS and Redshift? That sounds modern. Thumbs up!") For many, many startups (SaaS, mobile apps, ecommerce, etc.) I think this type of diligence is basically useless for almost all seed stage companies.
- mgrennan 10y ago
  Yes - there are many RED FLAGS. One is they skip all the hard parts(Tech Diligence), like security and and are all ready selling to the public.
- dnautics 10y ago
  As a cofounder of a technical startup (biotech), and a part-time contractor on another technical startup (hardware): I think the main points in your article are right, but maybe retitle it "startup technical due diligence is (usually) a waste of time"?
andrewfromx 10y ago
but there is some minimum required. You want to avoid situation where you are investing in a team that litterally does not know what they are doing and are scamming you for money. Zero tech dilligence can't be the answer. But it should be pass/fail not graded for an A+.
dkarapetyan 10y ago
Sigh. This article just sets up a bunch of false dichotomies. You can ship good code and put a product in the hands of people at the same time. You can also ship shit code and do the same. It obviously takes more expertise and diligence to ship the better quality code but it's not like taking 5 extra minutes before every commit is gonna break your business if you didn't have a proper business model to begin with.
- gedy 10y ago
  This. "Go fast!" is often an excuse for putting zero thought at all into sane design or basic layering, which is basically just as fast as doing it the wrong way.
gersh 10y ago
He is looking at obituaries of startups for advice. If you look at successful startups, did they face early technical risk? Google won early by having the best algorithm. Facebook's early competitor Friendster died due to technical issues. It seems less clear at what stage companies like Uber and AirBNB faced substantial technical risk? I'd guess Slack and DropBOx had significant technical risk in early stages. I suppose WeWork probably had less technical risk. I suppose the early prototype's code may not be totally indicative of whether the company can overcome the technical risk. Still, I think you need to evaluate whether the founding team can deal with the technical risk. Technical due diligence isn't about looking for beautiful. It is about looking for an ability to manage technical risk. This includes an ability to hire and manage good engineers.
mgrennan 10y ago
Steve Jobs rule 4 should come in here somewhere. I agree, the first software produced is just a proof of concept and will be re-written. I even believe the only way to write good code is to build it fast in some intransitive language and then throw it away and do it over in something compiled. So I agree with this post except, to become great, you need to know upfront you are just proving the idea and you will do Technical Diligence of the final product and NOT SELL CRAP.
- 20andup 10y ago
  "will be re-written" From my experience working in startups, this is never the case. Crap code persist because rewriting it would take time, they would rather spend on new features. Feature creep sets in very fast.
kafkaesq 10y ago
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. Most startup failures were caused by building the wrong product, or lacking sales skills, or not having a viable business model. The strong presence or absence of amazing engineers was rarely a factor. "Our biggest obstacle to growth, right now? We still can't seem to attract candidates with strong CS fundamentals. Maybe we should crank up HackerRank hazing process from 3 hour-long sessions, up to 5. Because I mean, just look around -- aren't we amazing? At this critical juncture for our venture, surely we can't afford to dilute our crack team with mediocre talent."
- gedrap 10y ago
  It probably counts as failure because of poor management, rather than absence of amazing engineers ;)
  - delinka 10y ago
    That's obviously not the problem: "just look around -- aren't we amazing?"
- 50CNT 10y ago
  I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it). That is total speculation though. Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs. It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays? There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter". But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so. These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.
gedrap 10y ago
> For >95% of startups, however, technical diligence is a waste of time for a more fundamental reason: 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. While it's a tough pill to swallow for many engineers, there's a lot of truth in it. The company I work for (Bored Panda) is a pretty good example of it. I was the first full time engineer, and the company already had 20+ millions of monthly visitors and ~2m facebook followers. Surely, there was tons of technical debt to clean up and uptime was... really poor :)
- econner 10y ago
  > From Google description, "Bored Panda is a leading art, design and photography community for creative people. Our submission platform helps artists and creators turn their stories into." into what? :-)
  - thomasjudge 10y ago
    That's called semantic debt
    - jessaustin 10y ago
      LOL. I will be on the lookout for this now, and I fully expect to see it everywhere.
  - gedrap 10y ago
    Whoops! It happened quite a few times that some artist submitted their work (photos, illustrations, etc), our experienced editorial team polished them and the attention and traffic really kickstarted their career. Here are some selected stories: http://www.boredpanda.com/success-stories/ http://www.boredpanda.com/success-stories/ . Also, I believe, we contributed significantly to the coloring-books-for-artists trend which was quite a thing in late 2015 and sold loads and loads of copies, because I think we were the first major publisher to publish a story about them. Not something world changing, but it's good to know that I contributed in one way or another to actually help some artists :)
c-smile 10y ago
Truth is as usual in between of two polar opinions - in the golden middle. Just hire at least one professional for the startup. He/she will simply not be able to do complete garbage. That's meaning of "professionalism" at the end, right? Good Experienced Professional Engineer also understands real life compromises. For him/her it is not that hard to make initial architectural decision that allows to implement something fast but has a foundation for future expansion. Usually it takes about couple of days for the person that "been there, seen that" to make good architectural decision. Startups: "We are not so rich to buy cheap things". Well, at least CTO / architect.
biot 10y ago
What's the typical cost of bringing in someone to investigate and write up a technical due diligence report?
mizzao 10y ago
Is the article arguing that ability to execute is not a distinguishing factor for startups? Or just that non-technical execution is more important than technical execution?
fillskills 10y ago
Anything that starts with "For the most part, I was wrong." gives me a boost of trust and respect for the author of the post. It is hard to admit your own fault and it is much harder to admit to it publicly.
kalman5 10y ago
Flawed logic all around. First 4 points: 1. Early version of a product especially when in hurry with features delivery are going to be "temporarily definitive" implementation. As soon a feature reached the production the code has to be considered "legacy code" 2. Technical debt is a choice, and when you have too much of it you enter in a spiral of death. 3. The quote from Donald Knuth is only a poor excuse to slack and to justify bad development habits. Writing efficient code most of the time doesn't require more time than not (choose the right container or the right algorithm for example). 4. It's a so generic statement that adds no info at all. "For >95% of startups [...] That means technical resources are rarely the cause of success or the reason for failure." that's the best statement of the whole post that more or less sounds like this: "In Africa 90.3% of people die due to: nutritional causes, hearth disease, cancer and diabets, why send over there good doctors then?"
nabla9 10y ago
It seems that the Internet and mobile technologies are established technologies at this point. Most internet startups are not technology driven. They are all about marketing, customer relations, service and business as normal. MBA's are more important than engineers. High-tech startups still exist but they are not the norm.
vinceguidry 10y ago
Solid engineering may not be needed from a business standpoint, but good engineers want to work on solidly-engineered products. If you've got a pile of hacks, and you keep telling developers they can't take the time to clean it up because business needs come first, then speed of feature implementation is going to slowly degrade and eventually grind to a halt. The good ones you'd have tapped to clean everything up will be long gone by the time this happens.
xenadu02 10y ago
Technical debt can absolutely kill a company if you have competitors who are fast-following while already knowing where the map will lead them. They have a chance to avoid some of the problems. I would suggest this isn't addressed in post-mortems because most of the time customers won't or can't tell you why they chose a competitor, sales doesn't know or doesn't communicate that to engineering, or engineering is too dysfunctional to act on the information and has a vested interest in justifying their own decisions. Sometimes it isn't even tech debt per-se, just bad decisions that make implementation of critical features much more expensive... sometimes so expensive everyone feels it would take too long to implement so it isn't done.
wyc 10y ago
Another supporting argument for this is from The Innovator's Dilemma: disruptive technology (startups tend to leverage this) tends to be constructed from pre-existing and commercially available components. Think Snapchat, Instagram, tablets, digital pianos, and all-in-one PCs. All the major building blocks had already existed at the time of invention. This is in stark contrast to sustaining technology, which tends to require expensive teams of scientists and engineers to make incremental improvements to an existing business line, making it palatable only to large organizations with deep pockets. Samsung can afford to have its physicists to find tighter SSD data packing. Google can afford statisticians to tune their search algorithm with complex models. Startups simply can't, nor should they!
- danieltillett 10y ago
  Startups can do this, but they need to have very, very good people and go niche. The are millions of smallish niches out there that can be attacked with a sustaining approach provided you have the right people. The problem is really good people are hard to find and most niches are too small to support investor funding.
claudiusd 10y ago
As a technical founder having gone through a few VC rounds, I was initially surprised by the lack of technical diligence but eventually came to the same understanding as the author: product-market-fit and sales/marketing execution make-or-break most companies. I would add though that the impact the technical founder has on the design of the product and the quality of execution is immense and often hidden behind the non-technical founder selling the company to VCs. Good technical founders do a lot more than code. If I were a VC, I would look for teams with technical founders that have skills extending into product management, people management/recruiting, and operations.
LordHumungous 10y ago
>only ~5% of post-mortems referenced a lack of technical ability/execution I'd be curious to see how he arrived at that number. In my experience poor technical execution manifests itself as other problems, like slow time to market, poor user experience, or even building the wrong product.
erdevs 10y ago
The headline for this post is far too broad. More accurate would be to say that "very early stage startup technical diligence is usually a waste of time". That is often the case, for many of the reasons the author outlined. Later on in a company's life, however, technical diligence becomes very important. If anything, VCs should do a better job of it. Countless companies have struggled, stalled or failed because they didn't become aware of or address technical issues early enough and scaled the business side too far out in front of what could be managed technically. This gets your company upside down fast, and in very difficult to unwind ways. Customers become dissatisfied at instability and lack of rapid improvements. Internally, strife between revenue owners and technical owners can easily increase as tech tries to balance delivering new funcitonality and addressing old technical debt. After you find product-market fit and start really scaling-- ie after the early stage-- technical diligence should be a much higher priority than it currently is, for both VCs/investors and for company operators within their own orgs. Better technical assessments of issues and opportunities would serve most startups very well.
graycat 10y ago
It appears to me that the OP is making a very serious, fundamental mistake: He keeps talking about "most" startups. Alas, in shockingly stark terms, as a VC he is quite definitely, necessarily, in very strong terms not looking for "most" startups. Instead, he is looking for exceptional startups. How exceptional? A few or so each decade. What is true for most startups is no doubt close to irrelevant for the exceptional startups he is looking for. Sure, due diligence is not important for lemonade stands, but it was just crucial for, say, the Lockheed SR-71. And for any startup that is using new, advanced, original, powerful, valuable technology, proprietary intellectual property, barrier to entry, technological advantage, due diligence stands to be crucial for, say, estimating the exit value of the company. Sure, a lemonade stand may have traction growing rapidly right away, but it will never have much exit value. Moreover, don't do due diligence on just the code or the architecture but also on the crucial core technology, e.g., some original applied math. We're talking theorems and proofs here, guys, maybe with some pure math grad school prerequisites missing among nearly all chaired full profs of computer science. Did I mention technological barrier to entry? Uh, again, we are looking for the exceptional, and that may look different from the "most".
- FiatLuxDave 10y ago
  This. Upvoted. Does anyone have the data to do the math and see what the difference in ROI is between startups in general and startups which a) should have technical due diligence done and b) which have or would have passed tech due diligence? Maybe we could call these something like "tech startups" to distinguish them from the others. :) It would be good to see how much delta exists between these two different pools of startups. This would be a fairly easy filter for VCs to apply.
  - graycat 10y ago
    Would be good. In the meanwhile, pretend you are the Johns Hopkins University Applied Physics Lab (JHU/APL) working for the US Navy, and they have explained that for their nuclear armed, submarine launched intercontinental ballistic missiles they have one heck of a navigation problem. They tried inertial navigation but are not pleased with it. So, some physics guys thought about some satellites sending out signals, the Doppler shift, etc. Some back of the envelope physics was some convincing due diligence. The system was built and deployed as planned, and a receiver on the roof of the lab routinely navigated itself within one foot. No question. No doubt. Worked great the first time. Disclosure: Have to track the satellites quite carefully and update the data on their orbits frequently, and the JHU/APL had a group doing that. At one time I was a programmer, on the fast Fourier transform with passive sonar data, in that group and heard the stories. There are many more examples where some such applied math/physics, etc. worked great. The due diligence was carefully done, and the batting average for the projects was terrific. Instead of empirical pattern matching, just do due diligence on such projects one at a time. That's what the US DoD has long done. E.g., look at that truck with some long tubes on the back the US just deployed to South Korea. Each tube has a missile that can get up to altitude like right now and hit an incoming warhead. So, given several warheads and several missiles, how to assign missiles to the warheads? There's some nice applied math there. And don't have to wait for a pattern of nuclear wars to know that the math will work. Maybe the lack of enough data for pattern matching is the bad news, but, then, the good news is that same lack of data -- we're talking greenfield here, guys! To heck with the pattern matching: Instead pick a problem, one that with the first good or a much better solution enough customer/users will care enough about to yield spectacular revenue and earnings. Then, use applied math, physics, etc. to get the crucial core of such a good solution. Write the software. Go live. Get publicity. Please the target audience. Smile on the way to the bank. The core tech permits better or first good solutions to challenging problems, gives crucial technological advantage, barrier to entry, proprietary intellectual property, etc. But, as for the JHU/APL project for the US Navy and many more US DoD projects, have to do the due diligence one project at a time. Sorry 'bout that.
lifeisstillgood 10y ago
I naively assumed this article would be saying "don't be diligent in adhering to software quality in your startup" not "when investing don't worry about the quality of the software - it's a numbers game" This is one more example of how what's good for the VC (with a large portfolio) is not necessarily good for the startup (with a portfolio of one)
rywalker 10y ago
Great post Leo. Most startup "diligence" is a waste of time, usually just investors checking the box after they've already made a decision.
dreamcompiler 10y ago
This article re-confirms that most of the money in Silicon Valley is being made without much real technical innovation. Not a surprise, but I still find it depressing.
abc_lisper 10y ago
All aspiring programmers, pay heed to this. If you want to become a good programmer, startups are thus a waste of your time, at least the ones that think like this. The devil/fun is always in the details. Deprive me of that, I will never work for you.
cakeface 10y ago
Dealing with technical debt is the privilege of a successful business.

287 points by lpolovets 10y ago

I relate with most of the points, also from my experience with due diligence (bought by the vc from an external consulting company) they cannot say all is good, since if it fails then they could be blamed, they cannot say all is bad otherwise you'd just need to sell once and you prove them wrong, so pretty much the outcome is always in between. That due diligence was really not worth the money spent.

payne92 10y ago

While intensive technical due diligence at the seed stage is rare (for the good reasons cited in the note), I wouldn't make a unilateral assertion that it's a waste of time. Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence). I find a light / informal discussion about technology to be really helpful. What's been built gives a sense of the real (vs stated) tech skills on the founding team (we all tend to reach for what's most familiar). For example, if the first version is built on the Microsoft stack, you might want to know that. Finally, code meant to be thrown away always hangs around longer than expected.

peterbonney 10y ago
"Some startups ARE technology driven (I bet the Theranos investors wished they did more tech diligence)." The article specifically addresses this: "There are, of course, some companies with real technical risk: SpaceX, Zoox, Rigetti Quantum Computing, etc. But for a typical consumer app or SaaS tool, technical risk is low enough to be ignored." And of course it never hurts to ask a few questions - you can quickly find out if the technical team is on-the-level without examining their entire commit history (and as he suggests, on-the-level can mean lots of different things in the context of an early stage software company, not just "10X engineer"). I think his point is that obsessing over technology when the technical challenges are insignificant compared to the business challenges is silly, and likely to lead to lost investment opportunities.
- p4wnc6 10y ago
  Doesn't this mean, full stop, that good developers should not even consider working for such start-ups? You know from day one that your contribution is not valued, and that if you are hired it's because management viewed you as a bargain basement sort of developer who could get the (easy, insignificant) tech job done and no more. I don't see how the premise of the post can coexist with the phenomenon of clamoring to "only hire the best" and obsessing over e.g. HackerRank interview submissions or something. Also, what of acqui-hires? I've seen and been part of some big corporate acquisitions in which a company buys a start-up that is not doing good work and has a stupid product, solely to get their 10-person engineering team and then drop the other employees. In which case that start-up succeeding mostly by not giving a shit about any actual business problem and just hiring a group of excellent engineers.
  - peterbonney 10y ago
    "Doesn't this mean, full stop, that good developers should not even consider working for such start-ups?" No, I don't think so. Just because you're not doing novel computer science or engineering doesn't mean you aren't doing interesting work, or that your work isn't valued. I think the point is that from an investor's perspective you aren't going to learn much from poking around the code and saying "why'd you use this library rather than that library?" I can offer my own personal perspective on the value of developer talent as a quasi-technical (I'd say on a good day I'm maybe a 0.9x engineer, most days more like 0.5x :) co-founder of a SaaS company that definitely isn't doing any ground-breaking computer science. To me, the value of a top-flight engineer isn't that they are going to overcome a problem so hard that no "normal human" (like myself) could ever solve it. It's that they are able to look at the fairly vanilla problems we are facing (usability, scalability, etc.), see better solutions than I see, implement them faster and more robustly, and avoid pitfalls that are obvious to them but aren't obvious to me (because I lack the experience to spot them). Maybe we could hire someone cheaper to do the same work, but it would be half as good, take twice as long, and be four times harder to build on in the future. So to me, having top-notch developers is a business issue, not a computer science issue. Let's face it, even at companies that are doing novel computer science, most of the work that most engineers do is going to be pretty mundane from a CS perspective: Google may be doing amazing work at the boundaries of technology, but someone still needs to maintain the mouseover behaviors in Gmail... Which is not to say that development work not at the boundaries of technology is inherently uninteresting! I think most people who code (even sub-par coders like myself) get off on a lot of things other people would consider pretty boring, like (in my case with some work I'm doing right now) figuring out a reasonable stop-gap way to manage state when creating a new object that requires putting some hooks into multiple third-party APIs. This is not a novel problem, but there are a lot of ways to solve it, and it made me happy to implement one that is simple and fails in a reasonable way even if it isn't maximally flexible/robust. Of course, not all founders/managers/executives "get it". And those that don't may opt to just hire the cheapest while paying lip service to hiring the best. But I think (shamelessly tooting my own horn) that people with some experience in the weeds, or with personal exposure to the range of engineering talent out there in the world, recognize hiring sub-par talent is a false economy. And of course there are all sorts of other factors that go into choosing where to work: can I stomach working with these people every day, does the job fit with my personal life, is the executive team technically illiterate and prone to giving us impossible tasks, etc. TL;DR: Engineers can be highly valued even when their work isn't "novel" to the point of requiring technical DD at the time of an early stage investment (there are those of us out there who recognize the value of craft), technical work doesn't have to be groundbreaking to be interesting, and making the choice to hire top-notch talent is usually a business decision, not a technical one.
josh_carterPDX 10y ago
I was waiting for someone to mention Theranos. The challenge there was that Elizabeth wouldn't share the tech. With anyone. They shouldn't have gotten a dime in funding.

mbesto 10y ago

I do technical diligence for a living so I feel like I should chime in. 1. Many of my clients are unsophisticated when it comes to technology, regardless of whether they buy a "tech company" or not. Yes this includes both PE and VC clients. When a PE firm makes an investment in a tech company (and take 51+% of the company) they need to be confident the technology will hold up. About 90% of my work is PE, with the other being 10% in VC (mostly Series A +). Believe it or not, many commercially successful companies do not always use "today's world of SaaS tools, APIs, and cloud infrastructure". And even if they do, just because you use AWS doesn't mean you've setup a VPC correctly, you have multi-az setup, or sensitive data isn't encrypted at rest. These can have potentially costly (i.e. lose customers / brand recognition) consequences. (case in point -> https://news.ycombinator.com/item?id=11999712 https://news.ycombinator.com/item?id=11999712 ) 2. If you're a VC, and especially an early stage one, then no, due diligence isn't necessary. At all in fact (including finance, etc). You're thesis isn't aligned with careful analysis, it's spray and pray, so diligence isn't a worthwhile endeavor. I wonder if something prompted the author to write this or if it's just a random rambling. I thought it was pretty well understood that doing diligence at the angel/seed stage was almost unanimously worthless. 3. Tech due diligence at the later stage of VC, if done right, has more to do about scalability of operations and processes then it does about the specific tech. When you put $50M into a company, spending $50k is a pretty good safeguard. 4. Tech diligence, by the right partner, could have certainly identified risks at Theranos or uBeam (assuming there are some there), but that's precisely what it is - risk. I'm pretty confident the investors in these companies understand the risk, they simply just don't care, because the potential outcome will return their whole fund and some. Do this 10 times and one bet is bound to pay off. 5. I always try to remind entrepreneurs, VCs are finance professionals, not tech professionals. While some may have made their way into VC because of their previous technical ability, there are also many who do not. And just like when you stop coding for 6 months and get "rusty", so do previously technical able VCs who get older and out of touch.

yborg 10y ago
I would hardly consider "spray and pray" to be a "professional" approach to investing, although this aligns perfectly with my experience with many VC firms. The key skill there is sales ability with the types of investor that also allocate large amounts of other people's capital on the basis of gut feels and lunches at expensive eateries.

emblem21 10y ago

How to run a startup in 2016: * No homebrewed tech allowed. It's too "complex" * We should only use off-the-shelf libraries and SDKs because bar-to-entry isn't a real investor risk ("Just trust me, I'm a charismatic CEO who played golf a few times with the best friend of the college roommate of the guy who helped the guy close Series A for Baidu") * Soft skills, soft skills, soft skills! Smiling > coding * I don't know what technical debt is, but I'm sure we can safely rewrite our core product from scratch in between Series B and Series C. Product owners, customer support teams, and quality assurance re-on-boarding is a money problem, not a leadership problem. * Security audits? I have no idea what those are, but lets incorporate IoT into our product suite somehow. That seems hot right now to VCs. Bubbles. Bubbles everywhere.

JoeAltmaier 10y ago
Re: No homebrewed tech Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not smart enough to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.
- ben_jones 10y ago
  "Can that corner be cut?" "Well technically yes, but..." "Good, cut it" .. 2 years later .. "How could we possibly have been hacked! We had security right?!" .. points behind at ten miles of cut corners ..
  - moron4hire 10y ago
    The problem was that the corner could not actually be cut. If the answer is, "yes, but we won't hit our performance targets," then the answer should have been "no, we won't hit our performance targets." Your management can't help it that you said it was possible.

arcanus 10y ago

Anecdotally, I'll mention that for the two founder level pitches/seed raises I've been involved in, there was absolutely no technical diligence at all. Nor was there really any technical discussion at the YC pitch (we did not get selected, admittedly). I've always conjectured that this is why vetting the team is considered such a critical element. For instance, I have a Ph.d. and so I've found people just assume I know what I am doing in terms of tech and algorithms. This can be a disadvantage when I want honest feedback, actually. Most VCs are much better equipped to discuss the business related aspects than anything technical. In fact, I would be hard pressed to evaluate most start-up technology outside my fields of study, because it becomes so specialized so quickly.

vidarh 10y ago
My experience is that technical due diligence is much more likely to be thorough in cases where someone is acquiring a slower growing, more established business. If you're buying a startup, chances are you're buying into the idea and the team much more than the current technical solution, and if you're right the margin for error on the cost side are huge, so you can afford taking the risk of having spend extra cleaning up a messy code base. Apart from rare areas where solving a particularly hard problem is part of the value, the underlying tech is a distraction if the team is good and the idea is good. But if you're buying a "boring" established business with a moderate growth rate for its market position and revenue, whether or not you'll end up spending 20% on top of the acquisition cost over the next year fixing crumbling infrastructure suddenly matters a lot more.
ridgeguy 10y ago
My anecdote tracks with yours. Ours was a materials startup, no code involved, but totally dependent on a then-new type of plasma chemistry. Intel Capital brought over their Wall of Faces (mostly technologists) for a "tech DD meeting". They asked almost no tech questions. All the questioning went to our business model, transition from custom proto to volume mfg, and building protectable IP. Our tech PowerPoint stack remained unrun, and I was very glad we'd stayed up all night doing 5-year financial pro formas. I.C. invested. But I was surprised at how little they vetted our technology before signing the terms sheet.

jacquesm 10y ago

The main reason why investing in start-ups is hard is not because of the ones that die, it's because of the ones that remain afloat but only barely so.

theseatoms 10y ago

Because odds are high that you'll fail, in which case you default on your technical debt.

grandalf 10y ago
Technical debt is a temporary leveraging to achieve productivity at the expense of ultimate quality. So assuming the business failed for non-technical reasons, or if the business succeeded, both are examples of why to use technical debt as a strategy. The case for not acquiring technical debt is when a business fails because it can't pay down the debt or fails because it is bitten by the debt in some way.
- afarrell 10y ago
  "Technical debt" is actually an unhedged call option
  - theseatoms 10y ago
    Exactly. (An unhedged short call option to be more precise.) And a startup is a long call option. So a startup can bootstrap itself to a certain level of success by mortgaging its higher-upside states. What would this look like in practice?
    - grandalf 10y ago
      It happens all the time, not just via technical debt but also via management debt and various other leveraged choices. For a young startup to be successful, it needs to offer evidence to investors that additional funding will lead to exponential revenue or market share growth. Those are the hard things. Building code without taking on technical debt is actually easier than building it with just the right amount of technical debt for the business's uncertain future. In my opinion, the kind to avoid is sloppy, non-strategic technical debt, such as what you often get when developers are burnt out and need to complete aggressive milestones so that management will be satisfied with the rate of development. This debt tends to break modularity and lead to bad system design, whereas stategic debt can simply mean building a quick and dirty black box for desired functionality that has clearly defined interfaces that can likely remain once the debt is removed and will not necessitate a rewrite of other modules. Similarly, management debt can be strategic if it teaches young or inexperienced managers useful lessons that they grow from and apply as the company grows. But management debt that results in burnout and high turnover also gets rid of the valuable lessons and lets someone with slightly more experience make some of them again.

chris_va 10y ago

There isn't a distinction made here between product+technical diligence (e.g. is something possible to build given the funding sought) and execution+technical diligence (e.g. is the team building it the right way). I would argue that the former is always important. I agree that the latter is less important, but with some caveats. The number of engineering hours put in during the first year is going to be a tiny fraction of the second year, etc, so tech evaluations will change drastically over time. The author argues that this makes them a slight waste of time. However, I've been very successful in using rough technical diligence in the early rounds as a proxy for measuring the decision making abilities of founders. This is hard to measure, so I still find technical diligence useful. You have to know the constraints they are working under, and not hold technical debt/differences of opinion (like homebrew vs stock) against them, the purpose is different. Just my 2 cents.

DonHopkins 10y ago

I understand the reluctance to evaluate a startup based on a prototype, but there are prototypes that are designed from the start to be incrementally refactored and replaced, and there are prototypes that are monolithic dead ends in hell. There are people who use technical debt to get to the next level so they can repay the debt, and there are people who use technical debt like Donald Trump uses bankruptcy court to screw people who trusted him.

lima 10y ago

And then you get hacked and your customer data is leaked.

20andup 10y ago

"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)" He is using the quote wrong. A scalable product and an MVP are build entirely differently. Both scalable product and MVP can have technical debt, but I wouldn't say the scalable product is the optimized version of the MVP.

eldavido 10y ago

What about cases where "poor technology execution" is the root cause behind "we didn't move quickly enough" or "we didn't build the right features" because you didn't move quickly enough, and the product architecture made change too difficult?

hywel 10y ago

"Most startup failures were caused by building the wrong product, or lacking strong sales skills, or not having a viable business model" <- the first one of these is the biggest cause of startup failure, and is technical. Startup technical diligence needs to check for a minimum level of ability and beyond that, ability to find the right direction to build in. The idea that what product you build is not the responsibility of the technical team is almost certainly why you think there's no point in doing technical diligence.

zxcvvcxz 10y ago

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.

wslh 10y ago

Probably most of the time technical due diligence is not necessary but this is not my experience working with startups where the commercial success is strongly connected with a technical solution. Some examples: i/ An startup wants to enter as an automatic security escrow in a Bitcoin multi-signature wallet (please forget for a moment this is about a sector with too much hype). If you do a basic analysis you will realize that multisig wallets are well supported but there is a missing link: there is no standard out-of-band way to setup these wallets and you should do many manual steps. These manual steps add a lot of friction for user onboarding and undermine the startup success. ii/ A security startup wants to integrate their app inside Microsoft Outlook via an add-on. They are confident because they look at the API and it seems you can extend Outlook but they discover very late that a specific feature can't be achieved. iii/ An startup wants to virtualize Windows applications (e.g. VMware ThinApp) using binary instrumentation and/or filtering drivers. They will find that some few but critical applications (e.g. legacy Java applets) require an ad-hoc solution for specific issues that significantly increases the development costs.

tobyc 10y ago

Technical due dil doesn't just need to look for poorly architected systems and bad code. It should also look for code that's prematurely optimised and over-engineered. If an early stage team is building a massively complex microservices based product, using a new type of database and deploying it via kubernetes — where a Rails CRUD app on Heroku would easily satisfy requirements for years. Then someone seriously needs to ask the question as to whether using bleeding edge tech is necessary, and whether it will impact the ability to iterate and hire.

LoSboccacc 10y ago
Due diligence is less about code and more about robustness, licensing and operating costs. Common questions are what would happen if the data storage failed/datacenter went dark and do you have an up do date list of all libraries used, yes including copypasted stuff out of stack overflow. Due diligence != code audit. Sure if you get in that level detail for the td then it's a waste of time, but otherwise knowing that the tech team is not sitting on a landmine it's kinda important
ilaksh 10y ago
'Massively complex' -- ok I agree on that part, you want to avoid that. But as far as microservices, its totally possible to do that in a way that doesn't add a bunch of complexity. As far as new databases versus relational, a new database can make it easier to iterate (no/easier schema migration) and hire (can't prove this but I believe there are many people like me who got sick of relational dbs after many years and are just happy to deal with different types of problems.) Something like kubernetes if done correctly can really help smooth things over because many apps have specific external dependencies which without a tool like that are hard to automate 100% and so create drag for new hires especially.

vasilipupkin 10y ago

I actually disagree with this. Of course, building the wrong product and having poor sales/marketing and all that other stuff matters a lot, BUT if the startup's technical people are weak and cannot quickly iterate, then this startup will bleed money really fast, while not being able to quickly modify the product as needed. So, I would say, you need to do technical diligence on the founders, but not necessarily on their code

ilaksh 10y ago
I've worked one at least two or three little startups where they were iterating fast but the code never really worked (core functionality broken) and the non-technical people' didn't even find out until I came in to 'fix a few bugs' and found a pile of spaghetti which could not possibly function correctly. So just be careful how you define 'iterate' and how much emphasis you put on 'quick'.
- vasilipupkin 10y ago
  exactly, so that's what happens when a startup tries to iterate quickly, but doesn't have the right technical people who can pull it off.

franciscop 10y ago

> "The ability to scale with success is important, but designing products for high scalability from Day 1 is usually a mistake." In my opinion, and having helped dozens of startups (friends or work), this is the biggest mistake I've seen. Engineers love to make things that scale, while business logic imply to leave it for when it is actually needed. I'd say it's #1 waste of time in a startup (in Spain). Also, when doing so mostly it's done without measuring anything, just doing it "for the sake of it".

heme 10y ago

In my experience as a software developer... Technical diligence, and technical debt, only matter in the way they affect revenue & growth. Technical people are usually more acutely aware of how they will be crushed by the current debt they are accumulating. Business is more acutely aware of how the business will fail when growth goals are not met. Both things should be everyone's concern. Striking that balance, and communicating serious pitfalls and shared goals should help give perspective.

kang 10y ago

The world very soon is going to be the opposite of it, where you just release software and wait. An anonymous person launches a company without any capital, registration, employees, marketing, sales, which is ipo from day 1 and the founder is a billionaire just by releasing a piece of code. With blockchains it is possible to do so.

lpolovets 10y ago

(I'm the post's author.) Just to clarify a little bit, since I didn't make this explicitly clear in the article: there are certainly questions about the technical side that are useful. One example from the blog post is trying to understand if the tech team's experience lines up with what they're building. If the founders are 2 infrastructure engineers who are trying to build a social app, or if they're mobile devs who are trying to build a streaming database, then that's a yellow or red flag. Another example: I've gotten a lot of value out of drilling in a tiny bit when people make bold technology claims. If someone says they've developed cutting edge ML, they rarely expect an investor to ask about it. When I ask them what "cutting edge" means, if I hear words like linear regression or decision trees, then my bullshit detector goes off -- but not for technical reasons. It's not bad at all to use simple ML models, what is bad is misrepresenting your tech, because then I start wondering what else you're misrepresenting. But for most (seed) VCs that I've met, technical diligence means asking an engineer they're friends with to talk to a CTO they're thinking of investing in. The engineer asks about system design, infrastructure decisions, deployment environment, coding practices, etc. and then tells the VC if they think the tech stack is robust. (VC: "Ah, they're using AWS and Redshift? That sounds modern. Thumbs up!") For many, many startups (SaaS, mobile apps, ecommerce, etc.) I think this type of diligence is basically useless for almost all seed stage companies.

mgrennan 10y ago
Yes - there are many RED FLAGS. One is they skip all the hard parts(Tech Diligence), like security and and are all ready selling to the public.
dnautics 10y ago
As a cofounder of a technical startup (biotech), and a part-time contractor on another technical startup (hardware): I think the main points in your article are right, but maybe retitle it "startup technical due diligence is (usually) a waste of time"?

andrewfromx 10y ago

but there is some minimum required. You want to avoid situation where you are investing in a team that litterally does not know what they are doing and are scamming you for money. Zero tech dilligence can't be the answer. But it should be pass/fail not graded for an A+.

dkarapetyan 10y ago

Sigh. This article just sets up a bunch of false dichotomies. You can ship good code and put a product in the hands of people at the same time. You can also ship shit code and do the same. It obviously takes more expertise and diligence to ship the better quality code but it's not like taking 5 extra minutes before every commit is gonna break your business if you didn't have a proper business model to begin with.

gedy 10y ago
This. "Go fast!" is often an excuse for putting zero thought at all into sane design or basic layering, which is basically just as fast as doing it the wrong way.

gersh 10y ago

He is looking at obituaries of startups for advice. If you look at successful startups, did they face early technical risk? Google won early by having the best algorithm. Facebook's early competitor Friendster died due to technical issues. It seems less clear at what stage companies like Uber and AirBNB faced substantial technical risk? I'd guess Slack and DropBOx had significant technical risk in early stages. I suppose WeWork probably had less technical risk. I suppose the early prototype's code may not be totally indicative of whether the company can overcome the technical risk. Still, I think you need to evaluate whether the founding team can deal with the technical risk. Technical due diligence isn't about looking for beautiful. It is about looking for an ability to manage technical risk. This includes an ability to hire and manage good engineers.

mgrennan 10y ago

Steve Jobs rule 4 should come in here somewhere. I agree, the first software produced is just a proof of concept and will be re-written. I even believe the only way to write good code is to build it fast in some intransitive language and then throw it away and do it over in something compiled. So I agree with this post except, to become great, you need to know upfront you are just proving the idea and you will do Technical Diligence of the final product and NOT SELL CRAP.

20andup 10y ago
"will be re-written" From my experience working in startups, this is never the case. Crap code persist because rewriting it would take time, they would rather spend on new features. Feature creep sets in very fast.

kafkaesq 10y ago

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. Most startup failures were caused by building the wrong product, or lacking sales skills, or not having a viable business model. The strong presence or absence of amazing engineers was rarely a factor. "Our biggest obstacle to growth, right now? We still can't seem to attract candidates with strong CS fundamentals. Maybe we should crank up HackerRank hazing process from 3 hour-long sessions, up to 5. Because I mean, just look around -- aren't we amazing? At this critical juncture for our venture, surely we can't afford to dilute our crack team with mediocre talent."

gedrap 10y ago
It probably counts as failure because of poor management, rather than absence of amazing engineers ;)
- delinka 10y ago
  That's obviously not the problem: "just look around -- aren't we amazing?"
50CNT 10y ago
I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it). That is total speculation though. Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs. It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays? There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter". But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so. These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.

gedrap 10y ago

> For >95% of startups, however, technical diligence is a waste of time for a more fundamental reason: 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. While it's a tough pill to swallow for many engineers, there's a lot of truth in it. The company I work for (Bored Panda) is a pretty good example of it. I was the first full time engineer, and the company already had 20+ millions of monthly visitors and ~2m facebook followers. Surely, there was tons of technical debt to clean up and uptime was... really poor :)

econner 10y ago
> From Google description, "Bored Panda is a leading art, design and photography community for creative people. Our submission platform helps artists and creators turn their stories into." into what? :-)
- thomasjudge 10y ago
  That's called semantic debt
  - jessaustin 10y ago
    LOL. I will be on the lookout for this now, and I fully expect to see it everywhere.
- gedrap 10y ago
  Whoops! It happened quite a few times that some artist submitted their work (photos, illustrations, etc), our experienced editorial team polished them and the attention and traffic really kickstarted their career. Here are some selected stories: http://www.boredpanda.com/success-stories/ http://www.boredpanda.com/success-stories/ . Also, I believe, we contributed significantly to the coloring-books-for-artists trend which was quite a thing in late 2015 and sold loads and loads of copies, because I think we were the first major publisher to publish a story about them. Not something world changing, but it's good to know that I contributed in one way or another to actually help some artists :)

c-smile 10y ago

Truth is as usual in between of two polar opinions - in the golden middle. Just hire at least one professional for the startup. He/she will simply not be able to do complete garbage. That's meaning of "professionalism" at the end, right? Good Experienced Professional Engineer also understands real life compromises. For him/her it is not that hard to make initial architectural decision that allows to implement something fast but has a foundation for future expansion. Usually it takes about couple of days for the person that "been there, seen that" to make good architectural decision. Startups: "We are not so rich to buy cheap things". Well, at least CTO / architect.

biot 10y ago

What's the typical cost of bringing in someone to investigate and write up a technical due diligence report?

mizzao 10y ago

Is the article arguing that ability to execute is not a distinguishing factor for startups? Or just that non-technical execution is more important than technical execution?

fillskills 10y ago

Anything that starts with "For the most part, I was wrong." gives me a boost of trust and respect for the author of the post. It is hard to admit your own fault and it is much harder to admit to it publicly.

kalman5 10y ago

Flawed logic all around. First 4 points: 1. Early version of a product especially when in hurry with features delivery are going to be "temporarily definitive" implementation. As soon a feature reached the production the code has to be considered "legacy code" 2. Technical debt is a choice, and when you have too much of it you enter in a spiral of death. 3. The quote from Donald Knuth is only a poor excuse to slack and to justify bad development habits. Writing efficient code most of the time doesn't require more time than not (choose the right container or the right algorithm for example). 4. It's a so generic statement that adds no info at all. "For >95% of startups [...] That means technical resources are rarely the cause of success or the reason for failure." that's the best statement of the whole post that more or less sounds like this: "In Africa 90.3% of people die due to: nutritional causes, hearth disease, cancer and diabets, why send over there good doctors then?"

nabla9 10y ago

It seems that the Internet and mobile technologies are established technologies at this point. Most internet startups are not technology driven. They are all about marketing, customer relations, service and business as normal. MBA's are more important than engineers. High-tech startups still exist but they are not the norm.

vinceguidry 10y ago

Solid engineering may not be needed from a business standpoint, but good engineers want to work on solidly-engineered products. If you've got a pile of hacks, and you keep telling developers they can't take the time to clean it up because business needs come first, then speed of feature implementation is going to slowly degrade and eventually grind to a halt. The good ones you'd have tapped to clean everything up will be long gone by the time this happens.

xenadu02 10y ago

Technical debt can absolutely kill a company if you have competitors who are fast-following while already knowing where the map will lead them. They have a chance to avoid some of the problems. I would suggest this isn't addressed in post-mortems because most of the time customers won't or can't tell you why they chose a competitor, sales doesn't know or doesn't communicate that to engineering, or engineering is too dysfunctional to act on the information and has a vested interest in justifying their own decisions. Sometimes it isn't even tech debt per-se, just bad decisions that make implementation of critical features much more expensive... sometimes so expensive everyone feels it would take too long to implement so it isn't done.

wyc 10y ago

Another supporting argument for this is from The Innovator's Dilemma: disruptive technology (startups tend to leverage this) tends to be constructed from pre-existing and commercially available components. Think Snapchat, Instagram, tablets, digital pianos, and all-in-one PCs. All the major building blocks had already existed at the time of invention. This is in stark contrast to sustaining technology, which tends to require expensive teams of scientists and engineers to make incremental improvements to an existing business line, making it palatable only to large organizations with deep pockets. Samsung can afford to have its physicists to find tighter SSD data packing. Google can afford statisticians to tune their search algorithm with complex models. Startups simply can't, nor should they!

danieltillett 10y ago
Startups can do this, but they need to have very, very good people and go niche. The are millions of smallish niches out there that can be attacked with a sustaining approach provided you have the right people. The problem is really good people are hard to find and most niches are too small to support investor funding.

claudiusd 10y ago

As a technical founder having gone through a few VC rounds, I was initially surprised by the lack of technical diligence but eventually came to the same understanding as the author: product-market-fit and sales/marketing execution make-or-break most companies. I would add though that the impact the technical founder has on the design of the product and the quality of execution is immense and often hidden behind the non-technical founder selling the company to VCs. Good technical founders do a lot more than code. If I were a VC, I would look for teams with technical founders that have skills extending into product management, people management/recruiting, and operations.

LordHumungous 10y ago

>only ~5% of post-mortems referenced a lack of technical ability/execution I'd be curious to see how he arrived at that number. In my experience poor technical execution manifests itself as other problems, like slow time to market, poor user experience, or even building the wrong product.

erdevs 10y ago

The headline for this post is far too broad. More accurate would be to say that "very early stage startup technical diligence is usually a waste of time". That is often the case, for many of the reasons the author outlined. Later on in a company's life, however, technical diligence becomes very important. If anything, VCs should do a better job of it. Countless companies have struggled, stalled or failed because they didn't become aware of or address technical issues early enough and scaled the business side too far out in front of what could be managed technically. This gets your company upside down fast, and in very difficult to unwind ways. Customers become dissatisfied at instability and lack of rapid improvements. Internally, strife between revenue owners and technical owners can easily increase as tech tries to balance delivering new funcitonality and addressing old technical debt. After you find product-market fit and start really scaling-- ie after the early stage-- technical diligence should be a much higher priority than it currently is, for both VCs/investors and for company operators within their own orgs. Better technical assessments of issues and opportunities would serve most startups very well.

graycat 10y ago

It appears to me that the OP is making a very serious, fundamental mistake: He keeps talking about "most" startups. Alas, in shockingly stark terms, as a VC he is quite definitely, necessarily, in very strong terms not looking for "most" startups. Instead, he is looking for exceptional startups. How exceptional? A few or so each decade. What is true for most startups is no doubt close to irrelevant for the exceptional startups he is looking for. Sure, due diligence is not important for lemonade stands, but it was just crucial for, say, the Lockheed SR-71. And for any startup that is using new, advanced, original, powerful, valuable technology, proprietary intellectual property, barrier to entry, technological advantage, due diligence stands to be crucial for, say, estimating the exit value of the company. Sure, a lemonade stand may have traction growing rapidly right away, but it will never have much exit value. Moreover, don't do due diligence on just the code or the architecture but also on the crucial core technology, e.g., some original applied math. We're talking theorems and proofs here, guys, maybe with some pure math grad school prerequisites missing among nearly all chaired full profs of computer science. Did I mention technological barrier to entry? Uh, again, we are looking for the exceptional, and that may look different from the "most".

FiatLuxDave 10y ago
This. Upvoted. Does anyone have the data to do the math and see what the difference in ROI is between startups in general and startups which a) should have technical due diligence done and b) which have or would have passed tech due diligence? Maybe we could call these something like "tech startups" to distinguish them from the others. :) It would be good to see how much delta exists between these two different pools of startups. This would be a fairly easy filter for VCs to apply.
- graycat 10y ago
  Would be good. In the meanwhile, pretend you are the Johns Hopkins University Applied Physics Lab (JHU/APL) working for the US Navy, and they have explained that for their nuclear armed, submarine launched intercontinental ballistic missiles they have one heck of a navigation problem. They tried inertial navigation but are not pleased with it. So, some physics guys thought about some satellites sending out signals, the Doppler shift, etc. Some back of the envelope physics was some convincing due diligence. The system was built and deployed as planned, and a receiver on the roof of the lab routinely navigated itself within one foot. No question. No doubt. Worked great the first time. Disclosure: Have to track the satellites quite carefully and update the data on their orbits frequently, and the JHU/APL had a group doing that. At one time I was a programmer, on the fast Fourier transform with passive sonar data, in that group and heard the stories. There are many more examples where some such applied math/physics, etc. worked great. The due diligence was carefully done, and the batting average for the projects was terrific. Instead of empirical pattern matching, just do due diligence on such projects one at a time. That's what the US DoD has long done. E.g., look at that truck with some long tubes on the back the US just deployed to South Korea. Each tube has a missile that can get up to altitude like right now and hit an incoming warhead. So, given several warheads and several missiles, how to assign missiles to the warheads? There's some nice applied math there. And don't have to wait for a pattern of nuclear wars to know that the math will work. Maybe the lack of enough data for pattern matching is the bad news, but, then, the good news is that same lack of data -- we're talking greenfield here, guys! To heck with the pattern matching: Instead pick a problem, one that with the first good or a much better solution enough customer/users will care enough about to yield spectacular revenue and earnings. Then, use applied math, physics, etc. to get the crucial core of such a good solution. Write the software. Go live. Get publicity. Please the target audience. Smile on the way to the bank. The core tech permits better or first good solutions to challenging problems, gives crucial technological advantage, barrier to entry, proprietary intellectual property, etc. But, as for the JHU/APL project for the US Navy and many more US DoD projects, have to do the due diligence one project at a time. Sorry 'bout that.

lifeisstillgood 10y ago

I naively assumed this article would be saying "don't be diligent in adhering to software quality in your startup" not "when investing don't worry about the quality of the software - it's a numbers game" This is one more example of how what's good for the VC (with a large portfolio) is not necessarily good for the startup (with a portfolio of one)

rywalker 10y ago

Great post Leo. Most startup "diligence" is a waste of time, usually just investors checking the box after they've already made a decision.

dreamcompiler 10y ago

This article re-confirms that most of the money in Silicon Valley is being made without much real technical innovation. Not a surprise, but I still find it depressing.

abc_lisper 10y ago

All aspiring programmers, pay heed to this. If you want to become a good programmer, startups are thus a waste of your time, at least the ones that think like this. The devil/fun is always in the details. Deprive me of that, I will never work for you.

cakeface 10y ago

Dealing with technical debt is the privilege of a successful business.