Some things I’ve learned reviewing tech stacks on small software/tech acquisitions

 profile

May 17, 2026

by a professional from Duquesne University in Stamford, CT, USA

Software is becoming a big piece of even physical service companies. Technical due diligence is an often overlooked piece of a successful acquisition, and it really shouldn’t be. 1. Everything was built by consultants that aren’t embedded in the business. This one flies under the radar. Everything technically works, but who knows how to make it better? Who knows how to fix it when things go wrong? Do you actually own the underlying software? 2. Unsecured and ungoverned AI infrastructure. SMBs are adding AI much faster than large companies, which is great. But the unintended consequence is that it can go completely ungoverned over what it’s doing and what it has access to. AI is becoming an easy attack vector and could leave your logins, keys, and sensitive information out in the open. Ungoverned AI has also been known to make incorrect decisions - PocketOS had all of their data deleted off of production databases and backups, even though they explicitly told the AI agent to never do this without approval. 3. Legacy platforms. These aren’t as obvious, and sellers won’t generally admit this one. This could kill you. Open source software, which SaaS (and ecommerce depending on the platform) is built on is updated so fast it’s hard to keep up with. A lot of times, this software reaches end of life way sooner than you expect. Without a team maintaining this, it’s so easy for this to fall under the radar. You’ll just wake up one day to your platform down and no quick fix for it - sometimes these updates take developers a week or longer. Would love to compare notes with anyone evaluating a deal with a tech component.
6
16
284
Replies
16
commentor profile
Reply by a searcher
from Missouri State University in Springfield, MO, USA
All three of these are underappreciated but the ungoverned AI infrastructure issue is the most prevalent right now. SMBs are bolting on LLM calls through third party APIs without any real understanding of what data is being sent out or stored. Beyond the security risks, those API dependencies are a hidden COGS problem that won't show up cleanly in a QoE. A business doing $300k SDE might look very different once you actually map out what they're spending on OpenAI calls at scale.
commentor profile
Reply by a searcher
from The University of Michigan in Ann Arbor, MI, USA
As soon as you have a few lines of code, you have technical debt. And probably bugs too. There is nothing scary about that (or deal-breaking). It just is. I would not conduct technical due diligence without the help of a technical lead or a software architect who can properly look under the hood. At a minimum, an inquiry about programming practices enforced during the development process, how the UX and design were performed, source control, whether CI/CD is in place, and issue tracking. Bonus points if they have ADRs (architecture decision records) and PRDs (Product requirement documents). Happy to chat if you DM me.
commentor profile
+14 more replies.
Join the discussion