The Build-Versus-Wrapper Read: One Startup's Repos, Start to Finish

Before a check clears, you want to know one thing that no deck answers: how much of this product is genuinely engineered, and how much is a thin layer over open-source code and third-party APIs. This guide is for early-stage investors, platform and talent partners, and angels who can read a repository but want a repeatable way to reach a defensible verdict. It carries one target company's public repos, manifests, and commit graph all the way through, with the intermediate counts and two wrong turns, so you can run the same read on a live deal.

The general technical-diligence method is covered elsewhere in this library. This teardown is narrower and sharper: it answers the build-versus-wrapper question that dominates AI-era diligence, where the fear is not that the code is bad but that there is barely any of it.

What the public surface can and cannot prove

Public repositories prove what a team declared and committed in the open. They do not prove what runs in production, because the substantive service is often private and server-side. Read the repo for evidence, then reconcile it against non-repo signals before you write anything down.

Each artifact answers a different question. Knowing what each one proves, and what it looks like when it lies to you, is most of the skill.

The manifest is your primary evidence, but it is not complete evidence. Package-manager scanning identifies only about 77 percent of a codebase's dependencies; the remaining portion enters by other means, including code pasted by AI coding assistants that never touches a manifest. That gap is structural and widening. Treat a clean manifest as a starting inventory, not a verdict.

Why raw open-source percentage tells you almost nothing

The single most common mistake is seeing a high open-source share and calling "wrapper." Do not. In the 2025 OSSRA benchmark, 97 percent of commercial codebases contain open source, and on average 70 percent of scanned code is open-source origin. Seventy percent borrowed is the population baseline, not a defect.

The share has climbed steadily. Open source rose from 35 percent of the average audited application in 2015 to 70 percent in 2025, and the average open-source file count roughly tripled from 5,386 in 2020 to 16,082 in 2024. Reuse is universal, so the raw ratio carries no information about defensibility.

The discriminating variable is different. It is the volume of original first-party modules the team wrote, and where that logic sits relative to the API call. A defensible first-party-lines-of-code ratio is not established publicly, so do not import a magic threshold. Instead, read the shape: substantial original modules that transform, orchestrate, or add proprietary logic point to a real build; a thin layer whose only job is to marshal an API request and format the response points to glue.

The worked example, end to end

Take one target: an early-stage AI company with a public org and two founder accounts. Here is the read carried through, with the counts and the two wrong turns.

Step 1, scope. The org holds nine public repos. Six are documentation, demos, or config. Three carry real code: a Python service, a TypeScript frontend, and a repo named core with 340 stars and a last commit two days ago. The founder accounts add two more, both experiments. Inventory done.

Step 2, manifests. Pulling requirements.txt, package.json, and their lock files yields a consolidated list of 611 direct and transitive packages. The typical application contains 911 open-source components and 64 percent of them are transitive, so this is a normal, mid-sized dependency graph. Nothing alarming yet.

First wrong turn. The frontend package.json is heavy, and cloc on the whole tree reports 240,000 lines. That looks like a serious build. It is not: the count included node_modules. Counting vendored dependencies makes a report look precise while quietly lying. Re-run with exclusions and the real first-party frontend is 14,000 lines. Lesson: verify the exclude flags before you trust a single LOC number.

Step 4, corrected count. Running scc and cloc with --exclude-dir vendor,node_modules gives 14,000 lines of frontend and 22,000 lines in the core Python service. That 22,000 is the number that matters. It is enough to be a real system if it contains real logic, and enough to be elaborate glue if it does not.

Step 5, lineage. The core repo's first commit adds 40 files across 3,100 lines, authored by both founders over the first week, with commits accreting daily after. That is organic. Contrast the second wrong turn below.

Second wrong turn. The Python service inference/ directory looked proprietary until I read the initial commit: a single commit dumping 1,800 files at once, authored by an email that appears nowhere else in the company's git history. GitHub did not mark it as a fork. It was still a lifted codebase, an open-source inference server pasted in wholesale. The multi-thousand-file first commit and the orphan author email are the tell. Manual comparison against likely upstream projects confirmed it. That 1,800-file directory should be subtracted from the "engineered" column entirely.

Step 6, API glue. Grepping imports across the corrected tree surfaces two external model providers and one vector-database SDK. In the frontend, calls go straight to the model API with only prompt formatting in between. In core, roughly 9,000 of the 22,000 lines sit between the API call and the user: a retrieval pipeline, a scoring layer, and caching that is genuinely the team's own logic. That is the substitution-test read: a technical user could reproduce the frontend by pasting the core prompt into a general model, but not the retrieval and scoring in core.

Step 7, copyleft. Filtering the SBOM for GPL, AGPL, and LGPL returns one LGPL library, dynamically linked and unmodified, and no AGPL. The LGPL hit is likely acceptable subject to legal advice. No source-disclosure trap here.

Step 8, reconcile. More on this in the talent section. The verdict: a genuine but modest build, roughly 27,600 first-party lines of which about 9,000 are defensible proprietary logic, one lifted inference component that must be rewritten or licensed, and a frontend that is glue. Confidence: moderate, with the private-monorepo caveat stated.

The procedure

Run these steps in order. Some practitioners generate the SBOM after counting lines rather than before; the order between steps 3 and 4 is not fixed, but every other dependency holds.

Reading lineage from the commit graph

The commit graph proves whether a codebase was built or copied. GitHub preserves lineage: once a commit exists you can scroll history to the first commit ever made. Read that first commit before anything else.

Three signals separate an organic build from a lifted one. Each has a clear tell and a clear failure mode.

GitHub's fork flag is a convenience, not a guarantee. A team can clone a repository, strip its history, and commit the result as a fresh project, and the flag will never appear. GitHub's own fork view will not easily diff a fork against its origin, so manual comparison against the likely upstream is the fallback. Tools that parse git author and commit metadata help you enumerate authors quickly, but the judgement is yours.

Copyleft is where the money is lost

The most expensive finding in a repo read is usually legal, not architectural. A single manifest line can outweigh a whole codebase's quality. GPL, AGPL, and LGPL are the flags, and AGPL is the one that ends deals.

A defensible license policy sorts licenses into three buckets: pre-approved, typically MIT, Apache 2.0, and BSD; requiring legal review, such as LGPL, MPL, and EPL; and prohibited absent a commercial license, meaning GPL and AGPL. AGPL is sharpest for SaaS because it closed the web-service loophole: if a hosted application uses AGPL code, the operator must offer source to its users. Many founders believe GPL does not reach web services. AGPL specifically does.

License conflicts are common enough that you should expect to find something: 56 percent of audited codebases contained license conflicts, and 33 percent had components with no or customized licenses. Not every hit is fatal. An LGPL library may be acceptable if dynamically linked and unmodified, depending on legal advice. Read the linkage and the network use, not just the license string.

The talent read the repo cannot fake

A repo can be staged; a hiring market cannot. Talent composition is the leading indicator you cross-check against the code, and it is the step that rules out the private-monorepo false positive. A real build must hire scarce deep-systems talent, while a glue-heavy org over-indexes on prompt and integration roles.

In Refolk's index of professional profiles, the shape is measurable. Among US software and machine-learning engineers, deep-systems CUDA talent outnumbers prompt-engineering talent, and the title mix inside each cohort skews sharply.

The ratio is 1.26 to one in favor of CUDA, and the title mix inside each sample tells you more. In a 25-row sample per cohort, CUDA engineers were 44 percent ML-engineer titles, while prompt-engineering profiles were 16 percent. A team building below the API layer hires the former; a team assembling glue hires the latter. Treat the sample shares as directional, not population-level.

Geography constrains the thesis further. The same skill is far thinner outside the US, which is a checkable stress point on any "deep infrastructure" claim from a European team.

If a Berlin-based startup claims a deep-infra build, the roughly 17-to-one gap in available CUDA talent is a real hiring constraint you can raise in the partner meeting. It does not prove the claim false, but it shifts the burden of proof onto the founders.

This is exactly where pulling the target's team profile by hand becomes the bottleneck. Cross-referencing who a company actually employs against the skills a real build requires is the reconciliation step, and it is slow when you do it one LinkedIn tab at a time.

Two example queries turn the reconciliation into minutes: one for engineers who list CUDA, Triton, or PyTorch, and one for people whose title says prompt engineering or LLM integration but who show no ML or systems background. The first confirms a build; the second surfaces a glue-heavy org. With Refolk you ask in plain English and get the named people across LinkedIn, GitHub, and the open web, rather than reconstructing the team by hand.

How this read goes wrong

Every failure mode below has cost someone a correct verdict. Treat this section as the load-bearing part of the standard.

• Dependency-percentage panic. Seeing 70 percent open source and calling "wrapper." That figure is the industry average, not a defect. Check first-party original modules, not the raw ratio.
• Manifest completeness illusion. A clean manifest looks authoritative but misses roughly 23 percent of code. Vendored and AI-pasted code hides. Grep for vendor directories and unexplained large files before you trust the declared list.
• LOC gaming. Counting node_modules, vendor, generated output, or checked-in artifacts inflates the "engineering" number. Verify the exclusion flags were applied, as in the first wrong turn above.
• Fork mislabel. A repo can be a hard copy without GitHub's fork flag. The multi-thousand-file first commit with an orphan author email is the real tell, as in the second wrong turn.
• Sparse-repo false positive. A thin public repo often fronts a private monorepo. Rule it out via hiring mix and server-side architecture before concluding thin product.
• License false alarm. Not every copyleft hit is fatal. LGPL is often acceptable when dynamically linked and unmodified, subject to legal advice. Read linkage and network use.
• Substitution-test overreach. Passing the substitution test does not prove a moat. The remaining 20 percent, the UI, onboarding, and brand, is real, but it is a head start, not a moat.

Weigh the stakes when you write the verdict. Technical issues found in diligence can cut valuation by up to 20 percent, and nearly 60 percent of deals fall through on technical-review problems. A wrong read in either direction is expensive: a false "wrapper" kills a real build, and a false "build" funds glue.

Before you call it done

Run this checklist against your written read. If any item is unchecked, the verdict is not yet defensible.

Keeping the read current

A build-versus-wrapper read has a shelf life. Repos change between term sheet and close, and the cheapest way for a founder to answer your concern is to rewrite the glue you flagged. Re-run the line count and the commit-graph check on the eve of signing, and note any new large commits since your first pass.

The benchmarks move too. The open-source share and the manifest blind spot both trend upward year over year, so treat the 70 percent baseline and the 77 percent identifiable-dependency figure as mechanisms to re-check against the current OSSRA report, not fixed constants. The mechanism is stable even when the number drifts: reuse is universal, so the borrowed percentage stays silent on defensibility, and you keep reading the same two variables, original first-party modules and where the logic sits relative to the API call.

Finally, keep the talent read live. A company that raises on a deep-build thesis should be hiring deep-build talent within a quarter or two. If the new hires are all prompt and integration roles while the pitch says infrastructure, the earlier code read was probably too generous, and that is the cheapest signal to monitor after the check clears.