Technical due diligence
What a target's codebase runs is rarely what the deal model assumes
A scoped technical due diligence engagement for private equity: $10,000–$25,000, one to three weeks. We read what a target company's codebase, dependencies and infrastructure actually run — not what the deck says — and hand back a report specific enough to become the remediation scope, if one is warranted.
Technical due diligence, scoped to one question
For the people who decide whether a deal or a portfolio company gets a technical read before the number goes firm — an operating partner, a portfolio CTO, whoever is running diligence on a target that runs on software nobody at the fund wrote.
$10,000–$25,000, one to three weeks. We read what a target company's codebase, dependencies and infrastructure actually run, find the specific legacy-stack or security exposure it carries, and hand back a report scoped enough to become the remediation plan — if the deal proceeds and one is warranted.
Works either side of a close. Pre-signing, it runs alongside financial and legal diligence. Post-close, it's the same read applied to a portfolio company nobody has looked at technically since the deal that brought it in.
Patterns we see
Twelve patterns from public research into small, real software companies. Each one is its own page, with the fuller pain point, the business impact, and what the diligence engagement checks for it.
Field-service and facilities-management software
A scheduling and billing platform still on .NET Framework, paired with a legacy WinForms desktop client.
Read the pattern →
Application monitoring and developer-tooling software
Core architecture predating the current generation of tools in its own category.
Read the pattern →
Membership and case-management software for member-based organizations
A core platform on ASP.NET Web Forms, unfunded by Microsoft since 2016.
Read the pattern →
Dispatch and fleet-management software for vehicle-recovery operators
Several older, founder-built platforms still running un-unified after a roll-up.
Read the pattern →
Public-records-request and workflow software for government agencies
A platform well over a decade old, with no evident ground-up rebuild behind a recent brand refresh.
Read the pattern →
Product-lifecycle and specification-management software for consumer-goods manufacturers
A small, bootstrapped platform modernizing after its first outside investment.
Read the pattern →
Travel-industry booking and reservations software
A booking engine that predates cloud-native architecture by well over a decade.
Read the pattern →
Safety and regulatory-compliance software, with a hardware component
A modern backend serving a login flow built on several-year-old front-end dependencies.
Read the pattern →
Template-based online video-creation software
A single-page-app framework choice from the early-to-mid 2010s, never rewritten.
Read the pattern →
Vehicle inspection and appraisal software
A decade-old front-end stack still live ahead of a sale, invisible to a check of the current, rebuilt site.
Read the pattern →
Drag-and-drop online form and survey-builder software
An unframeworked backend built up over roughly two decades.
Read the pattern →
Conversational-AI and customer-engagement software for enterprise clients
A core product console with infrastructure quietly drifted out of sync.
Read the pattern →These are patterns from public research on real, small software companies, not completed Shashtram engagements. Named engagements with measured figures replace them as clients clear being named.
This is Map, priced and scoped — not a rewrite pitch
Diligence isn't a separate product. It's Map — the same first phase behind every engagement, scoped to one question instead of a whole platform, and priced on its own because a fund needs to approve it without a process. What ends it is the same shape as any Map: a scope, a measure of the specific risk found, a remediation plan where one is warranted, and an honest answer where there isn't one.
It never assumes a rebuild follows. Most of the value in a $10,000–$25,000 read is knowing what's actually running before you sign, or before a portfolio company gets folded into a bigger platform — not committing you to fix it through us. If the report finds something worth acting on, Build is a separate, separately-scoped conversation, not an assumed next step.
Questions
Straight answers.
What does the technical due diligence report cover?
What's actually running under a target's product — the real framework and dependency versions, not what's in the pitch deck — the specific legacy-stack, security or infrastructure risk we find, and a scoped estimate of what remediating it would cost and take. It's the same shape Map produces on a larger engagement: a scope, a measure, a plan, and an honest read on whether one is even warranted — priced and timed for a single question instead of a whole platform.
How fast is this, and what does it cost?
$10,000–$25,000, one to three weeks, scoped and priced before we start. It doesn't require a data room to begin: several of the patterns on this page were found from outside the company entirely — a live site, a job posting, an archived snapshot — before any access was granted.
What if we don't proceed to a rebuild after the report?
Then the report is what you paid for, and the engagement ends there. Nothing about the diligence commits you to a modernization project — most of the value in a $10,000–$25,000 read is knowing what you're actually buying, whether or not you act on it afterward.
Do you need access to the codebase, or can you work from the outside?
Both, depending on the stage. Pre-LOI, we can often get a useful read from what's publicly observable — live infrastructure, dependency versions, job postings, archived snapshots. Once there's a data room or management cooperation, the same read goes deeper: repo access and a conversation with whoever owns the code answer questions an outside read can't.
Is this the same thing as your modernization work?
No. This is diligence — a read, not a rebuild. [Map, build and run](/map-build-run) is the delivery model for the layer itself, and this engagement is priced separately as a scoped version of the first phase, Map. If the report finds something worth fixing, that's a separate, separately-scoped conversation, not an assumed next step.
Start here
Bring us one workflow.
Tell us the process that crosses the most systems. You get a scope, a measure and a delivery plan back — and a straight answer if we think it is not worth building.
Get in touch