Website Rebuild Strategy: Fix Workflow, Not Just Design | Build with Matija
Website Rebuild Strategy: Fix Workflow, Not Just Design
Why most website rebuilds fail — prioritize publishing workflows, CMS operating model, translation and reduced…
·Updated on:··
Need Help Making the Switch?
Moving to Next.js and Payload CMS? I offer advisory support on an hourly basis.
Get Practical CMS Decision Briefs
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
Most website rebuilds start with something visible.
The homepage feels outdated. The CMS is painful to work with. Leadership looks at competitors and feels behind. Someone in marketing says "we need a new website," and that framing sticks.
Sometimes it is the right call.
But in a lot of B2B, ecommerce, multi-brand, or content-heavy companies, the website is only the first visible symptom. The actual problem is not the design system, the CMS choice, or the frontend stack. The actual problem is how the business operates around the website. And a rebuild will not fix that automatically. In fact, if you ignore it, the rebuild can make it more expensive.
The interface is not the bottleneck
I keep seeing the same pattern in larger projects. A company comes in convinced the problem is the website. When you look closer, the friction is sitting behind the interface.
Marketing wants to launch landing pages faster, but every page needs developer time. Product teams want content updated, but nobody is sure whether product information lives in the CMS, ERP, PIM, Shopify, a spreadsheet, or someone's inbox. Regional teams need translated pages, but there is no clear process for who translates, who reviews, and who publishes. Design wants consistency, but every campaign spawns a new one-off layout. Leadership wants reporting, but nobody owns tracking structure, conversion events, or post-launch analysis.
From the outside this looks like a design problem. From the inside it behaves like an operating model problem.
That distinction changes everything about how you approach the project.
A rebuild will not fix a broken publishing process
The most common hidden problem is publishing.
Publishing sounds simple until more than one team is involved. For a small company, one person edits a page and clicks publish. That works fine. For a larger company, a single page going live might involve copywriting, design, legal review, translation, SEO, product data, photography, campaign timing, stakeholder approval, analytics, and development.
At that point the CMS is not just a place to edit pages. It becomes the operating layer for how the company changes its public-facing information.
This is where a lot of rebuilds go wrong. Teams choose a CMS before defining the workflow. They ask "should we use WordPress, Payload, Sanity, Contentful, or something headless?" before they have answered "what actually needs to happen before a page goes live?"
That order matters.
If the business needs approvals, drafts, preview environments, translated versions, campaign releases, reusable content blocks, and different permissions for different teams, the architecture has to support that from the start. If not, the new website may look better but operate almost exactly like the old one.
The CMS choice is also an operating model choice
A CMS is not only a technical decision. It defines what the business can do easily, what requires a developer, and what becomes risky.
I wrote more about this in Payload CMS for Publishing Teams: Honest Review. The point I keep coming back to is that Payload gives you a flexible foundation, but it does not magically know how your marketing, legal, product, and translation teams should work together. Neither does WordPress, Contentful, Sanity, or Shopify. The workflow still has to be designed.
If the company needs a simple blog and a few static pages, a heavy custom architecture is overkill. But if the company has multiple brands, multiple markets, product launches, translated content, campaign pages, and internal teams that need different levels of access, the CMS decision becomes strategic. The question is not "can this CMS edit pages?" The question is "can this CMS support how the company actually needs to publish, approve, update, localize, and measure content?"
Developer bottlenecks are usually workflow bottlenecks
One of the clearest signs of an operating model problem is when every meaningful website update needs a developer.
Not because developers are doing anything wrong. Usually it is the opposite — developers become the fallback because the system was never designed to let non-technical teams move safely on their own. Marketing asks for a landing page. Product asks for a new section. A regional team needs translated copy. Leadership wants a campaign live tomorrow.
If the CMS cannot support those changes cleanly, everything becomes a development request. Marketing slows down, and developers get pulled into work that is not really engineering work.
A good rebuild should reduce this kind of dependency. Not by letting everyone change everything, but by designing clear boundaries. Marketing should be able to launch within approved structures. Design should control reusable patterns. Developers should build the system, not manually assemble every campaign. The goal is not no-code everything. The goal is controlled autonomy.
Campaign pages expose weak systems fast
Ordinary page maintenance can limp along even in a broken system. Campaign work is where the cracks become obvious.
A product launch, seasonal campaign, or regional promotion needs landing pages, forms, tracking, translated content, product references, campaign assets, legal review, launch timing, post-campaign reporting, and redirect decisions — often in parallel, often under time pressure. If every one of those pieces is handled as a one-off task, the campaign becomes a coordination problem before it becomes a marketing problem.
The best rebuilds make repeatable work easier. The worst rebuilds produce one beautiful version of the website and then leave the team to improvise every campaign after launch.
Architecture should come before implementation
This is where most rebuild projects need a different starting point.
Do not start with homepage design, CMS preference, plugin lists, or frontend framework decisions. Start with the operating model. Map the work first.
What does marketing need to publish every week? What does product need to update every month? What content requires approval? What content requires translation? What can local teams control? What must stay centralized? What should never need a developer? What does leadership need to measure? What happens to old pages after launch?
Only after those questions have answers does the platform decision become clear.
I usually think about serious website work in phases: system definition, architecture, build, rollout, and stabilization. The system definition phase is not bureaucracy. It is how you prevent the rebuild from producing a prettier version of the same operational problem.
Not every project needs this
There is an important counterargument worth making.
Not every website needs a deep operating model review. If the business is small, the website is simple, and one or two people own everything, a lightweight setup is completely fine. A simple WordPress site, a Shopify theme, or a managed CMS can be exactly right. The goal is not to make every website more complex. The goal is to match complexity to reality.
But if the company has multiple teams, approval layers, products, languages, campaigns, assets, and reporting requirements, treating the project as "just a redesign" is risky. The operating model already exists. It is either designed intentionally or discovered painfully during the project.
The brief changes everything
A weak rebuild brief says: "We need a modern website with better design and easier editing."
A stronger one says: "We need a website architecture that helps marketing launch campaigns faster, lets product update information safely, supports translation workflows, reduces developer bottlenecks, improves reporting, and gives the business clearer ownership after launch."
That is a very different project. It changes discovery, CMS selection, content modeling, permissions, migration planning, and what success means at the end.
A successful rebuild is not just a better-looking website. It is a clearer way for the company to operate its digital presence.
Before starting, map how the website should work after launch. Not just what pages it needs, not just what it should look like. Map the real operating questions — who creates, who approves, who translates, who updates, who publishes, who measures, who maintains.
Once those answers are clear, the architecture has something to support.
If you are planning a serious B2B website rebuild, migration, or CMS change, this is the part worth solving first. My B2B website development work is built around that idea: architecture before implementation, so the website supports the way the business actually needs to work.
And if you already have an internal development team but need senior architectural input around Payload, Next.js, workflows, or migration decisions, Next.js and Payload CMS advisory is often the better starting point.
