142 endpoints. Zero documentation. Three months I never got back.
The diligence team flagged it on day four. A $45M ARR SaaS platform, healthy net retention, a logo wall any founder would envy — and 142 production API endpoints that existed nowhere except in the heads of two senior engineers, one of whom had given notice. Each one had been spun up to close a specific enterprise deal: a custom export for the insurer, a bespoke webhook for the logistics customer, a one-off auth flow because a Fortune 500 procurement team demanded it. Individually, every decision made sense in the moment. Collectively, they were a seven-figure deduction waiting to be discovered.
I froze the product roadmap for three months. Not to build features — to find out what we'd already built. We had to enumerate every endpoint, identify which customers depended on it, reconstruct the payload shapes, and decide what to document versus decommission, all before the buyer's technical audit started. That is the worst possible time to learn how your own platform works. And it's exactly when most founder-CEOs learn it, because the integration layer is the part of the product nobody owns until someone tries to buy the company.
This is the pattern I see at $15M to $50M ARR, again and again: you built fast, you let engineering write bespoke connectors for whoever shouted loudest, and now every release breaks three legacy integrations because there's no contract governing how anything talks to anything. Bain's 2025 Software M&A Technical Due Diligence Report ties poorly documented integration layers to as much as a 30% reduction in post-merger synergy realization — which is a polite way of saying the buyer assumes your stack will be expensive to absorb and prices accordingly. If your "platform" is really a pile of one-off scripts with a login page, you're running a monolith in disguise, and a sharp acquirer will spot it before lunch.
The spec is the asset. The code is just the implementation.
Here's the reframe that changes how a SaaS company gets valued: your API is not internal plumbing, and the REST-versus-GraphQL debate is not your problem. Your problem is that the contract — what an endpoint accepts, what it returns, how it fails, how fast you'll throttle it — lives as tribal knowledge instead of a versioned, machine-readable specification. Fix that ordering and most of the chaos resolves itself.
Adopt API-first as a hard process rule: the OpenAPI specification gets written, reviewed, and approved before functional code exists. The spec defines authentication, error semantics, status codes, and rate-limit thresholds up front, so the implementation has something to conform to rather than the other way around. Critically, that documentation cannot live in a wiki that's stale the moment someone merges — it must be generated from code annotations so the map and the territory can never drift. Gartner's 2026 API Strategy and Governance Benchmark found that organizations enforcing strict OpenAPI standards cut third-party developer onboarding time by roughly 45%. Translated for a founder: a partner can build against you in days instead of filing support tickets for weeks, and integration time is the silent tax on every enterprise deal you're trying to close.
Two disciplines separate a platform from a tool here. First, semantic versioning with an enforced backward-compatibility guarantee — when a junior engineer renames a JSON key and silently breaks a customer's nightly sync, that's not a bug, it's a breach of contract, and it should be impossible to ship. Second, treating extensibility as a revenue lever, not a cost center: McKinsey's Global API Economy Analysis attributes a 20% lift in ecosystem-generated revenue to well-documented, standardized APIs over closed ones. The moment partners can reliably build on you, you stop selling seats and start selling infrastructure — and infrastructure carries a different multiple. When you're ready to show this to a buyer, package it the way the data room expects, per our technical architecture documentation standards for M&A data rooms.
Shadow APIs are how SaaS companies quietly fail security diligence
Building the API is maybe 20% of the work. The 80% that destroys valuations is lifecycle governance — specifically, what happens to an endpoint after the deal that justified it is long closed. A team ships an endpoint for a 60-day pilot. The pilot ends. The endpoint stays live, unmonitored, still wired to production data, for three years. Now multiply that by every pilot you've ever run. Forrester's 2025 State of API Security Report traces 60% of B2B SaaS data breaches to exactly these unmanaged, deprecated "shadow APIs" that nobody ever formally decommissioned. In diligence, every one is both a security finding and a sign that you don't actually know your own attack surface.
Two mechanisms shut this down. The first is a documented deprecation policy: how long a version is supported, how customers get notified, what the migration path is — tracked with the same rigor you give to NRR or burn. The second is a mandatory API gateway as your single control plane for routing, observability, and access. The rule is absolute: if an endpoint isn't registered in the gateway, it does not get to touch the production database. That one constraint makes shadow APIs structurally impossible to create, because there's no longer a back door to create them through. Institutionalizing this is the same muscle as turning any critical workflow into a repeatable system — see going from tribal knowledge to turnkey documentation.
Here's the number that should reframe how you spend next quarter's engineering capacity: MIT Sloan's Strategic Value of APIs Study found platforms with formal API lifecycle governance command roughly 3x the enterprise valuation multiple of those running ad-hoc integrations. Whether or not you ever sell, you're building an asset someone could underwrite — and every undocumented endpoint, every orphaned shadow API, every hardcoded client integration is a line-item deduction from what it's worth. So this week, do one concrete thing: pull a list of every live endpoint, map each to the customers depending on it, and flag the ones nobody can name. That list is your roadmap. Whatever you can't account for, a buyer will find — and they'll make you pay for it twice, once in remediation and once in the multiple.
