The real deliverable of a paragraph-based build is not the paragraphs. It is the moment your client stops asking for "a new page" and starts asking for "a new component."
There is a quiet milestone in every successful content-management project that never shows up in a status report. It is the day a client request changes shape. Instead of "we need a landing page for the new gift card," the email reads "we need a paragraph type that shows features in two columns, and make sure we can reuse it elsewhere." That sentence is the win. It means the client has internalized a component mindset - the habit of thinking in reusable building blocks instead of one-off pages - and now thinks about their website the way you do.
This shift is worth far more than any single feature. A client who thinks in pages depends on you for every change. A client who thinks in components builds their own pages, asks better questions, and keeps coming back to expand the system rather than to fix it. For project managers and account managers, facilitating this shift is one of the highest-leverage things you can do for a long-term relationship.
This post is based on a real project for Edenred Polska, a multinational benefits company that moved from planning to abandon Drupal entirely to commissioning new components on a regular basis. We'll cover how the component mindset develops, why you can't force it, and what you can do to create the conditions for it.
In this article:
- Why does the "build me a page" model hold clients back?
- What changes when clients start asking for components?
- How does the component mindset shift actually happen?
- What does the shift mean for the agency relationship?
- How do you facilitate the component mindset shift?
Why does the "build me a page" model hold clients back?
In the traditional model, every content need arrives as a page request. "I need a landing page for product X." "Can you build a page for the spring campaign?" Each request kicks off the same cycle: a new design, a new development task, a new line item in the budget, and a wait of days or weeks before anything goes live.
This model has three structural problems, and none of them are the client's fault.
Total dependency. The client can't do anything without the agency. Updating a phone number, swapping a hero image, or reordering two sections all require a ticket. In the Edenred project, the marketing team had reached the point where they pasted finished graphics into the site instead of editing text, because filing a request and waiting was slower than opening a design tool. That is not a lazy team. That is a team boxed in by a page-based system - the same pattern we describe in our guide to Drupal Paragraphs implementations that editors actually use.
Slow iteration. When every page is a bespoke build, the gap between idea and live page is measured in weeks. Campaigns slip. Seasonal opportunities pass. The marketing calendar bends around the development queue instead of the market.
A frustration cycle that erodes trust. The client waits, the agency builds, the client wants changes, and the loop repeats. Each turn of the cycle costs time and goodwill. Pushed far enough, the client concludes the platform itself is the problem. Edenred reached exactly that conclusion: they planned a full rebuild on a different technology and did not even list Drupal as an option in their request for proposals. That is the moment CMS modernization vs rebuild becomes a boardroom decision.
The page-based model trains clients to see their website as a series of one-off deliverables they can't touch. As long as they think that way, the relationship stays transactional and fragile.
What changes when clients start asking for components?
In the component model, the unit of work is no longer a page. It is a reusable building block. The client's request changes from "build me this page" to "build me this capability," and once the capability exists, the client assembles pages from it on their own.
You can hear the component mindset in the questions the client starts asking. Instead of "what will this page look like," they ask "how universal is this component, and where else can we use it?" They evaluate every new Drupal Paragraph by its reuse potential. At Edenred, after the first set of components proved itself, the client ordered six to nine new paragraph types and judged each one by exactly this standard: how many contexts could it serve?
Three things become possible once a client thinks this way.
Self-service page building. The marketing team assembles entirely new pages from existing components without involving a developer. A campaign page that used to take weeks becomes an afternoon of selecting paragraphs, filling in content, and publishing.
Creative reuse you never planned for. This is the clearest signal the mindset has landed. At Edenred, the team took product-presentation paragraphs and repurposed them to promote webinars, mapping the subtitle field to the event date and the description field to event details. Nobody asked them to. The components were universal enough that creative reuse happened on its own.
Better briefs. A client who thinks in components writes requests you can actually act on, because they already understand the difference between a one-off block and a reusable type. The conversation moves from "make it pretty" to "make it versatile."
Read also: Drupal Paragraphs: from unusable to empowering content editors and a quick way for editing and customizing a Drupal paragraph.
How does the component mindset shift actually happen?
You cannot install the component mindset the way you install a module. It develops in stages, and your job is to create the conditions for each stage rather than to lecture the client through it. Across projects, the progression tends to follow four phases.
Phase 1: demonstration
You build the first set of components and show what's possible. This is where the client sees, often for the first time, that they can change real content themselves. The goal here is not to teach every feature. It is to produce a single "wow" moment where the client realizes the site is now theirs to edit. A modern admin experience helps enormously; swapping a dated admin theme for something current makes the same capabilities feel dramatically more approachable.
Phase 2: discovery
The client starts exploring and uses components in ways nobody planned. This is the most important phase and the one you can least control. Give the client a staging environment with a complete example page that uses every component and every variant, then step back. Edenred's content team received exactly this and started building real production content without any formal training - the same zero-training CMS outcome we aim for on every handover. The webinar reuse trick was born here, during unsupervised play.
Phase 3: internalization
The client begins requesting components instead of pages. The language of their requests changes. Instead of "build us a page for the new product," they ask for "a paragraph that does X, that we can reuse." This is the milestone from the top of this article. When you see it in writing, the component mindset shift has happened.
Phase 4: advocacy
The client now thinks about universality before you do. When briefing a new design, they ask how reusable it will be and where else it might apply. They start defending the approach internally and to peers. At this point the client is no longer a consumer of your work; they are a co-owner of the system.
The throughline across all four phases: you create the conditions and let the client discover the value. A staging environment to explore, components versatile enough to surprise their makers, and the patience to not over-explain. You can't force the shift, but you can make it almost inevitable.
Read also: how we avoided a costly Drupal rebuild and lifted conversion ~24% and the Geysir module for faster paragraph editing.
What does the shift mean for the agency relationship?
When a client crosses into the component mindset, your role changes, and it changes in your favor.
From vendor to toolmaker. You stop being the team that builds pages and become the team that builds the tools the client uses to build pages. That is a structurally better position. Toolmakers are harder to replace than page factories, because the value you deliver compounds across every page the client makes.
Higher-value work. Instead of a queue of repetitive "change this text" tickets, your team focuses on designing new component types, solving genuinely interesting problems, and extending the system. The work is more rewarding for developers and more valuable to the client.
Longer relationships. A client who understands the system keeps coming back as their needs evolve, not because something broke, but because they want to do more. Edenred went from a minimal nine-hour monthly support package to commissioning new components regularly and planning further phases of development.
Account growth and referrals. A client who has internalized the approach invests more in expanding it, and they talk about it. The Edenred success was repeated with another client who was also planning to abandon Drupal; this time we could point to a concrete case study to make the argument. An empowered client becomes a reference and a source of new business.
The deeper point: a working component system doesn't just improve the website. It changes the relationship between the client and the technology, and between the client and you.
How do you facilitate the component mindset shift?
The shift is something the client discovers, but everything you do shapes how likely that discovery is. Here is what consistently moves clients toward thinking in components.
Design for universality from day one. Build components that work across many page types, not blocks tailored to a single page. The test for every component: "how could this be used in a context we haven't thought of yet?" If the answer is "it couldn't," redesign it. A small library of versatile components beats a large catalogue of one-off blocks every time.
Name components by what they do, not where they live. Call it "feature grid" or "two-column highlight," not "homepage section 3." Names that describe location trap a component in one page in the client's mind. Names that describe function invite reuse.
Show, don't tell. During handover, demonstrate creative reuse instead of describing it. Show the team how a product paragraph can promote a webinar. Once they have seen one unexpected use, they start inventing their own.
Celebrate unexpected uses. When a client uses a component in a way you didn't plan, treat it as a success, not a deviation. That reaction reinforces the exact behavior you want and signals that the system is theirs to experiment with.
Resist over-specifying. Leave room for creative interpretation. A component that dictates exactly one correct usage teaches the client to wait for instructions. A component with sensible flexibility teaches them to explore. The same restraint applies to handover: a great example page on staging does more than a two-hour training session ever will.
Want to turn your clients into component thinkers?
This post is based on our real production work for Edenred Polska, where a properly implemented, paragraph-based Drupal system turned a client who was ready to abandon the platform into one who actively commissions new components and builds their own pages. The shift from page requests to component requests was the real measure of success, alongside an approximately 24% conversion lift on the first rebuilt page.
If your clients still depend on you for every page, the problem may be the model, not the relationship. Our team specializes in building universal, reusable Drupal components and the editor-friendly experience that lets clients run with them. Visit our Drupal development services to see how a component-based approach can change what your clients can do on their own.
