Payload Components comes out of years of freelance Payload work — and the tax every one of those projects paid: rebuilding the same blocks, rewiring them by hand, and re-proving they worked.
Freelancing on Payload sites means a new repo every few weeks, and every one of them needs roughly the same surfaces — a hero, a feature grid, post cards, an archive. None of that is the work a client actually hires you for. It is the work that stands between you and that work.
shadcn changed the expectation for plain UI: run one command and a real component lands in your repo, in your style, yours to edit. Payload had no shelf like that. And Payload blocks are harder than UI components, because copying the files is the easy part. A pasted block is not live until your collection schema knows it, your renderer maps it, your types include it, and the admin import map sees it.
After every paste, on every project
register the block in src/collections/Pages/index.ts
map it in src/blocks/RenderBlocks.tsx
run payload generate:types
run payload generate:importmap
prove it still works — integration tests, e2e, click through the admin
The paste was never the problem. The edits after it were — and proving them, every single time, was worse.
That last checkbox is where freelance weeks actually went. Wiring a block by hand means verifying it by hand: integration tests, e2e runs, clicking through the admin to make sure nothing half-works in a way the client finds first. Multiply that by every block, every repo, every project, and the job stops being the content model, the design, the launch — the things that really matter — and becomes grunt work.
Payload Components is the registry I kept wishing existed. Blocks that install like shadcn components but finish the job: npx payload-components add hero-basic copies the source and does the four edits itself, landing as one reviewable git diff. And the proving moved into the registry: installer tests and a nightly fresh-repo smoke run gate every component centrally, once — instead of being redone by every freelancer on every install.
It is MIT-licensed end to end because an installer that edits your repo has to earn trust the only honest way: by letting you read it. The catalog grows from real installs, not roadmap theater — if you ship client sites on Payload, tell me which blocks you rebuild every time.
Where this came from
The freelance work that paid the tax
Real Payload sites I shipped for clients — before payload-components existed. Each one launched well. Each one also paid the same manual setup tax by hand: bespoke blocks rebuilt from scratch, types regenerated by hand, every surface re-proven before launch. These are not payload-components installs — they predate it. They are the reason it exists.
A Singapore leadership-development consultancy — marketing site spanning services, ROI proof, a five-step process, programmes, team, and a consultation flow.
~9bespoke blocksevery changetypes regen
Setup tax paid by hand
A dozen marketing surfaces — services, ROI, process, programmes, team — hand-built as blocks
Collection schema and RenderBlocks.tsx edited for every new block
Types and admin import map regenerated by hand on every change
Re-proved each surface in the admin before launch
From here
Spend your week on the work that matters.
Forty-four page blocks install today, eight post components are in development, and every component ships with its contract: source, manifest, docs, and installer coverage.
I built payload-components because installing a Payload block was never the copy-paste — it was the four edits after. The CLI exists so the second project, and the tenth, get that wiring for free. Read the installer source before you trust it; shipping it MIT is the point.
Live site