Tech Stack Due Diligence M&A: What to Check Before You Buy

Every acquirer’s playbook covers code quality, infrastructure review, security questionnaires, and the seller’s incident history. What very few cover well is the external tech footprint — the same surface a black-hat researcher would map in an afternoon. A target that looks clean in a data room can light up red on a passive scan.

This guide walks through the pre-LOI technology due diligence checklist that buyers run on us, on each other, and (increasingly) on themselves before they sign. Every step is reproducible with curl, dig, and one DetectZeStack API call. None of it requires the seller’s cooperation, which is exactly the point: you want to see what a stranger sees.

Why Tech Stack Due Diligence Matters in M&A

A seller controls every document in the data room. They do not control DNS, certificate transparency logs, the headers their CDN returns, or which versions of jQuery are referenced from the public site. That gap is where surprises live.

Real examples we’ve seen surface from a thirty-minute external scan:

• Hosting concentration risk that wasn’t in the architecture deck. Seller said “multi-cloud.” CNAME chain said 100% Cloudflare in front of a single AWS region. A Cloudflare outage during diligence would have made the post-close integration story very different.
• An unsupported CMS major version still in production behind a marketing subdomain that nobody mentioned. CPE lookup against the NVD returned eleven CVEs, three of them with a CVSS above 9.
• SPF record set to ~all (soft fail) instead of -all, with no DMARC policy at all. The target had a paying-customer email channel and was effectively spoofable on day one.
• A wildcard TLS certificate expiring eight days after the proposed close date. Renewal was on the seller’s ops checklist, which was now your problem.

None of these block a deal. They adjust price, scope the integration plan, or land in the indemnity schedule. But you have to find them before the LOI, not after, because by then the leverage is gone.

The Pre-LOI Tech Stack Due Diligence M&A Checklist

Five passes, each producing an artifact you keep in the diligence file. Run them in order — later passes depend on output from earlier ones.

1. Confirm the Target’s Public-Facing Technology Footprint

Step one is the ground truth: what does the target actually run? Not what the seller’s deck says, what their public properties expose. Frameworks, CMS, analytics, payment processors, marketing tools, chat widgets, error trackers, every third-party SaaS that ships JavaScript or DNS records.

The fastest way to get this is a single API call. The /demo endpoint requires no key and works against any domain:

$ curl -s "https://detectzestack.com/demo?url=target-company.com" | jq '.technologies[] | {name, categories, confidence, source}'
{
  "name": "Nginx",
  "categories": ["Web servers", "Reverse proxies"],
  "confidence": 100,
  "source": "http"
}
{
  "name": "Cloudflare",
  "categories": ["CDN"],
  "confidence": 100,
  "source": "http"
}
{
  "name": "HSTS",
  "categories": ["Security"],
  "confidence": 100,
  "source": "http"
}

The full /analyze response also returns a categories map (technology grouped by purpose), and a top-level meta block with status_code, tech_count, and scan_depth. scan_depth: "full" means HTTP + DNS + TLS all returned data. scan_depth: "partial" means the site blocked HTTP and DetectZeStack fell back to DNS and TLS only — itself a useful signal for diligence (sites that aggressively block scans often have something behind that decision).

For a single-domain target this is one call. For a target with subsidiaries, microsites, or acquired brands, you want the batch approach — covered in how to batch-scan 1,000 websites.

2. Audit Hosting, CDN, and DNS Provider Risk

Concentration risk is the diligence finding that turns into the most painful post-close conversation, because it’s structural. A target running its production site, its support portal, its status page, and its DNS through a single provider has one vendor between them and a multi-hour outage.

Pull the hosting, CDN, and DNS providers from the same /analyze response. The categories map groups them for you:

$ curl -s "https://detectzestack.com/demo?url=target-company.com" \
  | jq '.categories | {CDN, PaaS, "DNS": .DNS, "Reverse proxies": ."Reverse proxies"}'
{
  "CDN": ["Cloudflare"],
  "PaaS": ["Amazon Web Services"],
  "DNS": null,
  "Reverse proxies": ["Nginx"]
}

Run the same call against every public property the target operates — main site, app subdomain, docs, status, support, blog, plus any country-specific or product-specific properties. A clean pattern is “the marketing site is on Vercel, the app is on AWS, status is on Statuspage” — three different providers, none of them single points of failure for the others. A risky pattern is “everything is one Cloudflare account.”

For deeper DNS analysis — SPF, DKIM, DMARC, MX, NS — pair this with the techniques in DNS intelligence: SPF, DKIM, and DMARC. Email authentication is the most under-audited area in M&A diligence and the most common source of post-close surprises.

3. Surface Known Vulnerabilities via CPE Identifiers

A technology name is not a risk. A technology name plus a version plus a CPE identifier is a risk you can quantify. The /analyze response includes a cpe field for technologies with published CPE strings:

$ curl -s "https://detectzestack.com/demo?url=target-company.com" \
  | jq '.technologies[] | select(.cpe != "" and .cpe != null) | {name, version, cpe}'
{
  "name": "Nginx",
  "version": "",
  "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*"
}
{
  "name": "WordPress",
  "version": "5.8.2",
  "cpe": "cpe:2.3:a:wordpress:wordpress:*:*:*:*:*:*:*:*"
}

Each CPE string is a pivot point into the National Vulnerability Database. A security analyst on the diligence team can paste it into the NVD’s CPE-search API and pull every CVE that affects that product family. Where a version is detected (e.g., 5.8.2), you can filter to CVEs that apply specifically to that version — turning “the target uses WordPress” into “the target runs a WordPress version with three high-severity CVEs unpatched against their detected plugin set.”

That second sentence is the line that adjusts price or moves an item into the indemnity schedule. The first sentence does nothing. For the full methodology — how CPE lookup chains through to CVE lists, and how to keep the resulting risk register current — see detect vulnerable technologies with CPE and the deeper treatment in security audit: website dependencies with CPE.

4. Check TLS, Security Headers, and Email Authentication

This pass takes ten minutes and finds things buyers routinely miss.

TLS certificate: What’s the issuer, when does it expire, who manages renewal? A certificate expiring within ninety days of the proposed close needs to be on someone’s integration checklist. A certificate issued by a defunct CA, or one with a wildcard that covers more than the seller disclosed, is a flag.

$ echo | openssl s_client -connect target-company.com:443 -servername target-company.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates
issuer=C=US, O=Let's Encrypt, CN=R10
subject=CN=target-company.com
notBefore=Apr 12 00:00:00 2026 GMT
notAfter=Jul 11 23:59:59 2026 GMT

Security headers: The presence (or absence) of HSTS, Content-Security-Policy, X-Frame-Options, and Referrer-Policy tells you how seriously the target treats web security as a discipline. A target with no HSTS and no CSP isn’t necessarily breached, but it’s a posture signal — usually correlated with engineering bandwidth being spent elsewhere.

Email authentication: Pull the SPF, DKIM, and DMARC records for every domain that sends mail. SPF set to -all with a published DMARC policy of p=reject is the target you want. SPF set to ~all with no DMARC at all is — depending on the target’s industry — a finding that affects deliverability, brand-spoofing risk, and any future security questionnaire.

DetectZeStack surfaces all of this in the same /analyze call — HSTS appears in the technologies array with categories: ["Security"], TLS issuer appears as a separate “SSL/TLS certificate authority” entry, and the full DNS-derived view is available via the dedicated DNS endpoint covered in DNS intelligence: SPF, DKIM, and DMARC.

5. Track Tech Changes Across the Diligence Window

Diligence is not a snapshot. The period between LOI and close is where sellers occasionally do things you’d rather they hadn’t — switch CDNs, swap a vendor, deploy a new analytics tool, ship a major framework upgrade. Sometimes that’s fine. Sometimes you find out at close that the production stack you scoped during diligence isn’t the stack you’re buying.

Set a tech-change baseline at LOI signing. Re-scan weekly. Diff the results. If a new technology appears, you want a written explanation from the seller. If a critical one disappears (analytics, error tracking, security tooling) you want to know why before close.

The mechanics — baseline capture, scheduled re-scan, diff, alert — are covered end-to-end in track website tech changes via the API. For acquirers, the practical pattern is a weekly cron that scans every property in the diligence file, compares to the baseline, and emails the diligence lead on any add/remove. The whole pipeline is under fifty lines of shell.

How to Run a Tech Stack Audit With the DetectZeStack API

Three patterns cover most acquirer workflows.

Single-Domain Analyze Call

The starting point. Free to test against /demo, no key required:

$ curl -s "https://detectzestack.com/demo?url=target-company.com" | jq .
{
  "url": "https://target-company.com",
  "domain": "target-company.com",
  "technologies": [ /* ... */ ],
  "categories": { "CDN": ["Cloudflare"], "PaaS": ["Amazon Web Services"] },
  "meta": { "status_code": 200, "tech_count": 14, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

For production diligence runs use the authenticated endpoint via RapidAPI, which lifts rate limits and returns the same shape:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=target-company.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq .meta
{
  "status_code": 200,
  "tech_count": 14,
  "scan_depth": "full"
}

Batch-Scan an Acquisition Target’s Subsidiaries

Most targets above a certain size operate more than one domain — product subsidiaries, acquired brands, regional sites, status pages, support portals. A diligence list of fifty domains is unremarkable. A list of five hundred happens.

Feed a CSV through the API and write the JSON responses to disk. The batch-scanning 1,000 websites guide has the full pattern with concurrency limits, retry logic, and caching tuned for the DetectZeStack rate ceilings. The headline cost is roughly $9/month at 1,000 domains scanned weekly — cheaper than one hour of an analyst’s time, and reproducible from week to week.

Compare Acquirer vs. Target Stacks

This is the integration-planning pass. Once you have a clean /analyze result for both sides of the deal, diff the technology lists. The overlap is your “already standardized” column. The acquirer-only column is what the target will migrate onto. The target-only column is what you’ll keep running (because it’s load-bearing) or deprecate (because the cost-of-keeping outweighs the cost-of-migrating).

That comparison drives the integration budget and the integration timeline. It is also the input to the “what does post-close month one look like” document that boards ask for. The reusable pattern is covered in competitor website technology analysis, which uses the same diff mechanics in a competitive-intel context.

Red Flags That Should Adjust the Purchase Price

Not every finding moves the price. Some belong in the integration plan, some belong in the indemnity schedule, some are noise. The list below is what we’ve seen materially change deal terms:

From Diligence to Post-Close Integration

The artifact you ship out of pre-LOI diligence becomes the day-one artifact of post-close integration. Keep it machine-readable. Specifically:

• One JSON file per property, named by domain, holding the full /analyze response. This is your baseline.
• One CSV that flattens the JSON into one row per (domain, technology, category, confidence, source, cpe). This is the input to your risk register and your integration backlog.
• A weekly cron that re-runs the scan and writes a dated copy into a diffs/ folder. The diff between any two dated copies is your “what changed” report for stakeholders.
• A short README describing the methodology — which endpoints, which date range, which subsidiaries were in scope. Future you will want this; so will the next person to own integration.

If your post-close roadmap includes consolidating vendors (almost every one does), this dataset is also the dataset you use to scope the consolidation. “Migrate the four marketing sites off Wix onto our Webflow account” is concrete because you have the four sites in a CSV. “Modernize the front end” is not.

Get Started

The fastest way to see what a passive tech-stack scan looks like is to run one against a domain you already know. Pick a portfolio company, a former employer, a competitor, or your own marketing site:

$ curl -s "https://detectzestack.com/demo?url=YOUR-DOMAIN.com" | jq .

No key needed for /demo. Same response shape as the authenticated /analyze endpoint — you can prototype an entire diligence pipeline against /demo before you ever issue a key.

For diligence at scale — multiple targets, weekly re-scans, hundreds of subsidiaries — the $9/month tier on RapidAPI covers 1,000 requests, which is well above what a single deal needs. The $29/month tier covers 10,000 requests and is comfortable for a small corp-dev team running scans across an active pipeline.