Plain answers — for the engineer who reviews everything and the builder who reviews nothing.
No. A boilerplate you fork once and maintain forever — it drifts, and nothing re-verifies it. An npm package is a hidden dependency that changes under you. shadcn is the same vendoring idea for UI, with no verification. PartKit is vendored code you own plus a machine-readable contract, a conformance suite, an attestation that expires, and a lock that stops your agent drifting it.
Custom is exactly the problem for auth, billing, and webhooks: a stateless agent writes them a little differently every session, and the differences are where the bugs live. You want these boringly identical and tested — and your agent’s creativity spent on your product, not on re-deriving a session check for the hundredth time.
One command: npx create-partkit-app my-app. You get a running app on a verified, locked backend — auth, billing, email and more, wired and migrated against a zero-config local database (no Docker, no account, no signup). Open /panel to see it’s locked and built-to-spec, then have your agent build the product. When you’re ready, partkit provision db gives you a real Postgres on your Neon and partkit deploy a live URL on your Vercel.
partkit add records your intent (parts.spec.json); partkit conform checks the result against it — every capability installed from a verified part, on the vendor you chose, nothing hand-rolled. Your /panel panel shows the verdict next to what’s actually deployed. The lock stops your agent editing infrastructure; conform stops it quietly skipping or reinventing it. AGENTS.md asks nicely; this fails the build.
It can write the file — but a pre-commit hook and CI reject the change, so it can’t land past your build, and an import-boundary scan blocks reaching into a part’s internals. In practice the agent reads the rule in AGENTS.md, hits the wall once, and goes back to wiring the seams.
Two doors. Flip its vendor in one commit (partkit upgrade --adapter=), or partkit eject to take full ownership and hand-edit it. The lock is a default you can opt out of, not a prison.
The thin app-specific glue where a part meets your product — the only code your agent writes for that capability. The email part sends mail; your seam is your welcome-email template. The billing part talks to Stripe; your seam is your plan catalog. Every part ships a seams.md so your agent wires it without ever reading the interior.
It means the part’s conformance suite passed and the proof hasn’t expired — a 14-day window, re-run on a public schedule, so a part that breaks against a new dependency goes visibly stale instead of silently wrong. It is not cryptographically signed yet; attestations are dev-tier and real signing is on the roadmap. We’d rather say so than imply more.
Especially you. The parts most likely to bite you — auth, billing, webhooks, secrets — come in already tested and locked, so the code you can’t review is the code you didn’t have to. You still own and review the thin seams on top; everything below them is tested code.
Neither. partkit add copies the source into your repo (MIT) — no runtime, no server in your request path, no account. The registry is consulted only when you install or upgrade. partkit verify runs fully offline, and there’s no telemetry.
We tested it the hard way: dropped a small, cheap model into a fresh scaffold with nothing but a product brief — no mention of PartKit. It read AGENTS.md, found the locked backend, built the whole app on the parts’ seams, hand-rolled no auth or billing, and never touched a locked part — and partkit conform confirmed it. If the floor model stays inside the lines, yours will too.
Nowhere of ours. The parts are copied into your repo (MIT); the backend runs on your machine, your Neon, your Vercel. We’re never in your request path, no account is required to build, and there’s no telemetry. The moment we hosted your backend, “yours, no lock-in” would be a lie — so we don’t.
v0 is deliberately narrow: TypeScript, Node 22+, Next.js App Router, and Postgres — one reference stack many parts deep, rather than many stacks one part deep. The contract format is stack-agnostic by design; more stacks come after real projects ship on this one.
The verified parts add $0 — they’re code you own. You pay the metered vendors you pick (Stripe, a Postgres host, an email vendor), and the cost planner models that across your scale and shows the cheaper swap — Resend vs SES, Neon vs Supabase — which you take in one line, no code change. We’re vendor-neutral and sell none of them, so the comparison is honest.
Everything that lives in your repo is free forever, MIT — the CLI, every part, the lock, /panel, conformance. You’d only pay for the view above your repos: a shared dashboard of every backend across your team, a private registry of your company’s own approved parts, and org-wide governance. The public registry stays neutral — we certify vendors and sell none — which is the only way the free part stays trustworthy.
Ready? npx create-partkit-app my-app — or build your stack →