loading...

Investor due-diligence

Pert Soomann on February 22, 2018

Here's a little curve-ball from the usual dev oriented discussions on dev.to - how do you prepare for investor technical due-diligence? Little b... [Read Full]
markdown guide
 

I can't say I have a lot of experience with this situation but here's what I'd think:

You have a codebase that is doing the job now and I think this would qualify as not worthy of a full rewrite. Doing this speculatively like this just seems wrong.

The point is to offer assurance that the partnering company is not getting a bunch of fools who wrote spaghetti code. I think if you wrote a contingency plan that outlines what you expect to happen and the changes you might make if things don't go to plan. If you demonstrate that you have good reasons for what you have done and have honestly evaluated what might happen in the future, I'd see that as pretty decent assurance.

Scaling is probably going to end up being a matter of a few bottlenecks. It might be worth maybe estimating how you might fit something like AWS Lambda to handle certain parts of the system if you need to.

Again, this kind of due-dilligence is not something I have any real experience with, but knowing that we never have all the answers in software, demonstrating that you have thought about the future and you haven't been dummies to this point would be what I'd be looking for.

 

I think just like CTO's personality drove a lot of tech decisions and opinions. The Technical Due Diligence will be driven by the person doing it. So hard to say what his opinion would be.

Generally, unless they are investing in you for the patent or core technology (like new patent for new AI algorithms), rather than the business in itself (revenue, customers, etc), they would be less focused on the implementation details.

I think confidence is also most important factor, actually a very overweighted factor.... (Which is sometimes unfortunate, since often those who know more are less confident than those who know less.).

 

Warning: this is going to sound very opinionated and I'll admit it is:

Any CTO should know that rewrites are death. Real software professionals have understood this for near 20 years now, if not longer. Few people have a great success story coming off a rewrite and dozens of failures (dead bodies since literally these companies went out of business) litter the road.

For an early opinion: check out Joel Spolsky's comments from 2000 at joelonsoftware.com/2000/04/06/thin...

 

First, thank you all for replies, it's great to see my thoughts line up with others.

What I'm taking from this is:

  • if it works, there's no reason to just rewrite
  • documentation is the key
  • plan and document few steps ahead
code of conduct - report abuse