Design
Content architecture, templates and administration paths defined with the teams who will work in them every day.
Technology · Sanity
Sanity, content separated from its display.
We design, develop, integrate and evolve Sanity content platforms for organizations that publish the same information across several channels and want to keep one source of truth.
What we do
Design, develop, integrate, evolve.
We work across the full life of the platform, from initial framing to the changes that follow the launch.
Development
Custom theme, modules and extensions, versioned code, separate environments and review before every release.
Integration
Connection to the systems already in place: data, accounts, marketing tools and business applications.
Evolution
Adjustments, new sections and technical upgrades planned with you, without rebuilding the platform.
Your concerns
The questions an organization asks before choosing.
- What do we gain by separating content from display?
- The same information can feed a website, an application and a screen without being re-entered. In exchange, no site comes with the CMS: the display layer is a project in its own right.
- Will editorial teams find their way around it?
- The editing interface is itself code, so it adapts to your objects and your ways of working. Preview must be built deliberately: without it, publishing blind quickly becomes painful.
- Does the data stay with us?
- Sanity is a hosted service: content lives with the vendor and is exported through an API. This has to be settled early if there are sovereignty or archiving requirements.
In practice
One content base, several destinations.
The work is first about the schema and how each channel consumes the content. That is what prevents duplication and drift between channels.
Typed schemas
Content objects are declared in code, versioned and reviewed like the rest of the project.
Tailored editing
The interface is composed for your use, with the validations that help at entry time.
Preview
Every channel gets a real preview before publication, not an assumption.
Delivery
Content queries are defined per channel, with caching suited to each one.
The structuring decisions
- Source of truth
- What lives in Sanity and what stays in another system.
- Channels
- The surfaces served now and those to anticipate.
- Preview
- What teams need to see before publishing.
- Exit
- How content is exported if the platform ever changes.
Integrations
A platform connected to what you already use.
We start from your existing systems and the interfaces they expose. The exact scope is defined during framing: it depends on each system, not on the technology alone.
Data and accounts
- Directory and authentication
- User accounts
- Internal databases
- Internal APIs
Marketing and content
- Email tools
- Campaign management
- Translation and multilingual
- Media library
Business applications
- CRM
- ERP
- Forms and requests
- Customer service tools
Measurement and compliance
- Analytics
- Consent management
- Logging
- Accessibility
The right fit?
What tips the decision towards Sanity.
Sanity is justified when content serves several channels. For a single site, the separation adds work without an obvious gain.
Decision criteria
- Several channelsWebsite, application, screens or partners fed by the same information.
- Highly structured contentConnected objects, reused in different contexts.
- Technical teamA team able to keep the display layer alive over time.
- Publishing paceFrequent updates that must propagate everywhere without delay.
Counterparts to accept
- Front end to buildNo site is provided: the display layer is a full project.
- PreviewIt is developed; it does not exist out of the box for every channel.
- Hosted serviceContent resides with the vendor, with a subscription model to anticipate.
- Front-end dependencyAn outage in the display layer makes content unreachable for the public.
If the analysis shows another foundation serves your need better, we say so and point you to the right option.
Operations
What keeps the platform steady after launch.
Operations are not a contract separate from the project: they are prepared during design and continue at the pace you choose.
Environments
Separate development, staging and production, with the same deployment path every time.
Updates
Dependencies and versions tracked and tested before they are applied.
Security
Access management, logging and fixes applied according to their severity.
Backups and recovery
Verified backups and a documented restore procedure.
Monitoring
Availability, errors and response times watched, with a regular review.
Handover
Documentation and code handed to your organization, with no imposed dependency.
Use cases
What it actually looks like.
Three contexts where this approach changes daily life for teams. The interfaces shown are mockups made by our team to illustrate the point, not client projects.
MarketsSynchronised
One information base, several markets
Shared content adapted per market without manual copying.
Content
- Website
- Application
- API
The same content in site and app
Records served through an API to both surfaces at once.
Content model
- Titledefined
- Summarydefined
- Categorydefined
- Attachmentdefined
- Publication datedefined
Editorial data kept current
A single source of truth queried by the channels that need it.
Your project
Let’s talk about your next platform.
Share your objectives, technology environment, and constraints, and we will explore how to integrate the platform into your organization.
- A precise need or one still to define
- Architecture discussed before technology
- Collaboration with internal teams