Website Rebuilds: Start with Architecture, Not Mockups | Build with Matija
Website Rebuilds: Start with Architecture, Not Mockups
Why complex website rebuilds must begin architecture-first: define content models, CMS migration scope, workflows, and…
·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 rebuild projects get off to a confident start: the homepage concept lands, everyone reacts to it, and the project feels real. That momentum is seductive. It is also where serious rebuilds start going wrong.
The hardest decisions in a B2B rebuild, a multi-brand site, a CMS migration, or a site connected to internal workflows — are architectural decisions. They are rarely visual. A mockup can create the feeling of progress before those decisions have been made. Deferring them is where expensive rework begins.
The design conversation arrives before the hard questions do
When a company says "we need a new website," the conversation moves to design almost immediately. The homepage looks dated, the navigation feels cluttered, the brand has evolved. Starting in Figma seems natural.
A modern website carries more responsibility than a set of pages, though. It is a publishing system, a content model, a marketing workflow, a migration project, and sometimes a core part of the sales process. Visual design is one layer of that. The layers underneath determine whether the project succeeds or falls apart after launch.
A mockup produced before the architecture is understood will, almost inevitably, assume things that have not been decided:
A mockup shows what a page might look like. A rebuild plan explains how the site will work.
These are different documents and different conversations.
A serious rebuild needs answers to practical questions before full production begins:
Content model. Are case studies, products, services, locations, and landing pages separate content types with their own structures, or are they just pages? This decision shapes everything downstream.
Ownership and permissions. Can marketing publish landing pages without involving a developer? Can regional teams edit only their own content? Can legal review and approve before anything goes live?
Migration scope. How many WordPress posts, ACF fields, PDFs, redirects, authors, and legacy URLs need to move? What can be archived? What must be preserved exactly?
Integration surface. Does the website need to connect to HubSpot, Pipedrive, Shopify, Medusa, an ERP, or internal automation tools? Discovering these late is expensive.
Life after launch. Can the team actually maintain what gets built, or will every content change still require a developer?
These questions are not secondary to the project. They determine whether the proposal is a real scope or a confident guess. I approach this directly in my thinking about B2B website development, where the website is treated as part of the company's sales and marketing system rather than a standalone brochure.
The CMS question depends on answers that come before it
Rebuild conversations often jump to platform choice early. WordPress or Payload CMS? Headless or traditional? Next.js or something else? These are valid questions to eventually answer.
A more useful starting question is: how does the business need to operate?
If marketing needs to launch structured landing pages without developer involvement, the CMS needs reusable sections and guardrails. If multiple brands or regions share content, the architecture needs to support that without creating editorial chaos. If product data already lives in a commerce system, the CMS should not blindly duplicate it. If complex approval workflows exist, permissions need to be designed before content modeling begins.
The CMS decision is not about feature lists. It is about matching the system to how the company actually works. I covered this in more depth in how to choose a CMS, because the real question is system-fit, not capability comparison.
This is also why a WordPress-to-Payload migration cannot be treated as a copy-paste exercise. It involves content modeling, URL planning, media handling, redirects, editor experience, and technical decisions that have to be made deliberately. The Payload CMS migration service and the WordPress to Payload migration guide go deeper into what that actually involves.
Clear architecture makes design better
Defining architecture first is not a way to delay design work. A well-mapped architecture gives designers better information to work with.
When the content model is clear, designers know what they are actually designing for. When workflows are defined, they can create editor interfaces that real people can use. When reusable sections are established, they can build flexibility with structure. When migration scope is understood, they can avoid layouts that only function with perfect new content but break when real legacy content arrives. When integrations are known upfront, forms, filters, product data, and gated content can be handled properly from the start.
Design should shape a system that has already been understood, not guess at what the system might eventually become.
This is particularly relevant for companies that want marketing teams to move quickly without turning the website into a maintenance burden. I wrote about that balance in why marketers should not need developers for every landing page. The goal is safe freedom, not unlimited access.
The real risk is not the homepage
The homepage receives most of the attention because it is visible. The actual project risk tends to sit elsewhere.
It sits in old content nobody has audited. It sits in URL structures that cannot simply change without a redirect strategy. It sits in CMS fields built years ago that nobody fully understands anymore. It sits in product data that marketing wants to display but a separate ecommerce system owns. It sits in internal approval steps that were never written down. It sits in regional teams who need autonomy without breaking brand consistency. It sits in analytics events that leadership will expect to see tracked after launch. It sits in integrations that appear small until they surface too late.
Some rebuilds are in trouble before design starts — not because of poor taste, but because the project kicked off without understanding the website's actual role inside the business. I wrote about this pattern in when a website rebuild is actually an operating model problem. A redesign alone will not fix unclear ownership, unclear workflows, and unclear technical architecture.
Architecture-first does not mean overcomplicating small projects
A fair counterargument: not every project needs a deep architecture phase.
Refreshing a ten-page marketing site with no CMS migration, no integrations, no approval workflows, and no meaningful SEO footprint — starting with design is fine for that scope. A one-off landing page does not need an architecture sprint. Early design exploration has genuine value when the main problem is visual positioning or brand direction.
The point is not "never start with design." The point is to match the process to the risk.
The more a rebuild touches CMS structure, content migration, permissions, workflows, integrations, product data, multiple teams, SEO, or reporting, the more expensive it becomes to start with visual assumptions. Architecture is not about adding weight to the process. It is about adding clarity.
What architecture-first actually produces
Before committing to the full build, a serious rebuild should define the foundations:
Website goals. What is the site supposed to improve? Lead generation, sales enablement, campaign speed, content publishing, international growth, customer support — these need to be ranked, not just listed.
Content model. Pages, articles, case studies, products, services, locations, team members, landing pages, FAQs, and reusable sections all need defined structure before design begins.
CMS requirements. What should editors create, update, preview, schedule, approve, and reuse? What stays under developer control?
Migration scope. What content, media, metadata, redirects, and URLs need to move? What gets archived? What must be preserved?
Permissions and workflows. Who can edit, approve, publish, translate, or manage specific sections of the site?
Integrations. Which systems connect to the website? CRM, ecommerce, newsletter, analytics, search, ERP, forms, payment, automation.
Design system and reusable sections. What level of flexibility do marketers get? Which components are reusable? Which constraints protect brand consistency?
Analytics and conversion tracking. Which forms, CTAs, downloads, demos, and journeys need tracking? Defined before launch, not after.
Technical architecture. What stack makes sense given everything above? Should the site move CMS, go headless, or stay where it is?
Delivery plan and risks. What are the unknowns? What needs a proof of concept? What affects timeline, budget, and post-launch maintenance?
This is the kind of work that makes a rebuild estimable. A proposal built without it is not a scoped engagement. It is an informed guess that will require renegotiation.
Why a paid architecture sprint is a sensible first step
For complex rebuilds, the first paid deliverable should often be an architecture sprint rather than a production build.
The output of a well-run architecture sprint is practical, not abstract:
Current website and content audit
Business goals and priorities
CMS and content model recommendation
Migration risk map
Integration map
Permissions and workflow outline
Technical architecture recommendation
Phased delivery plan
Budget and scope ranges
Open questions and identified project risks
That output should help the business make a decision — rebuild everything now, phase it, migrate the CMS first, keep ecommerce where it is, bring in advisory support for the internal team. This is close to how I think about Next.js and Payload CMS advisory. Sometimes the highest-value work is helping the team make the right decisions before implementation momentum makes those decisions costly to revisit.
The first deliverable should be a map
For a serious rebuild, the first deliverable is a map.
A map of the content. A map of the CMS. A map of the workflows. A map of the migration. A map of the integrations. A map of the risks. A map of what needs to be true for the rebuild to succeed.
Once that map exists, design becomes precise. The homepage is no longer a guess. The CMS is no longer an afterthought. The proposal reflects real decisions rather than surface-level scope. Both sides of the engagement can see what is actually being built.
A serious rebuild can still be expensive. But the cost should be attached to understood scope, not assumptions. The client knows what they are buying. The implementation team knows what they are responsible for. The project has a real chance of becoming something the business can use after launch.
Before asking for mockups
Before opening Figma on a serious rebuild, a few harder questions are worth asking first:
What content needs to exist? Who manages it? What needs to move from the old site? What cannot break? Which systems need to connect? Which workflows should the CMS support? What should marketing be able to do without developer involvement? What decisions need to be made before the full project can be responsibly scoped?
If those answers are not clear, start with architecture.
Mockups can make a rebuild feel real. Architecture makes the rebuild responsible.
If you are working through a rebuild decision and need help mapping the architecture before committing to production, feel free to reach out. I am happy to look at where you are and what the right first step actually is.
