How Marketing Agencies Can Ship Client Websites Faster with a Visual Builder on Next.js?
Published on Jul 31, 2026
Published on Jul 31, 2026
The Visual Website Builder
You Actually Own. React + Next.js, low-code, self-hosted. Your data, your infrastructure, every feature included.
© ChaiBuilder. All rights reserved.
Every agency that builds websites has run the same experiment twice.
The first time, you build the client a custom Next.js site. It is fast, it scores well, it looks exactly like the design, and the client loves it for about three weeks. Then the marketing manager wants to swap a headline, add a testimonial, and put a new logo in the customer strip. None of that is work. All of it is a ticket. It goes into your sprint board, waits behind actual development, and someone on your team spends twenty minutes on a copy change that annoys everyone involved. Multiply that by fifteen live clients and you have a person whose full time job is other people's headlines.
So the second time, you build the client a site on a hosted website builder. The tickets stop. Then the client asks for a pricing calculator, a gated resource library, a webhook into their CRM, and a URL structure their SEO consultant insists on. Now you are the one filing tickets, except you are filing them against a platform that will not read them.
Neither experiment failed because you picked wrong. They failed because both tools force one team to work inside the other team's constraints. The way out is not a better builder. It is a split: developers own the setup, marketers own the ongoing changes, and the tool has to be built so that neither one blocks the other.
That split is the workflow this post describes, and it is the reason ChaiBuilder is a low-code builder that runs inside your own Next.js app rather than a platform your site lives on.
There are two phases and one handover.
Setup happens once per project and belongs to developers. Deploy the app, set the design tokens, build whatever custom blocks the design needs, wire up structured content, configure roles. It is real development work, billed as such, and it produces something the client's marketing team can operate.
Ongoing changes belong to the client. New landing page, seasonal campaign, updated copy, a new case study, a translated variant. They do all of it in the visual builder, preview it, publish it, and roll it back themselves if they get it wrong.
The retainer that follows is for development, not for headlines. That is the whole commercial point.
The fastest way onto a project is the one-click deploy from /start: pick the SQLite or Postgres variant of the public starter, deploy it to the client's Vercel account, and finish setup in the browser through the starter's /setup wizard. Name the site, connect the database, create the admin login, paste the generated environment variables back into the host, redeploy once. You have a live Next.js and Payload CMS site on the client's own infrastructure before the kickoff call is over.
When you want the project on your machine from the start, which is normal for anything with custom blocks, scaffold it locally instead:
npx chaibuilder-app create
The scaffolder asks for a project name and a database, creates the admin user, installs dependencies, runs migrations, and seeds the database. Then:
cd my-client-sitepnpm dev
Either way the result is the same project, and it deploys anywhere Next.js runs. The database is SQLite (a local file or hosted libSQL/Turso) or Postgres. Auth is yours to choose. Media goes to S3, R2, or whatever storage the client already pays for.
This matters more for agencies than for anyone else, because the end of a client relationship is a normal event in your business. When the site is a standard Next.js app on the client's hosting and the client's database, offboarding is a repository transfer and an invoice. There is no export process, no data extraction, no awkward conversation about who owns the pages.
The single highest leverage hour in the setup phase is the one spent on design tokens: background colors, text colors, fonts, border radii, spacing conventions. ChaiBuilder is built on pure Tailwind CSS, and tokens are reusable bundles of those utilities rather than one-off styles applied per element.
Doing this first is what keeps the client's site on brand six months after handover. When an editor drops a new section onto a page, it inherits the tokens, so it looks like the rest of the site by default rather than by discipline. When the client rebrands, you change the tokens once and the whole site follows. If you skip this step and let editors style elements individually, you have built a site that decays into fourteen shades of the brand blue, and you will be the one fixing it.
Themes are CSS, so a token set built for one client can be lifted into the next project as a starting point. Agencies accumulate a house style this way without accumulating a house framework to maintain.
Every client project has a handful of components no generic builder ships: the pricing table with their plan logic, the store locator, the calculator, the integration with their booking system. These become custom blocks, written as React components and registered so they appear in the builder's block list like any built-in.
The important design decision is which props you expose. A custom block whose every text string, image, and style hook is an editable prop can be reused by the marketing team on pages you never imagined. A block that hardcodes its content comes back to you as a ticket the first time the copy changes. Spend the extra thirty minutes on props. It is the difference between shipping a component and shipping a capability.
The same extension model applies to the builder interface itself: custom panels let you add agency-specific or client-specific tooling inside the editing experience.
Not everything belongs in a visual page. Blog posts, case studies, team members, job listings, and events are records, not layouts. They live in Payload CMS, which the starter ships with, and Payload stays purely Payload: your own collections, your own hooks, your own access logic.
The two halves meet through data binding. A visually designed template pulls fields from a collection, so the client's editors write a case study as a normal CMS record and the presentation stays consistent across every one of them. Nobody is laying out a blog post by hand, and nobody is asking you to add a field.
If the client already runs an external CMS they are not leaving, the CMS is swappable. That conversation usually ends a lot faster than it does on a hosted platform.
This is the part that keeps the second experiment from repeating. ChaiBuilder controls the visual part of the app. Everything Next.js does is still available to you: your own routes, your own API handlers, your own middleware, your own server components, pages you override entirely. The client's checkout flow, gated portal, or CRM webhook does not need to be expressible in a builder, because it does not live in the builder.
The rule of thumb: if the visual builder cannot do it, a developer does it in the app. That is the design, not a workaround.
Handover fails when the client is technically able to edit the site but afraid to. The features below exist to remove the fear, which is what actually stops the tickets.
Roles and permissions. Give the client's team exactly the access they should have, and no more. The intern who updates the events page does not get the ability to change the header on every page.
Multi-user editing with page locking. Two people on the client's marketing team will eventually open the same page on the same afternoon. Page locking means the second one gets told, rather than the first one silently losing their work.
Preview, then publish. Preview mode is built on Next.js draft mode, so the client reviews the real page, rendered by the real app, on the real URL structure, before anything goes live. Publishing is one click.
Revisions and restore. This is the feature that changes client behavior more than any other. When an editor knows a bad change is one restore away, they stop routing every edit through you "just to be safe." Version history is the permission slip that makes the rest of the workflow real.
Multilingual content. Clients operating in more than one market manage the language variants themselves rather than sending you a spreadsheet of translations.
Media manager and image editing. Uploading, organizing, cropping, and adjusting images happens in the builder. Nobody opens a design tool to resize a hero image, and nobody emails you a 4MB PNG.
AI assistance in the builder. A chat panel scoped to the current page handles copy edits, drafting and adjusting sections, SEO help, and theme changes, which means an editor with no CSS knowledge can express a layout intent in words. The AI provider is yours: Vercel AI Gateway and OpenRouter work out of the box, other providers are configurable, and the keys and usage stay on the client's own account. Same ownership principle as the database.
Budget a two hour training session at handover, recorded. In practice you will spend most of it on preview, publish, and restore, because once those three are understood the client's team stops asking permission to touch their own website.
Content tickets become capacity. An agency running fifteen client sites absorbs a steady drip of small content requests. They are unbillable in practice, they arrive with no notice, and they fragment developer attention. Removing them is not a rounding error; it is the difference between your team shipping projects and your team servicing them.
Pricing is simple to build into a proposal. Every ChaiBuilder license includes the entire feature set. There are no tiers and no per-feature gating, so you never have to explain to a client that revisions are an upgrade. Plans differ by domains, branding, and support:
| Plan | Price | Domains | Branding |
|---|---|---|---|
| Solo | $99 / year | 3 domains | ChaiBuilder branding shown |
| Studio | $399 / year | Unlimited domains | ChaiBuilder branding shown |
| Agency | $899 / year | Unlimited domains | Agency branding: your own logo and colors inside the builder |
Agency branding is included with the Agency license. The client's marketing team logs into a builder that carries your logo and your colors, which is a meaningful difference when the builder is the interface they touch every week.
There is also an operational detail worth knowing: a single database can host any number of sites, with all content scoped per site. Agencies that run many small client sites can consolidate infrastructure instead of provisioning a database per project.
Licensing is predictable. A license covers the versions released during your license period. If you stop renewing, the sites keep running on the last version you were eligible for. Nothing switches off, which is exactly the assurance a client asks for when you propose a tool they have not heard of.
Handover is clean. The site runs on the client's hosting, the client's database, and the client's AI provider. If they take the site in house in two years, they take a Next.js app. Agencies that have been through a platform migration know what that sentence is worth.
A realistic shape for a small marketing site, assuming design is already approved.
Monday. Deploy the starter to the client's account, connect their database, and get the admin login working. Translate the approved design into design tokens: colors, fonts, radii, spacing. Build the global header and footer.
Tuesday and Wednesday. Build the pages that are just composition, which is usually most of them: home, about, services, contact. Identify the three or four components that need to be custom blocks and build them with generous editable props. Set up the Payload collections for case studies and blog posts, and build the templates that render them.
Thursday. Configure roles for the client's team. Wire up forms, redirects from the old site, and metadata. Walk the site as an editor rather than a developer and fix everything that is technically editable but confusing to edit. This day is the one that decides how many tickets you get in month two.
Friday. Training session with the client's marketing team, recorded. Publish. Hand over the repository access.
The following Tuesday, the client publishes a new landing page for a campaign you never heard about. That is the outcome you were selling.
Being honest about this is what keeps the workflow credible with clients.
Anything structural is still development work: new page types, new custom blocks, new integrations, performance work, and the parts of the app that live outside the builder. Framework upgrades and dependency maintenance are yours if the client keeps you on retainer, or the client's if they do not. And the setup phase is real work that deserves real hours in the proposal, because the entire hands-off period afterwards is paid for by how carefully it is done.
The goal was never to remove developers from the client's website. It was to make sure the developer time goes into things a developer should be doing.
Pick the next small client site, the one where you already know the content will churn. Deploy the starter, spend a day on tokens and blocks, and hand it over. The trial runs 30 days from deploy, with no credit card and no email required, which is enough to get a real project through kickoff and handover before you decide anything.
Both setup paths, the one-click deploy and the CLI, start at /start. When you want the detail first, the quickstart covers both paths step by step, and design tokens covers the token work that makes the handover stick.
