Web design · Next.js
Next.js when the siteis an application.
A component system, a content source with preview, and a deploy path someone can explain. Not the default for a brochure.
The short answer
When Next.js earns its place.
Next.js is the right build when the site behaves like an application: shared components with a product, authenticated areas, or a content model a theme cannot express. It is a weak fit for a ten-page brochure or a standard catalog a store theme would merchandise. Marketers need a preview before a page is merged. A repository nobody on the marketing side can preview is a design file that happens to deploy.
Application sites
Use it when a theme would become a second product.
Next.js fits a product company whose marketing pages and app should share layout, type, and UI components. It also fits a front end in front of a catalog when the platform theme cannot do the merchandising you actually need. That bar is higher than 'we want it to feel custom.' Custom is not a requirement. A missing capability is.
Skip it when editors need a visual CMS and there is no engineering time to keep the deploy healthy. Webflow or WordPress will be faster to live with. Skip it for a small Shopify catalog that needs a cleaner product template. A new theme is the smaller project, and we will say that.
- Marketing and product need one component system, or the theme cannot express the catalog.
- Someone technical will own merges after we leave, or a retainer covers it.
- Editors get a preview URL. They do not edit production code.
Preview and components
Content source, routes, and who is allowed to merge.
We separate marketing routes from product routes so a campaign page does not inherit app logic it does not need. Content lives in a source that supports draft and preview. The page a marketer reviews is a deployment, not a screenshot of a design tool. Forms post somewhere a person reads. Redirects are in the project, reviewed like code, because they are code.
Components are the design system: a small set, documented with the props they accept. Pages assemble those components. We do not clone a one-off layout for every campaign. Caching and revalidation get a written rule so a published article appears, and a product price does not stay stale. That rule is part of the handoff, not a trick we keep to ourselves.
- Draft preview on a deployment URL before merge.
- A short component list with the content each one accepts.
- Redirects stored with the project and checked against the old site.
How this goes wrong
Rebuilding a CMS badly, or skipping preview.
Teams ask for Next.js and then want marketers to edit JSON in a repository. That lasts until the first launch week. If the content model is ordinary pages, use a CMS with preview, or do not use this stack. We will not invent a fragile admin panel as a side project.
The other failure is one repository where marketing pages, experiments, and the product release share a single unreviewed path. A headline change waits on an app deploy, or an app change ships a broken landing page. Routes, environments, and permissions exist so those are not the same event.
- No content editing by pull request unless the team already works that way.
- No marketing release that requires a product deploy by accident.
- No one-off page components that ignore the design system.
Deploy path
Preview works, and the owner is a person.
We judge the build on the path a page takes: draft, preview, review, merge, production. If any step is 'ask the freelancer who has the password,' it is not done. The marketer should open a preview without help. The engineer should know which environment a change is on.
We also check that the primary templates meet a basic speed bar on a phone, that forms arrive, and that old URLs redirect. Analytics events for the conversions you care about are part of the same launch. A site that deploys and does not record a demo request or a purchase is not ready to judge.
- A marketer opens a preview deployment without a walkthrough.
- Production deploys have a named owner and a rollback.
- Forms and primary conversions record on production.
Example engagement
A B2B software company with a split front end.
B2B software company. The product was a Next.js app. The marketing site was a separate tool the engineering team would not touch, so campaign pages drifted from the product UI and took weeks to request. The brief was to put marketing on the same front end without making marketers wait on the app release train.
We added marketing routes, a content source with draft preview, and a component set shared with the product where it actually matched. Marketing content did not wait on a product migration. The marketer reviewed a preview URL before merge. The billing app stayed in its own project.
Preview
Marketers reviewed a deployment before merge
Split
Marketing routes stayed off the product release train
The example uses anonymized results from a Quorum engagement. It is one account, not a benchmark you should budget against.
Questions
Next.js questions.
Is Next.js faster than a normal site by default?
No. It can be fast when templates, images, and scripts are disciplined. It can also be slower than a simple hosted site if every page is a custom client application. We treat speed as a template requirement, not a property of the framework name.
Which CMS sits behind it?
Whichever one your editors will use and your engineers will keep connected. The requirement is draft, preview, and structured fields. We do not pick a CMS to decorate the proposal. If you already have one that meets the bar, we use it.
Can a marketer publish without engineering?
They can publish content through the CMS and preview it. A change to layout components, routing, or integrations still needs a review. If you need every visual change to be free of engineering, this is probably the wrong platform.
Should our Shopify or BigCommerce store be headless?
Only when the platform theme cannot do the job. Headless adds a deploy, a preview problem, and a checkout handoff you must not break. Many catalogs need a better theme, not a second application. The proposal has to say what the theme cannot do.
Who owns the repository?
You do. We work in it, and the handoff names who can merge to production. A repo that lives only in an agency account is a lock-in. Access is part of launch, not a favor after the invoice.
More in this lane
Other Web Design platforms.
Talk through next.js.
One conversation. A diagnostic. A plan you can kill if it is not the work.