
Tech Due Diligence Calculator - tosh
https://decodingvc.gitbooks.io/p9-startup-tech-due-diligence-calculator/content/
======
rsweeney21
.9 is an angel investor. They say they like to be the first money in. Many of
the things on this checklist shouldn't even be on your radar until after seed
or series a. Paying thousands of dollars for employees to attend conferences,
hiring a chief product officer, thinking about scaling by x100000, worrying
about multi cloud, avoiding vendor lock in, unit test coverage, one click
deploys...and the list goes on. This is textbook over engineering and the HN
crowd is very vulnerable to it.

Pre-angel funding you should take every hack and shortcut you can to get
something into your users hands.

Please ignore this checklist. It is really bad advice.

(source: 2 time founder, over $16M raised from VC. I have made many of these
mistakes.)

~~~
marcinzm
Yeah, some of these are really weird.

Vendor lock-in, with established long term vendors, is such a tiny risk at
this stage that putting effort into avoiding it is going to cost you
signification more business wise. Especially odd when there's a whole bunch of
other questions noting that building things yourself is not worth it at this
stage.

Daily 1on1s seem like a massive waste of time and focus that it seems insane
to suggest them. If something comes up then your door should be open but
expecting things to change day to day seems like you've got much bigger
problems.

~~~
Negitivefrags
I disagree so much about the daily 1on1s.

You don’t need to pull people from their desk. Just walk around the room and
if nothing has changed you will have the following conversation.

CTO: Hey, what’s up?

Developer: Nothing much, still working on X feature. It’s going okay.

CTO: Cool, thanks a lot.

It wastes no time at all. Except that quite a lot of the time one of two
things can have occurred:

1) The developer is stuck on something but they don’t want to ask because most
people would rather struggle for a while first. By asking “What’s up” they
will usually volunteer this without it sounding like they need to ask for help
and then you can discuss it and usually resolve it or know who they should
talk to to resolve it.

2) The developer has gotten distracted by something that seems important to
them. If it’s actually important then it’s much better that you know about it
rather than not know, and if it’s not then it’s much better that you guide
them back to working on what is important before they waste too much time.

Seriously, I have gone through periods of doing and not doing this, and the
whole organisation moves so much quicker when doing it.

Also, if you have to tell everyone something, you will find that telling every
single person individually works so much better than telling everyone that
thing as a group.

When you tell a group of people something nobody in the group will actually
hear and understand it. One on one they will ask you a question if they don’t
understand but in a group they almost never will. So if there is anything to
tell people just walk around and tell each person one by one during this daily
process.

Zero “Meetings”, daily 1on1s is what it’s all about.

~~~
AstroJetson
This is known as "Management by Walking Around" My best manager did this. He'd
wander by, and ask how it was going. Some days he'd say "tell me one good
thing, one bad thing." At least once a day you got face time with him, and
once you learned that, you could use it to your advantage.

Sometimes I sit in on the daily meeting and don't learn anything, but MBWA, I
often get some insight to issues that are going on.

------
jandrewrogers
A few of these make unwarranted assumptions, though this may be based on the
kinds of companies they invest in. Examples:

S1.3b - For several types of software, releasing continuously is an anti-
pattern. Not only will it annoy your customers, it will significantly increase
the cost of development. Not every tech startup is a website.

S1.4b - Same as above, not every kind of software application can be properly
monitored without custom monitoring development, though most can. If someone
develops a custom monitoring solution, you should at least understand why
first; using an off-the-shelf solution in some cases would be a negative.

S2.6g - There should be an on-premise option. For several industries and
applications it is required by the customers and/or IaaS has substantial
adverse economics. The correct answer is that there is a financial model that
captures these CapEx/OpEx tradeoffs. I've seen too many startups burn millions
of dollars per year unnecessarily because they never did the math. (You should
always be able to easily deploy across IaaS and on-prem though.)

~~~
momokoko
Its more that they don't track "releases". In my experience, early companies
(that are not hardware related) that track full releases are very top heavy
with non technical leadership. This is because technical people generally
understand in modern saas, releases aren't really an actual thing with early
stage companies as they are constantly patching bugs and small features.

The point about monitoring is more a "bus factor". If the organization in
general has good visibility into the operation of the software, there tends to
be less situations where only one person knows how a specific recurring issue
gets resolved.

~~~
jandrewrogers
There are many cases where the customer requirements dictate release adoption
timelines (for business, regulatory, and/or logistical reasons), even on SaaS
platforms. The way you deal with this in practice is running several releases
in parallel in your production environment. This is messy and expensive so you
optimize your release process to minimize the number of versions you have to
support.

The other common scenario is when deploying new releases is intrinsically
extremely expensive in one or more dimensions. Some data infrastructure SaaS
can be like this. Again, in these situations startups correctly optimize their
release model differently than e.g. a website.

~~~
mason55
Right, if you’re a high touch enterprise SaaS that requires things like
customer training, good luck with pure CD. Your customers are going to be very
cranky if stuff is changing all the time.

That’s not to say you can’t get many of the good parts of CD but you’re going
to be making releases and supporting a few different versions at all times.
There’s just no way around it.

------
lpolovets
It's interesting to see different approaches for tech due diligence (tech DD)
work well. Point Nine is considered to be a very strong European seed fund and
they've invested in a lot of great companies. I'm not sure what they do for
tech DD (the first line in this article says this calculator is not part of
their process), but based on the article I'd guess they do a significant
amount of it.

My experience has been very different: I started out doing tech DD and quickly
stopped because it didn't have much value for us. Here's a post about my
experience: [https://www.codingvc.com/why-startup-technical-diligence-
is-...](https://www.codingvc.com/why-startup-technical-diligence-is-a-waste-
of-time/)

My conclusion over the last 6 years in venture has been that tech DD is
important for companies with technical risk, but not many products have true
technical risk. And regardless of the underlying tech, the CTO needs to be
able to spot good talent, convince that talent to join, and manage a team for
at least the first few years of a startup's life.

------
tptacek
Isn't this pretty much just theater? Does anyone have a story about how fine-
grained tech DD cost a company an investment that they hadn't lost for other
reasons already?

I've been involved in acquisitions that had fewer silly technical questions.

~~~
Qworg
A DD I was involved in should have disqualified an acquisition, but the
chairman of the acquirer said he had a "good feeling about these boys". That
acquisition turned predictably sour and downed several other projects at the
company.

------
samcday
> 2.b Is the person who wrote the initial version still the main developer?

> Our opinion: Developers don't like to inherit code at this stage when apps
> tend to be big monoliths. It's common that if they do it, they re-factor (or
> re-build) big chunks of the software.

Shockingly accurate. It's like these folks can read engineers' minds!

~~~
yitchelle
it could also a sign that the company is reliant on this rock star, and not
have a team around the product.

~~~
Aeolun
Chances are they have a single developer in the first place :P

------
jasim
I wonder whether focussing on strengths would be better than minimizing
weaknesses here. There have been companies with their tech in shambles, yet
managed to do really well because the market pulled a product out of them. Bad
tech made life certainly difficult, but it wasn't a show-stopper. There are
also far too many companies who will score well on a test like this, yet fail
because they weren't able to provide compelling value to the world.

This is however an excellent checklist for self-evaluation. I found the point
about feature flags insightful - having them as early as possible so you can
build a culture of testing sooner.

------
femto113
As someone who does due diligence for a (partial) living I try to approach the
question asking part of the process from as objective a perspective as
possible, my goal at that point is to establish an understanding of the
company's technology, staff, and processes, not make judgements. Asking
questions where there are "right" and "wrong" (or "better" and "worse")
answers induces the responder to think "what does the person asking this
question want to hear", not "what is the most factual response I can give".
Only after I'm confident that I have a clear picture of the company will I
make a subjective assessment, and there it is primarily by comparing them to
peers, not by ranking them on any absolute or idealized scale (with exceptions
for certain "red flags", e.g. releasing products without reproducible builds).

------
shapiro92
Personally I have been involved in DD in a startup during the jump from Seed
to Series A. They brought in our offices one guy, who really new his shit. He
didnt have a checklist however, he started by exploring our processes. How do
we create tickets, who are they assigned, coding, prs, deployment. The whole
cycle and he saw it in a whole not `do they use one click deployment` because
he wanted to actually understand how we work and then judge.

He went pretty deep in code in some cases for example useraccount management
and he did find flaws but again no checklist just fixes and improvements.

------
shiftpgdn
This is almost entirely nonsense "look at us" marketing. This is something I
could imagine a bureaucrat would come up with to blindly applynto startups
instead of actually doing work.

------
listenandlearn
I just went through it on my startup that has 3 people working on it.

>>You've got 276.5 out of a maximum of 330 points.

I think most startups with serious engineers on them will do very well on tech
due diligence. I think most people complaining on here don’t really understand
modern engineering or don’t fully lean into managed cloud services the right
way. For example it is very easy to have geo-replicated database, automated
backups/snapshots, auto scaling with functions.. on and on.

~~~
lmeyerov
Then you try to do a 500k deal at some global 2k and you're not even in the
running. Private cloud native (formation, ecs, ...) is starting to become a
thing in enterprise, but for most of our enterprise accounts, even baby steps
like docker swarm are a learning experience for them. But for some
nonsensitive mobile + saas thing, maybe!

~~~
auspex
Docker Swarm is pretty much dead. Everyone is moving to managed container
services like GKE, EKS and ECS.

Very few companies our building their own clusters (sure they are out there,
mostly banks, financials and gov)

~~~
lmeyerov
Yep, and yet, what a Californian knows is not what a Global 2000 does. We had
a new Swarm user last quarter and another Global 2000 doing Mesos, both
through their central IT. This month, a team trying us out with their new
experimental Hadoop cluster.

~~~
auspex
I have seen the container implementations for hundreds of companies and I'm
just pointing general out trends.

Swarm is used quite a bit on day one but generally phased out long before
production. Mesos still has traction on very large deployments but fewer new
initiatives start there these days --although there certainly still is
investment here.

What is most interesting to me is that the longer a company has been using
containers the more likely you see Mesos because three or four years ago kube
was not the first choice like it is today.

~~~
lmeyerov
... And those aren't ECS. I'm not saying ECS is unpopular, just what tech co's
do 90% of the time is't what Global 2000 does 90% of the time, so know your
customer.

------
Aeolun
-30! A total win. But what does this actually represent?

Also, daily 1on1’s?! Micromanagement much?

Edit: It seems the scoring on the survey is different from the one in gitbook.
The survey gives 147.5 points.

------
redact207
What's wrong with a monolith? You can have ones with well organised internal
boundaries. Likewise you can have microservices that are a complete mess

~~~
Cthulhu_
In microservices the mess is often at the higher architecture level. IMO,
startups should not do microservices, not until they can point at one fragment
of their product and go "This is 99% isolated from the rest of the application
yet costs 90% of performance, extracting this and rewriting this in a more
specialized fashion will benefit us"

~~~
redact207
Totally agree. Microservices is an optimization, not an architechure that you
start off with. They can absolutely kill your ability to iterate if your
boundaries suddenly change, which happens all the time if your startup is
pivoting

------
momokoko
Interesting to see the number of items about payment and invoices. While great
advice, I wonder if they had a specific instance where this burned them.

------
dusted
I don't want to live on an Internet where it's inconceivable that you're
hosted on your own damn servers.

------
MartinMond
It's a very interesting checklist, but I wonder if there's (m)any startups
that make it to due diligence and then fail to (literally) check the right
boxes.

Disclosure: I'm on the technical advisory board of round2cap.com where I also
do technical due diligence.

~~~
taytus
> I'm on the technical advisory board of round2cap.com where I also do
> technical due diligence.

[https://www.dropbox.com/s/4auliazw2d3kcio/Screenshot%202019-...](https://www.dropbox.com/s/4auliazw2d3kcio/Screenshot%202019-07-04%2012.59.11.png?dl=0)

¯\\_(ツ)_/¯

~~~
zaptheimpaler
> Important: If you are looking at this profile because you thought something
> I posted was Wrong, dismissive, disrespectful, douchebaggish, what have you,
> I would really like to hear from you

This comment is not only dismissive, its basically wrong too. Their website is
the digital equivalent of an information brochure - there is zero need for
HTTPS there. The only page that needs it, partner login and the admin area
looks like it does have HTTPS.

~~~
eropple
There's a need for HTTPS _everywhere_ , because to not HTTPS is to invite
hostile networks to inject advertising, exploits, etc. into your readers' web
browser.

Everything needs to be HTTPS.

------
icedchai
Most early stage tech diligence is not very thorough, and rightly so. Things
will change a lot in later rounds. It's more like whiteboard level, maybe a
couple of slides, show us a demo... oh, it works? great!

------
m0zg
Yeah, good luck making quick progress "at an early stage" with barely any code
reviews or tests and one click deploys, especially in a dynamically typed
language where you won't know about bugs until you run the thing.

