Buy vs build Nark

Last updated: July 23, 2026

TL;DR

Yes, you could build this. The scanner itself is a Semgrep rule engine and a small YAML DSL. The cost is not the scanner. The cost is the ongoing maintenance of the rule library. Nark maintains 170+ Nark Profiles on a weekly cadence, and the design-partner tier at $2K per month is cheaper than one FTE for any team above five developers.

What you would build

The scanner side of Nark is not exotic. If you sat down to build a v1 that covered your top 20 npm packages, you would ship these components:

A rule DSL. Realistically a YAML shape mapping package plus method plus pre-condition plus post-condition, with a fix hint string per rule.
A scanner that walks the TypeScript AST via ts-morph or the compiler API, resolves import symbols against the real type checker, and matches call sites against the DSL.
A CI runner. A GitHub Action or equivalent that runs the scanner on every pull request, diffs against the base branch, and posts a check.
A suppression system. Known-safe patterns need a way to be excluded without deleting the rule, ideally with a comment directive and a project-level suppressions file.
A profile library. One YAML file per covered package, hand-authored from the package's docs, changelog, and real-world failure modes.
Weekly maintenance. When a covered package cuts a version, the profile has to be re-verified or forked.

For a strong TypeScript team with prior static-analysis experience, that is roughly three to six weeks of engineer time for a v1 that catches the top 20 packages. Not free, but not unreasonable. Which is why the buy-vs-build question is a real question and not a rhetorical one.

Where the real cost is

The scanner is the small line item. The library maintenance is the large one, and it never stops.

Each Nark Profile takes 4 to 20 hours of research to author. Reading the author's docs is the easy part. The harder work is the changelog crawl, the CVE writeups, the GitHub issue history, and empirical testing against real repos to see which patterns show up in the wild versus which are theoretical.

Then, per covered package, per week:

A minor version ships. Is the error surface unchanged? Usually yes. Roughly one hour to verify against the changelog and the type declarations.
A major version ships. Is the error surface changed? Usually yes, at least in part. Fork the profile, re-run the empirical tests, and mark the version boundary. Roughly 4 to 16 hours.
A CVE or postmortem surfaces a new failure mode. Add it to the profile. Roughly 2 to 6 hours per finding.

Nark runs this pipeline for 170+ packages weekly via a purpose-built maintenance workflow. If you replicate it, you own it forever.

The buy-vs-build math

Assume the smallest reasonable coverage for a modern TypeScript app: 20 packages. That is roughly axios, prisma, a queue client, a cloud SDK, an ORM, a payment SDK, an AI SDK, an auth library, a logger, and a handful of smaller packages.

Ongoing maintenance for 20 covered packages runs about 5 hours per week: version drift monitoring, one or two profile fixes per week, and one or two new profiles per quarter as the stack evolves.

One senior TypeScript engineer at $250K fully loaded works out to about $130 per hour. Adjust for your local market. Even in markets where senior engineers cost less, the ratio shifts but the conclusion holds.

Weekly cost: $130 times 5 equals $650 per week, or roughly $33K per year for a library of just 20 packages. That does not include the initial 3-to-6-week build for the scanner and the first-pass profiles, which is another $30K to $60K of engineer time.

Nark, by contrast: 170+ packages, $24K per year at the design-partner tier. Even if your team already has a Semgrep rule library in place, extending it to Nark's coverage requires the same maintenance workflow. The scanner engine you already have does not shrink the ongoing cost.

When building makes sense

There are four cases where we would honestly recommend building. If you are in one of these, do not buy Nark.

You have more than 2,000 engineers. At that scale the FTE cost of maintaining a rule library disappears into overhead, and the flexibility of owning the pipeline is worth more than the price of a vendor.
You use packages that Nark's public corpus does not cover. Specialized industry SDKs, in-house forks of open source, or vertical-specific tooling that Nark has no reason to prioritize.
You have compliance requirements Nark's SaaS pipeline does not yet meet. FedRAMP High, air-gapped environments, specific data-residency constraints.
You want to open-source the rule set as part of your engineering brand. If your team's public identity includes shipping developer tools, this is a reasonable flag-planting exercise.

In all four cases, the honest recommendation is: hire a static-analysis specialist and start from the public Nark corpus at github.com/nark-sh/nark-corpus (CC-BY-4.0) as your seed. There is no reason to redo the profile research we have already published.

When buying wins

The mirror of the above. Buy Nark if any of the following describe you:

Any team under 500 engineers where an extra FTE is a real hiring decision, not a rounding error.
You want deterministic scanning as a table-stakes CI feature, not as a research project your platform team owns.
You already run Semgrep or Socket, you have felt the "we need a package-behavior scanner" gap, and you would rather not staff a person to fill it.
Your core value proposition is not "we run the best internal tools." If you are not GitHub, Vercel, Stripe, or Datadog, the opportunity cost of the FTE is high.

The middle path: build on Nark

For most teams the right shape is neither pure build nor pure buy. Nark's public corpus is CC-BY-4.0 licensed. You can use it as the foundation, buy Nark for the maintained pipeline plus the pro corpus plus the SaaS dashboard, and extend with custom profiles for your internal packages.

You get the 170+ maintained profiles as leverage, the SaaS surface for reporting, and the freedom to encode company-specific patterns that no vendor could reasonably prioritize. This is the shape our design partners have converged on.