loading...

Investor due-diligence

perttisoomann profile image Pert Soomann ・2 min read

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 background, I've been working as senior/full stack dev for a QA company from UK for last 6 years, been with the company pretty much since it first started. We use in-house developed issue management web-app to collect defects from remote testers, review in house, then report valid categorised issues back to client.

We're at the point where business runs comfortably, and founder is now looking for potential partner(s) to take the company to the next level. Part of that process is of course partners getting someone they trust in for technical due-diligence.

I wonder if anyone has any tips or first hand experience on best way to prepare?

One slightly concern I have due to our previous CTO, who was with us very briefly, stating that our PHP/CodeIgniter solution wouldn't scale and investors would want to re-write it as default anyway. For record, being old-school Java guy, he didn't like NodeJS either, so we were in technical-direction-limbo for about a year.

Other than causing the damn impostor syndrome to kick in, I'm now trying to defuse this proactively.

Being biased, of course, for me the app runs smooth even on lower end AWS instance (2-3% CPU) without us ever specifically doing any optimision on the code or architecture - so we def still have some dev-tricks in the bag and we can still throw a lot of hardware on it.

However just saying "meh, it'll be fine" is not what any auditor would want to hear, regardless if they are biased towards technology or not.

I'd personally refrain from complete rewrite, let alone rewrite in different language, based on app size and existing in-house skill, but if the change is needed, I'd rather do it now and be in right place in 1-2 years than going down the wrong path and running into existential issues later.

Would it be enough to reverse-engineer very top end estimated user count from revenue targets (knowing how many users we need to deliver a report, I can figure out how many projects we need to deliver to reach revenue targets, etc), prove that we can handle these numbers, and/or list specific ways we would improve the platform when hitting these numbers?

Aside of that, I assume the most important thing over anything else they want to see is our ability to grow from dev side (bluntly, putting that investor money in effective use).

Therefor our time from now on might be better spent on making sure we have greater separation of concerns, more documentation, more structure in place for existing tech stack to quickly and effortlessly on-board either fulltime devs/designers or freelancers. And/or have feature/changes roadmap in place, just waiting for that extra dev resource to quickly implement the changes.

Any comments on this topic welcome.

First time poster, so please be gentle :) Cheers.

Discussion

pic
Editor guide
Collapse
xngwng profile image
Xing Wang

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

Collapse
ben profile image
Ben Halpern

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.

Collapse
scottshipp profile image
scottshipp

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

Collapse
perttisoomann profile image
Pert Soomann Author

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