The math on a vendor fee you "saved"
A $45M ARR SaaS company I looked at last quarter spent 14 months building its own subscription-management engine. The trigger was a $50k annual vendor invoice that the CTO refused to sign. The build worked. It billed customers, handled proration, processed dunning. It also cost roughly $850k in fully-loaded engineering time plus localized technical debt, and it pushed three roadmap features — the ones sales kept losing deals without — into the following year. They saved fifty grand a year and spent the equivalent of a Series A milestone to do it.
This is the specific trap for Series B and C SaaS: you have just enough senior engineering talent to build almost anything, and just enough cash that the vendor line item looks insulting next to a salary you're already paying. So the team reasons that billing, internal auth, the deploy pipeline, the customer-data sync — they can own all of it. The flaw isn't the build quality. It's that every one of those systems now needs a human forever, and that human is your most expensive engineer, not a per-seat SaaS subscription that amortizes maintenance across ten thousand other customers.
McKinsey's 2025 Custom Software Development Cost Benchmark puts a number on the drag: companies that index heavily on building their own operational software see feature velocity fall by roughly 42% over three years. Not because the code is bad — because the code is alive, and alive code eats sprint capacity whether or not it ships anything new. You are paying staff engineers to be administrators for an app with fifty internal users.
What the buyer's diligence team actually does with it
Here is the part founders don't see coming until the data room is open. When a PE sponsor's diligence team finds a home-grown billing engine or a bespoke identity layer, they do not write down "impressive internal capability." They open a spreadsheet and price the replacement. Stripe to swap in for your billing system. Salesforce or HubSpot for your custom CRM wrapper. They estimate the migration effort, the data-integrity risk, the months of parallel running, and the chance that the one engineer who understands the system leaves mid-integration. That number comes straight off your enterprise value.
It is not a vibe. Bain & Company's 2025 M&A Technology Due Diligence Report finds acquirers routinely discount target valuations 15% to 20% when core business processes depend on undocumented, custom-built architectures. The discount is largest exactly where Series B/C companies are weakest: key-person risk. If the original architect of your subscription engine is the only person who can safely touch dunning logic, the buyer treats that as a single point of failure on your cash collection — and prices it like one.
And the systems don't even last. Forrester's 2025 Commercial Off-The-Shelf vs. Custom Build ROI Benchmark reports that about 70% of custom internal applications are abandoned or fully rewritten within 36 months. So the realistic lifecycle of the billing engine that took 14 months to build is: ship it, maintain it through two reorgs, then rewrite or retire it right around the time you're prepping for a raise or a sale. You paid for it twice and got credit for none of it. This is one of the quieter technology due diligence red flags that kill deals — quiet because it looks like productivity right up until someone tries to value it.
The one-page test before anyone opens an editor
The fix is a rule simple enough to enforce in a planning meeting: build Core, buy Context. Core is the proprietary algorithm, the data model, the workflow your customers pay you for and can't get anywhere else. Context is billing, HR, identity, logging, internal dashboards — necessary, undifferentiated, and available off the shelf from someone whose entire company exists to maintain it. The subscription engine that started this? Context. Nobody renews your SaaS contract because your dunning emails are bespoke.
Run this before the first commit. Draw a line from the proposed system to a customer who would pay more, churn less, or close faster because it exists. If you can't draw that line in one sentence without using the word "eventually," you're building Context, and you buy Context. MIT Sloan Management Review's Core vs. Context Software Productivity Index shows top-quartile engineering teams keep internal-tool maintenance under 12% of total capacity. If your repos say otherwise, you've found your velocity leak.
There's also an accounting edge to this for anyone eyeing an exit. PwC's 2026 Software Development Capitalization Study indicates auditors now reject around 40% of capitalized R&D when the code serves internal operations rather than saleable product — which means the engineering hours you booked as an asset get reclassified as expense, and that hits EBITDA directly. So the Monday move: have your engineering leads map active repos to revenue using a technical debt quantification framework, flag every Context system with a single maintainer, and put a buy-or-sunset decision on each one before your next diligence cycle does it for you. The earlier you decide, the cheaper the migration — and the cleaner the data room.
