
If you've ever managed a CMS for a client, you know the dreaded request: "Can we get a custom block that looks exactly like this?" Usually, this means opening up your codebase, defining a new schema, mapping it to your frontend components, and waiting for the Vercel pipeline to redeploy. It's a massive friction point.
For the NextBlock Beta, we wanted to give users total control to build, duplicate, and edit their own blocks directly from the dashboard.
To do this, we had to rethink how blocks are stored. We built a Dynamic Schema Engine where custom blocks aren't hardcoded files; they are strict PostgreSQL JSONB data definitions. They inject at runtime directly into our Tiptap editor and Next.js 16 pipelines. No redeploys. No HTML sanitization tax. Just instant UI generation.
But here is where it gets really fun.
Because the entire block architecture is now just pure data (JSONB) instead of hardcoded React/TypeScript, you don't even have to build the widgets yourself. We fully integrated this with our Cortex AI. You can simply describe the layout you need—for example, "Build a Testimonial block with an R2 image avatar, a rich-text quote, and a 5-star rating toggle"—and Cortex AI will autonomously generate the schema, build the custom widget, and make it instantly available in your slash-command menu.
Zero code. Zero redeploys. Instant custom blocks.
Jump into our ephemeral sandbox and let me know what you think of the DevX (try getting the AI to build something crazy): https://nextblock.dev
This is technically strong, but I’d be careful that the positioning does not stay too deep in the implementation layer.
JSONB schemas, runtime injection, Tiptap, and Next.js pipelines prove the system is flexible, but the buyer probably feels the pain in a simpler way:
“Every client wants a custom CMS block, and every custom block turns into developer work.”
That is the sharper wedge.
The strongest promise might be closer to:
“Let clients and teams create custom CMS blocks without opening the codebase or waiting for a redeploy.”
That makes NextBlock feel less like another headless CMS feature and more like a workflow unlock for agencies, dev teams, and client-heavy websites.
I’d probably test this first with web agencies or dev shops that manage multiple client sites. They already understand the pain of one-off content blocks, client requests, and CMS customization work.
Happy to put a tighter version in writing if useful. I’d map the agency positioning, first buyer segment, landing page angle, and a simple beta-user plan.
This is absolute gold. You are completely right—the technical stack is interesting to other devs hacking on forks, but the sharper commercial wedge is the massive reduction in support debt.
In traditional headless environments, when a client wants a one-off custom block layout for a landing page, an agency has to open the code repository, define the schema, map it to frontend assets, and push it through a build pipeline. Doing that on the fly safely inside the panel completely changes the agency/client margin profile.
I'd be incredibly grateful if you put that tighter version together! Mapping out that first buyer segment and landing page angle would help us align our messaging immensely. Let's hear what you've got!
Really appreciate that.
I started mapping it out, but I realized it isn't just a tighter landing page. It changes who NextBlock is really selling to, what proof matters, and what the first commercial wedge should be.
That's difficult to do properly in a thread without oversimplifying it.
Happy to put it together and send it over. What's the best email to reach you?
info@nextblock.dev
We are also starting an open beta, if you are willing to try out Nextblock and report feedback on any bugs or other ideas you would have, I can give you a free lifetime license for my 2 initial premium packages: ecommerce and Cortex AI.
Thanks again!
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.