Published
Next.js or a simpler CMS for your next client website?
Compare a custom Next.js setup with a packaged CMS using your client’s editing tasks, approval process and maintenance needs.
Before choosing the technology for a client website, ask the person who will maintain its content to show you a normal week’s work.
They may need to change service details and publish a case study. They may also need to build campaign pages without waiting for a developer. Those are different editing requirements, and they should shape your agency’s proposal.
Next.js is an application framework. A CMS manages content, and a Next.js site can use one. The useful comparison is between a custom frontend with an editing system and a more packaged website solution. Compare what the client will receive in each proposal.
Start with the editor’s work
Write down specific tasks using the client’s own content where it is available. Ask the supplier to demonstrate those tasks in the proposed setup.
For a hypothetical consultancy website, that might mean:
Update a service description without changing its layout.
Add a case study and connect it to the relevant service.
Create a campaign page using a choice of approved sections.
Preview a draft and obtain approval before it appears publicly.
Keep the distinction between changing content and creating layouts clear. An editor who can update a service description may still need a developer to add a new type of section. If the client expects to build campaign pages themselves, check which sections they can use and how new ones are added.
A list of CMS features will not show whether the client can do these jobs comfortably. Use the demonstration to check the actual editing process, including the parts that need someone else’s help.
A packaged system can provide substantial editing capability. For example, WordPress’s Site Editor supports editing site templates and styles with block themes. The supplied theme and configuration still affect what the client can do.
Compare the complete setup
The Next.js documentation covers website and application features such as routing, rendering and data handling. A supplier using it must still decide how content is stored, previewed and published.
Ask for those decisions in the proposal, then compare the full setup with the packaged option.
| Requirement | What to check in a packaged solution | What to check in a custom Next.js setup |
|---|---|---|
| Editorial freedom | Whether the supplied theme and editor support the required layouts | Which layouts and components are editable, and how new ones are added |
| Approvals and previews | Whether the chosen configuration supports the client’s approval process | How the CMS and frontend work together for drafts and previews |
| Connected services | What the available integration supports and what remains custom work | The scope of the connection, failure handling and ongoing ownership |
| Design requirements | Whether the design fits the available components or needs customisation | What is being built specifically, and which reusable components are used |
| Future changes | Who maintains themes, extensions and custom code | Who maintains the application, CMS integration and other dependencies |
| Handover | What the client receives and how another supplier can work on it | The same ownership question, including documentation of connected services |
These are checks for the proposed configuration. Neither column describes what every product or implementation will provide.
Choose the simplest option that meets the brief
For a small site with familiar layouts and straightforward editing, assess a packaged solution first. If it handles the design and content tasks, custom development needs a clear reason.
A custom frontend may make sense when the website is part of a larger application, the interaction is specific to the business, or content needs to support several channels. Other technologies can also address those requirements. Ask the developer to explain the choice through the work the site needs to do.
A distinctive design alone does not settle the question. Find out which parts require custom behaviour and which are layout choices an existing system already supports.
For the hypothetical consultancy, the decision should come back to the editing tasks. If a packaged setup supports the required service pages, linked case studies and campaign layouts, include it as a credible option. If something needs custom development, name that requirement and explain why.
Test the awkward parts before committing
A polished homepage demonstration tells you little about an editor publishing a late change.
For the consultancy example, ask for a draft case study to be previewed, corrected and published. Check who can approve it and what happens if it is unpublished. Confirm how the relevant service page displays the change.
Also ask the supplier to demonstrate creating a campaign page from the approved sections. Check whether the editor can produce the required layout within the proposed setup, and identify any step that needs a developer.
If the site connects to another system, test what the visitor sees when that service is unavailable. A working integration demonstration should include the agreed failure behaviour.
These are proposed checks to adapt to the project. Agree their scope before asking someone to build a trial.
Compare ongoing responsibility as well as build price
Ask for recurring service costs and the work needed to maintain each option. Include paid extensions or CMS plans, hosting and other connected services.
Identify who can make changes after launch and what another supplier would need to take over. A custom system can be documented and handed over. A packaged system can still accumulate custom behaviour that needs a developer.
For your agency, this belongs in the comparison before you make a promise to the client. Record who owns maintenance of each part, including any connection between the CMS and frontend.
Performance, security and search visibility also depend on implementation. A framework name does not establish that the finished site is fast, accessible or ready to index. The Next.js production checklist is one example of the checks a development team needs to work through.
Put the decision in the proposal
The recommendation should explain which editor and visitor tasks the system supports, where custom development is needed and who maintains it. Record the alternatives considered and why they were not selected.
Keep any limits on editing explicit. If the client can build pages only from approved sections, say so. If new layouts require development, include that boundary too.
If the client mainly needs to edit pages, keep that task central. If the website has become an application, scope the application explicitly before comparing prices.
I build in Next.js, and I can help assess whether it fits your client’s project. Talk through the brief with Kyln before committing to the technology.