Merlin is a small Amsterdam-based code boutique that ships high-end digital experiences. And when we say high end, we mean HIGH end.
Check out some of the work they've done with Dato for some context on why we were so obsessed with talking about their visual direction with them:
WØRKS – in collaboration with WØRKS,
Their own website on Merlin,
SKKY – in collaboration with WØRKS,
erthos® – in collaboration with WØRKS,
Mike Schwartz – in collaboration with WØRKS,
Summoner – in collaboration with Summoner,
Lessen voor het leven - in collaboration with N=5, and
Their work looks nothing like templates because the team starts by mapping the intended look and feel into a clean data model, then builds the UI to match. The result is visual freedom without chaos in the CMS.
They don't run discovery with a checklist. They sit with the client or the design partner and listen for signals.
Has the team shipped work like this before?
Is it one site or a multi-site?
Are 3D interactions on the table?
How much creative license exists?
Those answers shape both the front end and the content model from day one.
And when they have those answers - they tend to start thinking of how the schema needs to be shaped to match the story. In several cases, those thoughts have led to them kicking off a project with DatoCMS, because, in Mees' words 👇
"Bare bones, but structured"
Merlin’s modeling rule is simple. Mirror the design in data and stay modular wherever repetition appears. When a lot of pages share the same visual building blocks but in different orders, they model blocks that can be rearranged safely. That lets editors add content or swap sections without breaking layout logic, and it lets the devs stress-test variants by shuffling components before launch.
We try to mimic the design in data as well as in how it’s positioned
This is why they prefer working with Dato on these visual projects. His experience with multiple CMS has been that they tend to be restrictive by overwhelming you with dashboards, and cards, and clutter.
Dato, on the other hand, is "bare bones but structured", where you start off with a blank canvas and then build your content views based on your schema and added plugins.
Because Dato is so barebones, we’re able to match the mental model of the design to the layout in the CMS
Speaking of the schema, the simplicity of the implementation means it stays readable for both humans involved. Editors should not hunt through sidebars to change one string. Developers should not guess what a field does. If a page needs technical toggles, they label them clearly and fence them off. “Sometimes we have a page where we just have settings for a launch date or a button to remove the zero state. We mark it with please do not touch if you are the client,” he chuckles. The UX test however, is blunt. If the CMS feels intuitive, the design is right.
Handovers are hands-on. After build, they clean up labels and help text, then walk editors through the model in a live session and record it for later. They also reach for small plugins when they unlock a real task.
A good example is plugin they built which is an audiobook helper that inspects uploaded files, extracts chapter info, visualizes it for editors, and feeds that data back into the site.
Fragments, frameworks, and solid foundations
OK but with all this visual storytelling and animation-rich design, how are their projects not taking a million years to load on the client side?
On the stack side of things, Mees keeps things pragmatic. Many projects run on Next.js. The team keeps a small GraphQL workflow with reusable fragments, so media, SEO, and other common selections are consistent across screens. Defaults like site-wide SEO come from a central settings record. Svelte and SvelteKit are also in rotation when the work leans heavy on motion or 3D. The reason for this is control. Svelte lets them sit closer to raw HTML, CSS, and JavaScript which helps when performance and accessibility need a tighter grip.
They keep rich-text freedom in check as well to ensure performance is optimized. Editors can add links or bold (standard formatting options), but, for example, they avoid allowing full HTML that turns a field into a page inside a page. That discipline protects rendering performance and prevents design drift.
On the assets side of things they built a nifty video transformer that pulls media, re-encodes to modern codecs like H.265 and VP9, and ships smaller files for users without manual work per clip. DatoCMS slots in well here because it makes bulk processing and delivery straightforward.
A standout example of how they combine their pragmatism with aesthetics is a WebAR experience they did for Dior for the Garden of Dreams project. There was no page tree. The experience was a linear story composed of models, pop-ups for things like camera permission, and interstitials with text, images, or video.
Merlin solved it in data with clear naming and types for each state in the flow. That content model made the non-page world legible for editors and also scaled to 15 countries and 15 languages during rollout. “We figured out a way to name things really obviously. Promotional pop-up for this moment. Initial pop-up for the cookie banner. We were able to put all those things in data and it was very clear,” Mees says.
Why DatoCMS?
This is where the whole "bare bones" comment shines.
Noise is the enemy.
Mees wants one place to own content and a UI that does not encourage unhinged editing. “We really love that Dato allows us to create a space that has so little noise that you can almost not do the wrong thing,” Mees says. Text, media, SEO, and per-project toggles live in one model. Editors can update a staging domain, sanity-check changes, then promote to production without a dance through other tools. It is a simple loop that keeps the team focused on shipping rather than shepherding.
The approach scales down to small sites and up to complex interactive work because the contracts are stable. Model the design in data. Keep the blocks safe to rearrange. Use fragments to keep queries dry. Keep rich text constrained. Encode assets lean. Choose the framework that gives you the control the visuals need. And always make the editor view reflect the mental model of the final experience.
That last part is why the team records handover sessions and why they invest in little helpers like the audiobook plugin or the video transformer. The fastest support ticket is the one that never gets created because the model was obvious and the media just worked.
Mees' take is not theoretical. It comes from keeping performance budgets while pushing motion and 3D, and from avoiding the slow drift that happens when editors get a canvas they can paint into anything. Give them the right blocks. Keep the schema honest to the design. Keep the site fast. The rest is taste. And pretty damn good taste, too.
