Technical Due Diligence Checklist

29 08 2016

From time to time, I get asked to perform technical due diligence on investment opportunities.  I have a checklist, and I thought I’d share it with others in the hope that it might be useful.

If you have anything you think I’ve missed or got wrong, please let me know in the comments, and I’ll [potentially] edit the list to suit.


  • Describe the overall architecture of the system.
  • Well documented?
  • Easily understood?
  • Industry standard components?
  • Many vendors (eg AWS, Azure, etc)?
  • What’s the next big architectural leap?



  • Any monitoring happening now?
  • Ever done load testing?
  • What are the potential bottlenecks and remedies?



  • Load balancing?
  • Separation of functions?
  • Any single points of failure?
  • Automatic [ability to perform] scaling?
  • Cost structures (eg licenses)
  • What isn’t automated that should be?
  • What’s the next scalability hurdle?



  • How are {passwords, sensitive information} {stored, backed up, transmitted}
  • HTTPS?
  • Protection against obvious stuff covered, eg XSS, SQL injection
  • Ever done penetration testing?
  • What requires root access; who has it?
  • What are your upgrade / patching regimes?
  • What’s backed up? Where? Ever done a disaster recovery (DR) test?
  • How would you make the site more secure?


Development processes

  • What languages and frameworks have you used? Why?
  • Who’s in the dev team?
  • How is the team organised? How do they communicate and make decisions?
  • Revision control on all platforms (eg iOS, Android, and back end)? Which – Git, Github, Bitbucket, etc?
  • Test Driven Development?
  • Doing Continuous Integration? Which tools?
  • How does deployment work?
  • Describe the accumulated technical debt, and how this is managed.
  • How would you improve the development team?



  • Is the source code readable and/or beautiful? Is there consistent style?
  • Are there copious comments in the code?
  • Is there narrative commenting for each code unit (object, method, etc)
  • Are they running on current releases of underlying software? Any big changes on the horizon?
  • Are there any unexpected or obscure dependencies?
  • How hard would it be to pick up and move to (AWS, Azure, Rackspace, etc)
  • Any long-term viability issues with specific vendors?
  • How could you improve maintainability?


Licensing issues

  • Do you own all of the code necessary to run the system?
  • How is it licensed?
  • Does anyone else have rights over the code? Could anyone else claim to have rights over the code?
  • If you’re using any licensed code, what are the terms of the license(s)? What are the risks associated with those licenses? Are there any plans to re-engineer these bits over time?
  • Is there an IP strategy, eg “SaaS black box running our proprietary code, accessible only through the web site and our API’s”



  • Are there any other interdependencies with stuff beyond your control?
  • If you were investing in this company, is there anything else you’d like to know that we haven’t asked about?
  • Any other comments?

The Internet in NZ – not half bad

9 08 2015

I’ve just returned from a 3-1/2 month trip, mostly holiday with my wife Kate and 11 year old son Dan, in which we visited Hong Kong, Vietnam, Italy, Switzerland, France, Spain, and the USA, generally avoiding big cities.  Naturally, it was important to stay well-connected every place we went, so we employed a combination of mobile broadband through local telco and wifi in the accommodation we stayed at, mostly AirBNB.

In Hong Kong, CSL provided excellent mobile broadband, but the various accommodations I used had pretty terrible wifi.

Vietnam’s Viettel also provided generally great mobile broadband, and accommodations actually provided wifi that was surprisingly good.

In Europe, we used Orange Spain as they had a deal where for they charged EUR 1 per 100MB of data.  Problem was, for some reason, in parts of northern Italy they seemed to charge a lot more than that – without any real reporting.  Access and speeds in France and Spain were OK but not great, and wifi in private residences was uniformly terrible.

The USA was particularly disappointing.  I travel to the USA a lot, and use a T-Mobile sim card.  They recently prohibited tethering which made things difficult, and at USD 3 per day (a plan which has been discontinued), it isn’t exactly cheap.  Furthermore, T-Mobile’s coverage is patchy and even in urban areas when you can get coverage, I couldn’t ever get download speeds greater than 1Mb/s as measured by Speedtest.  Wifi was also pretty average at best, with the odd exception of an AirBNB we stayed at in Idyllwild, California, in the mountains, a long way from anywhere.

Back in New Zealand, using either Spark or Vodafone, tethering is allowed, speeds are regularly above 50Mb/s using 4G networks that are widely available, and it’s relatively inexpensive.  Wifi in peoples’ homes is generally good, and I really missed my cable broadband where again download speeds are reliably 50Mb/s.

Who would have picked Vietnam as a star performer, and Europe and the USA as letdowns?

OK, these measurements provide an anecdotal picture at best.  I know that:

  • Speedtest is not a reliable measure of speed
  • We were staying mainly in rural areas
  • NZ’s domestic network is super fast for cached and local content, but we’re still 150+ ms from anywhere in the world other than Australia

But still… I regularly hear Kiwi individuals and institutions whinge about how our Internet is both slow and expensive.  That may have been true a few years ago, but things have really improved a lot recently.  Anecdotally, that’s great for Kiwi individuals, businesses, and the economy.


Speak little; listen much

17 08 2014

I’ll be giving a talk at TEDxWellington next weekend.  I’m not allowed to reveal too much about what I’m going to say, but I will be spending some time talking about the IETF’s Requests for Comments, or RFC’s for short.

One of the most important RFC’s is RFC 760, which defined Internet Protocol, or IP for short – this is the really basic schematic for how Internet information packets are put together.  Section 3.2 contains the following lovely snippet, now referred to as “Postel’s Law”:

an implementation should be conservative in its sending behavior, and liberal in its receiving behavior

I was looking for a way of expressing this in plain English, and came across this lovely paragraph from 17th century theologian Francis Fenlon:

Speak little; listen much; think far more of understanding hearts and of adapting yourself to their needs than of saying clever things to them.  Show that you have an open mind, and let everyone see by experience that there is safety and consolation in opening his mind to you.  Avoid extreme severity, and reprove, where necessary, with caution and gentleness.  Never say more than is needed, but let whatever you say be said with entire frankness.  Let no one fear to be deceived by trusting you …  And correct yourself, for the sake of correcting others.

This came from Fenlon’s collection of Spritual Letters to Women, but is equally applicable to us moderns of any gender, especially software engineers.

HT: Stan

I was famous for fifteen seconds

3 07 2011

This year’s NetHui conference was full of unexpected delights, but this gave me the biggest (if shortest) shock –

Yes, I had finally achieved my lifelong ambition of being popular, even if only for fifteen seconds. Thank you, tweeps.

Ubuntu Maverick on a Thinkpad X201

15 03 2011

I finally upgraded my Thinkpad X201 from Kubuntu Lucid to Maverick over the weekend.  I’m pleased to report that the process was nearly flawless using KPackageKit.  Despite segfaults in KPackageKit which didn’t seem to deter it, the upgrade process went very smoothly and took about an hour.

I’ve only encountered three minor problems:

There were some strange dependencies that prevented Kmail from working properly; I had to manually install libkontactinterface4 and libakonadi-contact4.  Akonadi, I wish that it had never been thought of.

cups-pdf disappeared and had to be manually reinstalled.

Bluetooth file receive stopped working.  After a bit of investigation, Debian bug report 609022 had the critical piece of information I needed:  just

ln -s /usr/share/kde4/apps/bluedevil/bluedevil.notifyrc \

and everything is sweet.

Well done, team Kubuntu – Linux is nearly ready for my mother!