.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.)
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.
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.
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.
Leading a five person team and going to lunch with a different person every day effectively means that you do 1-on-1 daily (and they get 1-on-1 weekly) with barely any focus overhead.
Odd you put one click deploys in there though. It's quite trivial to get setup yourself, even if you are running your own servers/VMs and saves a ton of time (although I prefer it to be a couple of clicks).
And once you have it for one project, you can usually adapt the script or process for others.
The problem is you have to maintain it as your infrastructure goes. Pretty soon you should be setting up a staging and test environment, and then you have to deal with segmenting data between environments and it kind of spirals from there.
As a general rule of thumb you need to be really cautious not just of the initial work to implement something, but the medium term operational overhead which 1-click deploys falls into.
That said I still support 1-click deploys early on. It's just not so easy as adding a githook to trigger a script.
You are correct. This isn't good founder advice. Or PO advice, or dev advice, etc.
But to be fair, it is their money - if they want to decide on investments based on these criteria, that is their business. And they did say they are willing to accept critique of where they are wrong. They also said that this isn't truly part of their due diligence, nor should results be taken seriously.
I think that the best way to read this is that you may lose some points here and there and still get a good score. It’s not an all or nothing scenario.
I think this is useful advice and I’ll try to adhere to some of its points in my next startup.
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.)
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.
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.
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.
Re: continuous release, you can also replace the term with continuous integration; not so much if you DO release regularly, but if you CAN. Ask questions like, do we have build monitoring on the release branch? Is it green most of the time? Is work integrated into it regularly (multiple times a day)? If we discover a bug, can we just push a fix to master and deploy or do we need to do a hotfix on an older tag? What are the steps to create a new release?
While yes, continuous deployment may not be desirable in a lot of cases, continuous integration is a practice that (IMO) most software should strive for.
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 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.
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.
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.
> 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!
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.
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).
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.
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.
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.
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!
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.
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.
... 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.
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"
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
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.
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.
Interesting can I ask how you got into that line of work? it is something I have considered moving into that area given I have been around for a while :-)
> 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.
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.
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!
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.
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.)