[tobyc]

Technical due dil doesn't just need to look for poorly architected systems and bad code. It should also look for code that's prematurely optimised and over-engineered.

If an early stage team is building a massively complex microservices based product, using a new type of database and deploying it via kubernetes — where a Rails CRUD app on Heroku would easily satisfy requirements for years. Then someone seriously needs to ask the question as to whether using bleeding edge tech is necessary, and whether it will impact the ability to iterate and hire.

[LoSboccacc]

Due diligence is less about code and more about robustness, licensing and operating costs.

Common questions are what would happen if the data storage failed/datacenter went dark and do you have an up do date list of all libraries used, yes including copypasted stuff out of stack overflow.

Due diligence != code audit. Sure if you get in that level detail for the td then it's a waste of time, but otherwise knowing that the tech team is not sitting on a landmine it's kinda important

[ilaksh]

'Massively complex' -- ok I agree on that part, you want to avoid that.

But as far as microservices, its totally possible to do that in a way that doesn't add a bunch of complexity.

As far as new databases versus relational, a new database can make it easier to iterate (no/easier schema migration) and hire (can't prove this but I believe there are many people like me who got sick of relational dbs after many years and are just happy to deal with different types of problems.)

Something like kubernetes if done correctly can really help smooth things over because many apps have specific external dependencies which without a tool like that are hard to automate 100% and so create drag for new hires especially.