OurNext.js+Sanitystarter

In our Journal, we’ve already explained what a headless CMS is and why we chose Sanity as our platform of choice. In this article, however, we explain what happens when you build on that choice over the course of years, project after project.

When building digital products, the way you start says a lot about how you’ll finish. Setting up the same environment from scratch every time, reconfiguring the same integrations, reorganising the same folders… all of this takes time away from what really matters: building something of value for those who choose us as their partner.

That is why we have created (and maintain) a proprietary template repository based on Next.js and Sanity. This is not a generic starter kit, but the culmination of dozens of real-world projects, field-tested choices, problems already solved, and workflows refined over time.

Every new project we build builds on all of this.

Why the official template wasn’t enough

Sanity and Next.js offer excellent starter templates for anyone looking to explore the stack. But when working in production on real projects with real requirements, those same starters soon reveal their limitations.

The first key issue is language management. Standard plugins work well in simple scenarios, but when a project requires separate markets – different content for each language, different editors for each market – things quickly become complicated.

What we’ve done is develop a customised view of Sanity Studio where each editor sees only content in their own language. No risk of accidentally editing something intended for another market, no visual clutter, and no additional training required. The interface is designed around the actual workflow of those who use it every day.

All editable via the CMS

One of the core principles of our starter is that no text, links or settings visible to the end user are hard-coded. Any element you might want to change – from the text on the main button to social media links, from SEO metadata to analytics scripts – can be edited via the CMS without involving a developer.

The mechanism that makes all this possible is called PageBuilder, a block-based system that allows you to build complex pages by rearranging sections within the editor, just as you would with a visual page builder, but with all the power and flexibility of a headless CMS.

Each block – a hero section, a text section, a gallery, a call to action – has its own template in the CMS and its own React component on the front end. The correspondence is direct and predictable: content managers work independently, and the developer only steps in when new blocks need to be added to the catalogue.

Native internationalisation, not added later

Multilingual support is one of those features that, if not planned from the outset, becomes a huge problem to integrate later on.

In our starter, this is a structural element. Each piece of content exists as a separate document for each language, with automatically generated international URLs. The default language has no prefix (/); additional languages are automatically assigned a prefix (/en, /es, and so on).

In practice, adding a new language to a project takes just a few minutes to set up. No days of refactoring, no changes to the architecture. You simply add the language to a configuration file and the rest adapts accordingly.

SEO managed by the CMS

One of the issues that most often causes friction between digital agencies and clients is SEO: who updates it? How often? Do we have to wait for the developer to change a meta title?

In our starter package, the answer is no. Each page displays its own metadata – title for search engines, description, social media image – as editable fields in the CMS. The marketing manager can update them independently, at any time, without the need for a deployment or going through the agency. Changes go live immediately.

The site also generates an automatic sitemap, which is always kept up to date with the published content. There is no risk of forgetting to update it manually after each new page, as the code itself ensures it remains up to date.

Real-time updates without a rebuild

Publishing a change and having to wait several minutes to see it go live online – or worse, having to wait for someone to trigger a deployment – is a frustrating experience for content managers.

With our starter, there’s no waiting around. When an editor publishes a change on Sanity, the site receives it and displays it in real time – no reloads, no webhooks to configure, no waiting.

The same technology enables a live preview during editing: content managers can see the page update as they write, even before publishing.

In terms of performance, the site behaves as if it were entirely static: fast, efficient and optimised for Core Web Vitals. Yet the content is always up to date.

Performance that also has an environmental impact

There is one aspect of headless architecture that is rarely discussed: its environmental impact.

Our website, built using the starter kit we’re telling you about, emits just 0.10 grams of CO2 per visit – ten times less than the global average. This isn’t just window dressing; it’s a direct result of how the site is built.

In the traditional model, the server builds each page the moment someone requests it, consuming energy with every visit. In a headless architecture, this work is done only once, at the time of publication; the pages are then distributed via a CDN ready for use.

On a small scale, it is negligible. On an enterprise website with thousands of pages and constant traffic, it becomes a significant item in the sustainability report.

Accessibility as a starting point

If accessibility is only addressed at the very end, it creates a technical debt that is difficult to repay – and in some contexts, it is also a regulatory requirement.

Our starter kit includes all the essential building blocks right from the start: a well-structured HTML layout, correctly managed heading levels, fully functional keyboard navigation, and screen reader attributes where required.

It is not a perfect or definitive system. Accessibility is a journey, not a destination. But starting from the right foundation means not having to rectify poor architectural choices once the project is well underway.

The benefits for the whole team

The less obvious benefit of having a proprietary starter is what happens within the team.

Every new contributor finds a familiar environment: the same folder structure, the same conventions, and the same way of adding blocks, queries and page types. The code is well-commented to guide the development of each extension; there is no need to explain where components go or how data fetching works.

This cuts down on onboarding time and reduces the margin for error in the early stages, which are historically the ones where the most difficult decisions to rectify later on are made.

A constantly evolving repository

The repository is not a snapshot of a single moment in time. It is a living project that is constantly being updated.

Whenever we solve a complex problem on a specific project – a particular approach to metadata management, a more efficient pattern, or a component that proves to be reusable – that solution is incorporated into the template and becomes the standard for all future projects.

This means that every new website we build benefits from months, and sometimes even years, of optimisations gained through practical experience.

Why this matters to those who choose us

The issues we have already resolved

• Settings that need to be reset to default for every new project.
• Standard plugins that cannot cope with complex multilingual scenarios.
• Rigid routing that requires the developer to intervene for each new section.
• SEO and accessibility treated as an afterthought.
• Long onboarding periods for new staff members.
• Integration bugs discovered too late, at a late stage.

The benefits we take home

• Every project benefits from months of optimisations gained through practical experience.
• The editors are self-contained: content, languages and pages can be managed without deployment.
• The site is updated in real time, without the need for a rebuild.
• SEO, accessibility and performance are standard features, not optional extras.
• Il team parla la stessa lingua tecnica, dal primo giorno.
• The customer’s budget goes towards the solution, not the assembly.

Conclusions

A proprietary starter kit is not a technical luxury: it is a commitment to quality that is reflected in every project that leaves our studio. Clients who entrust us with a website do not pay to solve problems that we have already resolved elsewhere. They start from a solid, tried-and-tested foundation that meets our standards for performance, security and accessibility.