From "We Need a Website" to a Stack You Actually Understand
Most of our client engagements start the same way. Someone calls and says, "We need a website." Then comes the harder admission: "We have no idea where to begin."
That moment is more common than vendors will admit. And the answer is rarely "buy this platform." The answer is a conversation.
What Clients Actually Mean When They Say "Website"
When a CMO, founder, or operations lead says they need a website, they almost never mean what an engineer hears. They mean they need a place to send customers. They need credibility. They need a way to publish updates without filing a ticket every time. They need leads to come in, content to go out, and someone to call when things break.
The word "website" is shorthand for an entire operation. Our job is to unpack it.
In my experience leading platform engagements, the first thirty minutes of any new client conversation has nothing to do with technology. We ask who is going to update content, how often, and what happens today when they try. We ask what tools the marketing team already lives in. We ask what the sales pipeline looks like and where the website fits inside it. We ask what scares them about the last website they had.
By the time we finish that conversation, we usually know more about what they need than they do. That is not because we are clever. It is because we have done this several hundred times, and patterns repeat.
Why "You Need a CMS" Is the Wrong First Sentence
A lot of agencies open with the acronym. CMS. DXP. Headless. Composable. The client nods politely and pretends to follow along.
I think that approach fails the client. Telling someone they need a content management system before they understand the problem is like telling them they need a hydraulic press before you know what they are building. The acronym is not the answer. The acronym is a category of tool that solves a specific problem, and we have to make sure the problem is real before we reach for it.
So we explain it plainly. A content management system is the layer that lets non-technical people put words and pictures on a website without breaking it. That is the entire job. Everything else, the workflows, the personalization, the integrations, the AI features, is an extension of that core idea. Once a client understands that, the conversation gets honest.
Some clients hear that and realize they do not actually need much of a CMS at all. A small services business with five pages and quarterly updates does not need an enterprise platform. Others hear it and realize they have been underestimating their needs for years. A regional healthcare network with twelve service lines and compliance reviews on every page absolutely needs a real platform.
The clarity comes from the conversation, not the pitch.
The Stack, Translated
Once we know what a client actually needs, we walk them through what a modern website is really made of. Most clients have never been shown this. They think a website is one thing. It is not. It is a small system, and understanding the parts makes the whole thing far less intimidating.
We usually describe four layers.
The content layer is where words, images, and structured data live. This is the CMS. Today that might be Sanity, Sitecore, Optimizely, Contentful, or something lighter depending on scale. It is the source of truth.
The presentation layer is what the visitor actually sees. It is the frontend code that pulls content from the CMS and renders it as pages. This is usually built with a modern framework like Next.js or Astro, deployed to a fast hosting platform.
The infrastructure layer is where everything runs. Hosting, content delivery, certificates, DNS, caching, security. Clients almost never see this layer when it is healthy, which is the point.
The operations layer is the part nobody markets to clients but everyone needs. Monitoring, backups, updates, incident response, performance tuning, and the human on the other end of the phone when something goes wrong at 2 AM.
When we draw that picture on a whiteboard, something shifts. Clients stop feeling lost. They can see the system. They can ask better questions. They can tell us which parts they want to own and which parts they want us to handle.
Choosing the Platform Without the Sales Pitch
Most clients assume the platform choice is the hard part. It usually is not. The hard part is being honest about constraints.
We look at four things before recommending anything. How much content the client manages and how often. What their team can realistically maintain. What budget exists not just for build but for the years after. And what integrations the business actually depends on, such as CRM, marketing automation, commerce, identity, and analytics.
From there, the recommendation tends to write itself. A team of two marketers updating a few pages a month does not need a six-figure DXP. A global organization running multiple brands across regions cannot get by with a starter plan and good intentions. We have built on every major platform, and the goal is not to sell a preference. The goal is to match the platform to the work.
When we evaluate platforms for clients we use the same rigor we would use for our own systems. We reference independent sources like DXP Scorecard, which evaluates platforms across architecture, build simplicity, hosting cost, vendor lock-in, and dozens of other dimensions. We bring that data to the conversation so the client can see the tradeoffs themselves. Vendor marketing material is not a substitute for an honest evaluation.
What "Managed" Actually Means
Here is where most agency conversations stop and ours begins. A platform is not a service. A built website is not a finished website. The thing clients really need, and rarely get a clear explanation of, is what happens after launch.
We bundle the technology stack with a managed service so the client does not have to learn the operations layer to keep it running. That means we handle hosting, monitoring, security patches, performance tuning, integration upkeep, and the platform upgrades that arrive whether anyone is ready for them or not. It means the client has one phone number to call instead of seven vendors to coordinate.
For most of our clients this is the difference between a website that thrives and a website that quietly decays. Platforms evolve. SitecoreAI shipped major changes at Symposium 2025. Sanity ships changes monthly. Hosting providers deprecate features. Integrations change their APIs. Without an operations practice around the stack, the website starts to drift the moment the project closes.
A managed stack also means the editor experience stays good. When a client's marketing team logs in, they should not see a half-broken interface or an out-of-date plugin warning. The system should feel cared for, because it is.
How We Hand It Off Without Handing It Over
Clients sometimes worry that a managed stack means losing control. The opposite is true when it is done right. We design the handoff so the client owns everything that matters: the content, the domain, the accounts, the data, the design system. We manage the parts that take engineering attention to keep healthy.
The editor experience is built around what the client's team actually does. If marketing publishes weekly campaigns, the CMS is configured for that workflow with previews, scheduling, and approval steps that match how they already work. If editors are non-technical, we hide every field they do not need and document the ones they do. The system gets shaped to the team, not the other way around.
Training is part of every engagement. We do not consider a project done when the site launches. We consider it done when the client's team can confidently run it without us standing over them. We stay involved because they want us to, not because they have to.
What the Journey Actually Looks Like
For a typical mid-market client, the path from "we need a website" to a running managed stack runs roughly like this.
We spend the first few weeks on discovery, content modeling, and platform selection. We do not write a line of code until we know what we are building and why. Once the architecture is approved, we move into design and build, which usually takes between two and four months depending on scope. Launch is not a celebration; it is a milestone. The real work of editorial training, performance tuning, and operational handoff happens in the weeks after.
Then the managed phase begins. Quarterly platform reviews. Monthly performance and security reports. A roadmap for what comes next, because the website is not finished, it is just running. Clients tell us this is the part they wish they had known to ask for from the beginning.
Practical Takeaways for Anyone Starting This Conversation
If you are at the front of this process, asking yourself how to even start, a few things help.
Start with the work, not the tools. Describe what your team does today and what you wish it could do tomorrow. The platform conversation gets much easier once that picture is clear.
Ask any agency or vendor to explain the stack in plain language. If they cannot draw it on a whiteboard in five minutes, they probably cannot run it for you either.
Budget for after launch, not just before. The website is a living system, not a one-time purchase. Plan for the operations layer or accept that the site will degrade.
Insist on owning what should be yours. Content, domain, accounts, data, and design should belong to you. Engineering operations can be managed for you without being taken from you.
The clients who come to us not knowing where to start often turn out to be our best partners. They are honest about what they do not know, which makes it possible to build something they actually understand. That is the whole point of the work.
