Technical Verification

Is it real code, or a template
with a new logo?

It’s the first question every buyer of a pre-revenue asset asks, and no other marketplace answers it with evidence. Connect the repository read-only and DayXero produces a Build Integrity Report — six machine-run checks, none of which rely on the seller’s word.

Verify your assetBrowse verified listings
Build Integrity Report
Sample output
Commit history
Incremental — 411 commits over 14 months
Template lineage
No known boilerplate detected
Licence conflicts
None — all dependencies permissive
Dependency scan
2 moderate CVEs · 0 critical
Test coverage
64% of core modules
Third-party API weight
31% of runtime paths
Read-only access, revoked when the scan completes. Source code is never exposed to buyers — only the findings. A seller can run the scan privately first and choose whether to publish it.

What gets checked

Six checks, each answering a question a buyer would otherwise have to take on trust.

Commit history analysis
Was this built, or dumped?

Real development leaves a trail — hundreds of incremental commits across months, with the shape of actual work. A single bulk commit, or a history that starts fully-formed, indicates a fork, a purchase, or an import. Both are legitimate; neither should be presented as original work.

Template lineage detection
Is this a boilerplate with a new logo?

The defining fear when buying a pre-revenue asset. We fingerprint the codebase against known starter kits, templates, and public boilerplates. A match doesn’t disqualify an asset — but a buyer is entitled to know before they pay.

Licence conflict scan
Can the buyer legally own this?

Copyleft dependencies buried three levels deep can make a codebase legally unsellable in a commercial context. We resolve the full dependency tree and flag anything whose licence conflicts with a change of ownership.

Dependency vulnerability scan
What is the buyer inheriting?

Known CVEs across the dependency tree, graded by severity, with a note on how far behind the project has drifted. Technical debt priced at diligence is cheaper than technical debt discovered post-close.

Test coverage & structure
Can someone else maintain it?

Coverage across core modules, presence of a test suite at all, and whether the architecture is comprehensible to a new owner. A product only its author can maintain carries a real discount.

Third-party API weight
How much of this is actually yours?

What share of runtime paths depend on external APIs. A thin wrapper over someone else’s service is a legitimate business, but it is not the same asset as one carrying its own logic — and it feeds directly into the Commodity Risk figure on the ADR.

It upgrades Clean IP from claim to evidence
The Clean IP badge used to rest on an eight-point checklist the seller filled in themselves. Verification turns the technical half of that checklist into a machine-confirmed finding. A badge nobody audits is decoration.
It feeds the Commodity Risk score
Template lineage and third-party API weight are direct inputs to the Commodity Risk figure in the Asset Durability Report. Verified assets get a more accurate — and often more favourable — valuation.
It protects honest sellers most
If you actually built it over fourteen months, you are currently indistinguishable from someone who forked a template last week. Verification is how you prove the difference and defend your asking price.
What verification does not tell you

It confirms how the code was built, not whether the product is good. A clean report on a well-engineered thing nobody wants is still a clean report on a thing nobody wants — judgement on market, timing, and strategic fit remains yours.

Template detection is fingerprint-based, so it catches known boilerplates rather than every possible derivation. And a private repository can only be scanned with the seller’s consent — an unverified listing isn’t evidence of a problem, only an absence of evidence. We label it that way rather than implying otherwise.

Verify your assetHow the ADR uses this