Last week, we evaluated a Series B fintech that claimed its AI-powered platform was ready to scale globally. The pitch deck was flawless, the total addressable market was massive, and the CEO was charismatic. But a quick look under the hood revealed a monolithic system with a single-point-of-failure database and spaghetti dependencies on a niche third-party data provider with a shaky SLA. Their "AI" turned out to be a series of hard-coded if/else statements. It wasn't a deal-killer, but the post-close refactor and vendor-risk mitigation completely shifted the valuation conversation.
That's the reality behind most hockey-stick charts. As builder-investors at Osparna, we've learned -- often over a cup of coffee -- that a slick UI can mask a crumbling foundation. Our bet isn't just on the product; it's on the code, the processes, and the people who build and maintain it. Ignore the red flags in diligence, and you inherit tech debt that stalls growth, inflates costs, and can turn a winner into a rescue mission.
We put this checklist together as a field guide, sharpened on dozens of deals we've won and the few we wisely walked away from. Consider it the conversation we'd have over coffee when you ask what really matters when your capital is on the line -- software architecture, cybersecurity, infrastructure, IP, team competency, and more, down to the exact artifacts you should ask to see.
Software architecture and code quality: verifying the blueprint. Last quarter, we dug into a Series A SaaS that looked rock-solid until we opened the repo and found a classic "big ball of mud" -- every new feature duct-taped onto core modules, every fix spawning two new bugs. A modular, well-documented architecture is a signal for rapid feature rollout; a monolith hiding tech debt is a warning light. We look at architectural patterns -- monolith, microservices, SOA -- and whether they match growth projections, ideally backed by Architecture Decision Records explaining why. We run tools like SonarQube and CodeClimate for codebase health, paired with peer review from senior engineers who catch design anti-patterns automated metrics miss, and we ask for the debt backlog directly: teams that log, prioritize, and chip away at technical debt earn real points, versus debt baked into core business logic. Read-only access to the Git repository -- commit history, PR practices, review turnaround, the ratio of refactors to feature commits -- tells you more than any slide deck.
Cybersecurity and data protection: fortifying the crown jewels. A few years ago we were deep in diligence on a health-tech company handling sensitive patient data, and when we asked for their incident-response plan, the CISO handed us a hastily drafted two-pager. We passed. Six months later they were hit by ransomware that nearly sank them. Security isn't an IT checkbox -- it's a board-level concern that can vaporize enterprise value overnight. We validate certifications like SOC 2 Type II, ISO 27001, and HIPAA by reading the actual audit reports and confirming exceptions were remediated, not just checking a box. We look for regular SAST/DAST scans, bug-bounty programs, and third-party pen tests, and request the pen-test report and its follow-up tickets directly. We verify encryption in transit and at rest, RBAC controls, and GDPR DPIAs where relevant, plus automated access logging and key-rotation policies. And we ask for the last twelve months of security incidents and near-misses, tracking mean time to detect and mean time to recover -- the real security-maturity metric, more honest than any certification.
Technology stack and infrastructure: cost, scalability, and lock-in. We once scoped a B2B logistics company whose cloud bill was a runaway train -- 90% of spend was data-egress fees to a boutique cloud provider they were locked into, margins evaporating as they scaled. A modern, well-architected stack is a growth driver; leaky, proprietary infrastructure is an anchor. We check whether the core technologies are mainstream enough to hire for, since obscure or end-of-life tech is a red flag on its own; review three months of cloud bills to find the real cost drivers and any lock-in; and check whether the team uses infrastructure-as-code and containerization, and whether disaster-recovery plans are more than a diagram -- do they actually run failover drills? Matching the highest-cost line items on the bill to the nodes on the architecture diagram usually finds the money pit fastest.
Intellectual property and licensing: owning the secret sauce. During one AI acquisition we discovered the core model was built on university-owned libraries with no commercial license -- that single miss stalled a nine-figure deal and cost millions in legal fees. We scan employee and contractor agreements for IP-assignment clauses and trace the origin of key modules; run open-source-compliance tooling to build a full bill of materials, with particular attention to GPL/AGPL and other viral licenses; and catalogue every third-party API, SDK, and licensed dataset along with its SLA, pricing, and termination terms. Asking directly for the open-source license report -- and digging into expired versions, known-vulnerable libraries, and copyleft clauses that could force code disclosure -- surfaces more risk than any legal summary will.
Scalability and performance: ready for growth. We once peeled back the layers of a B2C e-commerce platform about to triple its user base overnight, only to find the entire shop running on a single, beefy VM with manual scaling. True scalability is horizontal, cloud-native, and automated. We look at whether scaling is horizontal or vertical, whether auto-scaling and load balancing are actually in place, and we ask for real performance data -- p95/p99 latency under peak load, historical load-test results -- since no data almost always means the team is purely reactive. On the database side we look for read replicas, sharding, and connection pooling. Read-only access to monitoring tooling, checked against past traffic spikes, tells you whether those spikes were graceful scale-outs or outages.
Team technical competency and documentation. We once acquired a brilliant data-science team only to have the lead scientist walk out two months later, taking undocumented knowledge with him -- the code had effectively lived in his head, and the remaining team stumbled for nearly a year. We look for evidence of paired programming, ADRs, tech talks, and onboarding docs that spread expertise rather than concentrate it in one person, and check whether runbooks and deployment guides are actually current. The most revealing thing we do is sit down with engineers and have them walk us through a complex feature at a whiteboard, no slides -- their fluency with the system says more than any resume.
Third-party integrations and dependencies. A high-growth SaaS company once wooed us with deep CRM integrations, until we read the fine print letting their CRM partner change API terms on 30 days' notice -- one line, one catastrophic lock-in risk. We inventory every external service, API, and open-source library the product depends on, flagging which are load-bearing versus ancillary, and review the actual contracts -- SLAs, pricing tiers, rate limits, deprecation policies, data-ownership clauses. We also estimate the real migration effort for each critical dependency, since high switching cost is itself a form of deal risk. Pulling six months of cloud billing and looking for spikes or single-vendor concentration is often more revealing than any architecture diagram.
Testing, quality assurance, and release management. We once audited a logistics company deploying daily, only to find every release triggered a firefight -- no automated tests, no canary releases, just frantic rollbacks. Velocity without quality is disaster wearing a growth-metrics costume. We look at the testing pyramid and whether coverage is meaningful rather than just high, at how fast and how reliably the CI/CD pipeline actually builds, and at whether releases use blue-green deployments, canary releases, or feature flags to limit blast radius. Deployment frequency and mean time to recovery, taken together, tell you the team's real operating maturity far better than a stated process ever will.
Data architecture, privacy, and compliance. We once advised on a European health-tech build with genuinely impressive analytics and genuinely broken data-consent flows -- built for a single country, it blew past GDPR the moment it expanded. We review privacy policies, DPAs, and DPIAs and look for actual proof of GDPR/CCPA/HIPAA adherence, not just a stated policy; map data lineage from ingestion to archival and verify encryption, RBAC, and audit logging along the way; and list every subprocessor and confirm their own compliance and data-storage geography. Watching an engineer actually perform a "right to be forgotten" request live is the fastest way to find out whether compliance is real or theoretical.
Disaster recovery, business continuity, and operational resilience. We once walked away from an e-commerce deal because the disaster-recovery plan had never actually been tested -- backups existed, but nobody had ever pulled the trigger on a full restoration. A company that can't handle a major incident is a ticking clock in a 24/7 world. We check whether recovery-point and recovery-time objectives are documented and actually aligned with customer SLAs, whether backups are automated, geo-redundant, and regularly tested -- a backup that's never been restored is not a backup -- and whether failover is genuinely multi-zone and multi-region rather than aspirational. Asking for the last DR-test report -- the scenario, the timeline, what broke, what was learned -- tells you whether the team learns from failure or just documents good intentions.
Checking these boxes isn't about completing a to-do list -- it's how conviction actually gets built. None of this is about finding a flawless company; no company is flawless. It's about replacing guesswork with data: performance numbers, audit reports, real cost line items, and a live demonstration of disaster-recovery and data-deletion processes rather than a policy document describing them.
The highest-value output of diligence isn't a yes or a no -- it's the first hundred-day roadmap. Specific findings let you price risk accurately, negotiate the right representations and warranties, get the post-close team moving on the real issues immediately, and stress-test the thesis itself -- if global expansion is the pitch but the platform isn't multi-region, that's either a deal-breaker or a repriced one. We once nearly closed on a SaaS company with phenomenal unit economics, only to discover they were manually spinning up single-tenant instances for every client and their multi-tenant roadmap was pure vaporware -- a twelve-month rebuild in disguise. It didn't kill the deal, but it rewrote the valuation and the integration plan overnight.
This framework exists to shift the conversation from the story a founder tells to the truth the technology actually reveals -- asking the hard questions upfront so you can structure the deal, price the risk, and set realistic post-close milestones. At Osparna, we bring a builder's mindset to every piece of diligence, turning narrative into data and data into conviction.