
Startup Technical Diligence Is a Waste of Time - lpolovets
http://codingvc.com/why-startup-technical-diligence-is-a-waste-of-time/
======
mbesto
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
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.

~~~
mbesto
Ok, I'll be more diplomatic - not spray and pray, but a "portfolio approach".

~~~
ska
Hah.

I think you're off a bit though. There is a place for diligence at early VC
stage, but it is almost entirely about the people.

~~~
mbesto
That's not necessarily a technology due diligence then...

~~~
ska
Fair, it's more of a technical (and other) competence DD

------
kafkaesq
_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."

~~~
50CNT
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.

~~~
lpolovets
(I'm the author of the post.)

There's definitely some sampling bias from the post-mortem article. Alas, this
is the the most relevant public data that I could find. I do have a good
(anecdotal) first-hand dataset: I've worked closely with about 50 portfolio
companies at this point, and I've tracked a few dozen more that my fund didn't
invest in. Maybe 5 out of the 50 had real technical risk, and 2 or 3 struggled
and/or failed due to technical issues. For the remaining companies, the
challenges have always been market-related, hiring-related, funding-related,
and so on.

~~~
hoodwink
You are really missing the point of due diligence...

"Homeowners' insurance is a waste of money. 99% of the time your house doesn't
burn down!"

You don't buy insurance because you expect your house to burn down. Similarly,
you don't perform due diligence because you expect to find something. You do
it to catch those rare 1 out of 20 events where something is f*cked up.

~~~
lpolovets
It's a little different in Venture Capital because exits follow power laws. So
the big mistakes are literally the opposite of insurance: it's okay to make a
lot of losing investments as long as you don't miss Airbnb. Missing out on
Airbnb because you got stuck on it being 3 designers and no engineers is way
worse than investing in Airbnb and 49 companies that go bankrupt.

~~~
hoodwink
Perhaps you do not use the term "due diligence" the same way that it's used in
the investment management industry, which to be clear, includes "Venture
Capital."

"Due diligence" does not mean making a judgment call on whether three
designers can build, scale, and operate a tech company. Due diligence means
diving into the details of a company you are going to fund and checking, among
other things, that the things they've said are valid and that there are no
skeletons in the closet.

Don't get me wrong: due diligence sucks for all parties involved. If you are
investing your own money, you have the right to do as little work as you want
and skip it, but when you are entrusted as a fiduciary of someone else's
capital -- and paid for the job -- it comes with responsibility.

~~~
lpolovets
There are other factors, like Time, that influence the diligence process for
(seed stage) venture capital. Investments are made at a fast cadence, which is
good for founders and for investors. A seed fund might see 1000 companies in a
year and invest in 10. That allows for a few hours spent on each company, but
not much more than that. Similarly, a founder might meet with 50 or 100
investors before closing their round. 1-2 hours per investor will take a few
months, but if investors spent too much time on diligence then a founder could
spend all year just answering investors' questions. That would be like a
twisted variant of the Uncertainty Principle, where just going through
fundraising process basically dooms a company to fail because of the time
required.

Given that time is a factor and given that I have 2-4 hours to spend with the
companies I'm most interested in before making a final investment decision,
I've gotten the most value out of spending 95% of that time on non-tech
diligence. YMMV.

~~~
50CNT
That does make sense. Investor & Founder time is limited, technical due
diligence on the investor side takes too much time.

I'm coming more from a founder perspective though, and I think there's some
dangers with the mindset as a founder, and I see it with a lot of people in
the chinese startup community.

Whilst as an investor, one might get to play a bit fast and loose with
technology choices, I believe that as a founder doing so is suicidal. I see
startups here struggling to hire PHP programmers because they made the
decision to go with PHP because they heard it was easy, and later on realized
that that may have been a mistake. They try to smooth it over with funding
later. PHP programmers over here have the same reputation. They learn it
because they thought it was easy, and that there's a lot of companies
desperate for that skill. It's a match made in hell.

Similar boneheaded decisions, preventable with a week of due dilligence
reading, are made by founders here all the time. One thing I found interesting
is that the people making these kinds of calls are always working on C-list
ideas. It's always derivative businesses in markets that just don't care. They
need to get their MVP out fast and half baked because what they're working on
should have died on the drawing board. They're desperate for investor money
because they think it will patch over major errors they've made up to that
point.

Some of these ideas are salvageable. It usually requires restructuring on both
the business side and the technology side, preferably to the point where they
make sense as an integrated system. One guy I was working with, his startup is
trying to create a site for farmers and rural Chinese to sell things on that,
and that is so interesting, Alibaba jumped into the ring recently. Now he has
a dinky site that does not solve anyone's problems. It's a website, which is
greatly hindered by the fact that most villages have a single computer, and
the people who wanted to trade with each other would sit at that computer,
together.

I suggested to him that he change things up a little. Small farmers do suffer
from information asymmetry with the people they're selling to. Technology
wise, most of them have non-smart phones, but China Unicom is rolling out
mobile coverage to rural China, because that's their market tomorrow. So,
provide informational and automated brokering services over a website on the
buyer end, and an SMS gateway on the seller end. Ship the FAQ on actual paper.
Allow farmers to post their wares with a formatted text message, have offers
coming in an hour later, goods shipped the day after. Give them a reason to
upgrade to smartphones, pack in more features on the app once data becomes
cheap. Do agricultural futures 5 years down the line, in one of the hungriest
economies in the world.

The part where technology makes this interesting is that it allows you to
reach a market segment that is unreachable over conventional means. Innovation
is the edge startups have over large, well funded enterprises. Founders
ignoring that side are blindsiding themselves to half their business.

------
lpolovets
(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
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.

------
gedrap
> 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
> 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
That's called semantic debt

~~~
jessaustin
LOL. I will be on the lookout for this now, and I fully expect to see it
_everywhere_.

------
emblem21
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
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.

~~~
onion2k
Developers should definitely write their own code when there isn't an open
solution that they can leverage to solve the problem, but those situations are
quite uncommon for the majority of startups. Most founders aren't doing the
sort of cutting-edge development that no one has seen before; they're making a
SaaS app that boils down to a few CRUD forms in a browser and some nice
design[1]. Building a business around that is much, much easier and cheaper if
you write less of your own code.

Use open solutions where you can, and don't use them where you can't.

[1] That is in no way denigrating startups that do that. If you can solve
people's problems by making a better form then that is a Good Thing.

~~~
nostrademons
> Most founders aren't doing the sort of cutting-edge development that no one
> has seen before; they're making a SaaS app that boils down to a few CRUD
> forms in a browser and some nice design

They should probably ask themselves what sort of defensible competitive
advantage they're building, though.

With many founders I know, the answer is "none". This is probably necessary in
the very early seed stage - it's hard to build something unique and difficult
and still get to market - but it's disturbing how many companies end up with
$50M in funding and the answer is still "none". Probably a good indicator of a
shake-out in the SaaS world in the near future.

~~~
onion2k
The competitive advantage those companies have is typically two-fold:
knowledge and brand.

Knowledge is the very detailed and insightful understanding of what their
industry needs at the moment, and where it needs to move to in the longer
term. Founders who build those businesses are typically experienced in their
industry and are solving a pain they've seen firsthand. That is
_exceptionally_ hard to compete with if they're good. Just because that
knowledge can be codified in a 'simple' CRUD app doesn't make it any less
valuable.

The brand advantage is comes from being the first mover. If the industry knows
your company, trusts that you've proven to have an impact on their bottom line
(or their competitors bottom line), then you're probably in a good position to
retain customers and build a market. Competition is not a problem for a
business that's intent on making a market $100m bigger rather than trying to
take $100m of business from someone else.

Neither of those advantages require any code.

------
payne92
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
"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
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.

~~~
eldavido
Experience suggests this may be wise.

I feel there's a huge "repricing" of the value of early-stage tech employment
occurring as capable developers realize just how shitty the standard 90k + .1%
job offer for 50-60 hours/wk, little autonomy, and zero chance for promotion
is, in a city where apartments cost 3400/mo, gas is 3.50/gal and income taxes
are 9.4%. (And the city wants a "tech tax" on payroll of companies)

I worked in this kind of environment for a few years, gained some great
experience/connections, and enjoyed it to a large extent, but probably
wouldn't do it again.

~~~
nostrademons
I've noticed both sides of this repricing - it works both ways.

Good, experienced American developers are realizing that $90K + 0.1% equity is
a really shitty deal relative to what the rest of the tech industry pays, and
they're giving up startup work for AmaGooAppBook.

At the same time, entrepreneurs are realizing that they don't actually need a
good engineer to build v1 of their product, and so they're relying more on
international contractors sourced through UpWork, Alibaba, etc. _Most_
startups I know actually have entirely-international dev teams now, and hiring
your first local engineer is considered a milestone like getting funded (and
often comes after getting funded).

I suspect that the real losers in this are entrepreneurs - the startup field
has become so competitive lately that there's likely to be a shake-out where
the vast majority of startups fail, and many founders are paying for these
outsourced dev teams out-of-pocket.

~~~
eldavido
Thank you for the very insightful comment.

This is yet another example of what I call the "Hollywood-ization of tech",
where the industry (we?) are trying to sort out the relative value of being
attached to something big vs. money vs. relationships.

I think our industry is maturing. I see it all around me. The industry-wide
career ladder is starting to solidify, we're getting more concerned about
credentials/pedigree, salaries are going way up, people are getting more
concerned about their "careers", etc. I don't know that it'll ever get to the
point of, say, law or banking, but it's a hell of a lot closer than it was
15-20 years ago, when there was much more of a "homesteading" feel to
everything, and the suggestion that software could be a prestigious career
choice was the last thing on anyone's mind.

To be clear, I don't know if any of this is good or bad, but it's definitely
happening.

------
franciscop
> "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".

------
DonHopkins
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.

------
graycat
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
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
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.

------
vasilipupkin
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
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
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.

------
thomasrossi
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.

------
wyc
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
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.

------
eldavido
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?

------
arcanus
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.

~~~
ridgeguy
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.

------
xenadu02
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.

------
heme
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.

------
erdevs
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.

------
wslh
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.

------
dkarapetyan
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
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.

------
jacquesm
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.

------
lifeisstillgood
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)

------
kalman5
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?"

------
chris_va
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.

------
gersh
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.

------
andrewfromx
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+.

------
claudiusd
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.

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

~~~
grandalf
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
"Technical debt" is actually an unhedged call option

~~~
theseatoms
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
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.

------
c-smile
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.

------
fillskills
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.

------
tobyc
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
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

------
hywel
"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.

------
vinceguidry
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.

------
dreamcompiler
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.

------
mgrennan
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
"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.

------
20andup
"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.

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

------
abc_lisper
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.

------
nabla9
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.

------
LordHumungous
>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.

------
mizzao
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?

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

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

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

------
kang
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.

------
zxcvvcxz
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.

