Redesigning a Website with Headless WordPress and Next.js

The Tech Stack and Tools for Our Headless WordPress and Next.js Website

In the first article in this series, I explained why I am redesigning the Morgan Web Development website around a headless WordPress architecture. The larger goal is to demonstrate how a growing business can move from a traditional WordPress website toward a more structured digital platform when it needs greater control over content, branding, application logic, and software releases.

Before we start planning individual features or writing code, the next step is to establish the technology that will make up the platform and the tools I will use to build it.

There is an important distinction between those two things.

The tech stack is the technology the finished platform actually depends on. If I replaced one of those technologies, I would be changing the architecture of the application itself. For this project, that means WordPress, Next.js and the technologies that come with it, and AWS as the production infrastructure.

The development tools, on the other hand, help me create and manage the platform but are not part of the application that customers ultimately use. I am going to develop in Cursor, run WordPress locally with XAMPP, design the new experience in Figma, manage the source code through GitHub, and organize the project in Lancer. Another developer could use a different editor or local development environment without fundamentally changing how the finished application works.

Keeping those categories separate helps us focus on why each decision matters.

The tech stack

The core technology stack for the new Morgan Web Development platform will be relatively small. WordPress will remain the content-management system, Next.js will become the public-facing application, and the production platform will be hosted on AWS.

Those technologies have different responsibilities, which is intentional. One of the goals of the redesign is to stop asking a single WordPress installation to manage content, presentation, application behavior, and deployment as though they are all the same concern.

WordPress as the content-management system

The first major technology decision is that WordPress is staying.

My original idea for the redesign was to move the existing content into a different headless CMS. As I thought more carefully about the problem, however, I realized that I would be replacing a system that already does a large part of what I need.

WordPress is a mature content-management system. It gives us an established environment for creating and editing content, managing media, defining different types of content, and controlling users, roles, and permissions. Those capabilities are particularly useful for the kind of growing business this series is intended to represent.

What will change is WordPress’s responsibility.

In the current architecture, WordPress manages the content and is also responsible for producing the public-facing website. The theme and page-builder environment determine how that content gets displayed, and plugins can influence both the administrative and frontend experience.

In the new architecture, WordPress will focus on being the CMS. It will become the source of truth for the content the business manages, while another application becomes responsible for presenting that information to customers.

That means an article can remain an article inside WordPress without also containing all of the decisions about how the article page should look. Services, projects, landing-page content, and other information can be modeled around what the content actually represents rather than around how a particular WordPress template happens to display it.

This also allows us to retain one of the biggest advantages of WordPress for a business team: different people can interact with the CMS according to their responsibilities. Writers, editors, and administrators do not need access to the application code simply because they need to manage content.

Next.js as the frontend application

Next.js will become the public-facing application that visitors interact with.

WordPress will provide the content, but Next.js will decide how that content becomes the actual website. The navigation, page templates, reusable interface components, responsive behavior, integrations, and other frontend functionality will live in the Next.js application rather than inside a WordPress theme.

This is one of the most important architectural changes in the project because it gives us much clearer control over the presentation layer.

Instead of allowing every page to accumulate its own styling decisions through a page builder, the frontend can be constructed from reusable React components. When we design a button, card, navigation pattern, hero section, or content block, that pattern can become a reusable part of the application rather than something that has to be recreated on every page.

Next.js also gives us a strong foundation if the website needs to become more application-like over time. A growing company’s digital platform may eventually need to do more than present marketing content. It may connect to additional services, provide interactive tools, expose customer-specific functionality, or become part of a larger application ecosystem. Having the frontend operate as an application gives us room to support those requirements without continuously extending a WordPress theme.

React and TypeScript

Next.js gives us the framework for the frontend, while React provides the component model we will use to construct the interface.

That component model is important to the broader goal of the redesign. Instead of treating every page as its own implementation, we can define reusable pieces of the interface and assemble pages from them. That makes it much easier for the implementation to reflect the design system we will create later in Figma.

TypeScript will provide the language foundation for that application code. The goal is not simply to add another technology to the list, but to make the contracts between parts of the application more explicit as the system grows. Content coming from WordPress, component properties, application data, and integrations can have defined structures rather than relying entirely on assumptions about what data will be available.

Together, Next.js, React, and TypeScript form the frontend application stack.

AWS as the production environment

The finished platform will be deployed on AWS.

I want the infrastructure to follow the same separation of responsibilities as the application itself. WordPress and Next.js are part of the same digital platform, but that does not mean they need to run as one application on one traditional WordPress server.

AWS gives us the flexibility to host the different parts of the system according to their actual needs. WordPress can have the environment it requires as the content-management system, while the Next.js application can follow its own deployment process. Storage, networking, caching, databases, monitoring, and other infrastructure can be introduced as the requirements become clearer.

I am deliberately not choosing every individual AWS service yet.

There are several legitimate ways to deploy an architecture like this, and I do not want to select infrastructure simply because it might eventually be useful. When we reach the deployment portion of the project, I will look at the actual requirements and design the production environment around them.

At this stage, AWS is an architectural choice. The exact AWS implementation will be a later design decision.

The tools we will use to build it

The technologies above define the platform. The next group of tools will help me design, develop, test, manage, and release it.

These tools are important to the workflow, but they are intentionally less fundamental to the architecture. If another developer wanted to follow this series and use a different editor instead of Cursor or a different local WordPress environment instead of XAMPP, the overall platform could remain essentially the same.

XAMPP for local WordPress development

I am going to use XAMPP to run WordPress locally during development.

WordPress needs PHP, a web server, and a database, and XAMPP gives me a straightforward way to run those pieces on my development machine. That gives me a local WordPress installation where I can change configuration, experiment with content structures, test custom functionality, and work on the connection between WordPress and Next.js without making those changes directly in production.

That local environment will become particularly useful once we begin adapting WordPress for its new role. We will need to think about how content is structured, how different data types are represented, what information the frontend needs, and how that information becomes available to the Next.js application.

Having a local environment gives us somewhere safe to work through those questions.

XAMPP is simply the tool I am choosing for that job. It is not a requirement of headless WordPress. Someone following the series could use another WordPress development environment and still build the same architecture.

Cursor for development

I will write the application code in Cursor.

Cursor is currently the development environment I prefer because it combines a familiar code-editing workflow with AI-assisted development capabilities. I expect to use it heavily throughout the project for creating components, working through implementation decisions, troubleshooting problems, refactoring code, and translating parts of the design system into the frontend application.

AI-assisted development is particularly useful for the workflow I want to demonstrate because there should be a relatively direct path between the components we define during design and the React components we eventually implement. Cursor can help with the mechanical parts of that process, but the architectural decisions still need to come from the requirements of the application.

I still need to decide what should become a component, how components should relate to one another, what belongs in WordPress, what belongs in the frontend, and whether the implementation actually follows the standards of the project. AI can make implementation faster, but it does not replace those decisions.

Cursor is also not required to follow this series. Visual Studio Code, WebStorm, or another development environment can be used instead. The application code should remain portable regardless of which editor a developer prefers.

That distinction is important for a business application. The source code belongs to the project; it should not become dependent on one developer’s preferred editor.

Figma for the design system

Figma will be used to redesign the site and define the visual system before we begin implementing the frontend.

I do not want the design work to consist only of drawing individual pages. One of the major goals of this redesign is to move away from a model where every page can become its own collection of design decisions.

Instead, Figma will be used to define typography, colors, spacing, buttons, cards, navigation, forms, content sections, and the other reusable patterns that make up the interface. Pages can then be designed using those established components.

That approach fits naturally with React development. A reusable component in Figma can inform a reusable component in the Next.js application, which creates a much stronger connection between the design system and the actual implementation.

It also supports the larger business goal behind the architecture. Content editors should be able to manage content without also needing to make decisions about how every part of the brand should look.

GitHub for source control

The application code will live in GitHub.

That gives the project a clear history of what has changed and creates a much more deliberate process around application development. Changes can be made in branches where appropriate, reviewed, tested, and then merged into the version of the application that is ultimately deployed.

This is another area where the headless architecture helps create a clearer boundary between content and software.

Publishing an article in WordPress is a content-management activity. Changing the React component responsible for displaying an article is a software-development activity. The latter should have source control, a change history, and an appropriate testing and release process.

GitHub will provide that foundation throughout the project.

Lancer for project management

I am also going to manage the redesign in Lancer.

This project is more than a website mockup and a collection of development tasks. It includes planning, architecture, design, content modeling, development, integration, testing, migration, infrastructure, and deployment. I want to manage that work as an actual software project rather than keeping the plan scattered across notes and development prompts.

Using Lancer also gives me a chance to manage a real project through the same platform I use for project and client work.

As we move into the planning portion of the series, I will break the redesign into the work that needs to be completed, organize it into a manageable project, and use that plan to guide the implementation.

The distinction matters

The easiest way to understand the overall setup is to separate the platform from the workflow used to create it.

The production platform depends on WordPress, Next.js, React, TypeScript, and AWS. Those technologies determine how content is stored and managed, how the frontend is built, and where the finished system runs.

The development process will use XAMPP, Cursor, Figma, GitHub, and Lancer. Those tools help me run the system locally, write the code, create the design system, track changes, and manage the project.

If I decide tomorrow that I prefer another editor over Cursor, the architecture does not change. If another developer prefers a different way to run WordPress locally, the architecture does not change. We could also manage the project in another project-management tool without changing the application visitors eventually use.

Replacing WordPress or Next.js would be different because those technologies have actual responsibilities within the running platform.

That distinction is useful beyond this particular project. It is easy when planning software to produce one long list of technologies and call it a stack, but not everything used during development becomes part of the finished system. Being explicit about the difference makes the architecture easier to understand and makes future technology decisions easier to evaluate.

Starting with a small, understandable architecture

There will be more decisions to make as the project develops.

We will need to determine how Next.js retrieves content from WordPress, how we structure custom content types, how previews work, how forms are handled, how images are delivered, how caching works, how the application is tested, and what the final AWS infrastructure looks like.

I do not think we need to make all of those decisions before we have enough information to make them well.

For now, the architecture has the pieces we know we need. WordPress manages the content. Next.js, React, and TypeScript build the public-facing application. AWS will provide the production infrastructure.

The supporting workflow is also established. Figma will define the design system, XAMPP will provide the local WordPress environment, Cursor will be the editor I use to develop the application, GitHub will manage the code, and Lancer will help organize the work.

That is enough to move to the next part of the project.

Before I start designing components or writing the application, I want to define exactly what we are building, break that work into a plan, and establish the requirements the new platform needs to satisfy.

Redesigning a Website with Headless WordPress and Next.js

A lot of businesses begin with a website that is intentionally flexible. WordPress, a good theme, a page builder, and a collection of plugins can give a small team everything it needs to establish an online presence without making a large investment in custom software. Someone in marketing can create a landing page, an owner can update content, and new functionality can often be added by installing a plugin rather than starting a development project. For a growing business, that flexibility can be a major advantage because it keeps the cost of making changes relatively low and allows the website to evolve alongside the company.

There is nothing inherently wrong with that approach, and this series is not going to argue that every WordPress site should eventually be rebuilt as a custom application. In many cases, a traditional WordPress site remains the right solution for years. The reason to reconsider the architecture is not that the original website was poorly designed or built with the wrong technology. It is that the needs of the business have changed.

As a company grows, its website often becomes more important to the way the business operates. More people are responsible for creating and managing content. Branding becomes more established and needs to remain consistent across every page. The site may begin integrating with CRMs, internal systems, marketing platforms, external APIs, or custom applications. Plugins that once solved relatively small problems can become important dependencies, while developers and content teams may find themselves working on the platform at the same time.

At that point, the questions surrounding the website begin to change. The business is no longer only concerned with how quickly someone can create a page or make an update. It also needs to think about who should be allowed to publish, what different users should be able to change, how the brand is protected, where business logic belongs, how third-party dependencies are managed, and how software changes can move through testing and into production without interfering with ongoing content work.

That is the transition I want to explore in this series.

I have been meaning to redesign the Morgan Web Development website anyway, so I am going to use it as the practical example throughout the project. Rather than rebuilding it privately and writing about the finished result afterward, I want to document the decisions as I make them and show how I would approach this kind of modernization for a growing business. Morgan Web Development is the case study, but the larger subject is how a company can move from a highly flexible website toward a more structured digital platform without unnecessarily giving up the tools and capabilities that are already working.

When flexibility starts to create new problems

The flexibility of a traditional WordPress site is often exactly what makes it useful early on. A page builder gives someone the freedom to create new layouts, adjust spacing, select colors, change typography, and assemble a page without waiting for a developer. Plugins provide a similar advantage by allowing the business to add features without building everything internally. If the website is managed by one or two people and changes are relatively simple, there may be little reason to put more structure around that process.

The tradeoff becomes more noticeable as additional people become involved. A page builder that allows one person to quickly create a landing page also gives that person a great deal of control over how the page looks. When several people are working on the website, that can lead to small inconsistencies that accumulate over time. One person uses a slightly different heading size, another creates a new button style, and another adjusts spacing to solve a problem on a single page. Individually, those changes may seem minor, but eventually the site can become a collection of design decisions rather than a consistent system.

For a growing company, that becomes less desirable. The business may have invested in a brand system, created standards for how its products and services are presented, and developed expectations around how customers should experience the website. At that stage, the goal is no longer to give every editor complete control over visual presentation. It is to give people the right amount of control for the work they are responsible for.

A content editor should be able to manage content without having to make design decisions every time something is published. A marketing team may need enough flexibility to assemble pages from approved sections without being able to change every part of the design system. Designers should be able to define how the brand is represented, while developers should be able to implement those decisions consistently across the application. The organization still needs flexibility, but the flexibility becomes more intentional.

The same thing can happen with plugins. The WordPress ecosystem is one of the platform’s greatest strengths because businesses can use existing software to solve common problems instead of building everything themselves. That remains valuable as a company grows, but it becomes increasingly important to understand which parts of the platform are simply using third-party tools and which parts contain logic that is critical to the business.

A plugin may start by solving a relatively isolated problem, but over time other workflows can begin depending on it. Additional plugins may interact with it, custom configuration may accumulate around it, and eventually the organization has important business behavior distributed across several third-party systems and administration screens. The question is not whether plugins are good or bad. It is whether the business understands where important logic lives, who owns it, and what happens if one of those dependencies changes.

Moving from a website to a more structured platform

The architecture I want to demonstrate is ultimately about creating clearer boundaries between different responsibilities. In a traditional WordPress site, content, presentation, configuration, and application behavior can all become closely connected. That works well when the platform is relatively simple, but it can become difficult to manage when each of those areas begins changing for different reasons.

The new Morgan Web Development site will separate those concerns more intentionally. WordPress will remain responsible for managing content, but it will no longer be responsible for rendering the public-facing website. The frontend will become a separate application built with Next.js, allowing the visual presentation and application behavior to be managed independently from the content itself.

I will get into the specific technology choices in the next article, but the architectural idea is more important than any individual tool. I want to separate the content and data the business manages from the templates and visual components used to present that information, while also giving application-specific logic a clear place to live.

That means an article can remain an article regardless of how its page is designed. A service can have a defined structure without containing the instructions for how every part of it should appear on screen. A reusable section can have an approved visual implementation that editors can use without recreating the design every time. The presentation can change without requiring the underlying content to be rewritten, and content can continue to be created without changing the application code.

This is also where stronger roles and permissions become more useful. WordPress already provides a mature content-management environment with users and different levels of access. A business can allow someone to create content without giving that person complete control over the platform, while other users can be responsible for review, publishing, or administration. As the number of people involved grows, those distinctions become increasingly valuable.

The result is not meant to make the platform harder for people to use. Ideally, it does the opposite. Instead of asking every person who touches the website to understand design, development, content management, and platform configuration, each part of the system can provide the controls that are appropriate for that role.

What this series is going to demonstrate

I want this series to cover the entire transition rather than starting with the finished architecture and working backward. One of the reasons I am using Morgan Web Development as the example is that it already exists as a real site with real content and existing decisions that have accumulated over time. I am not starting with a clean demonstration project designed specifically to make the architecture easy.

The first part of the process will be understanding what I am actually trying to change. I need to evaluate the existing platform, decide what should remain, identify what has become difficult to maintain, and establish the requirements for the new version before I begin rebuilding anything. From there, I will define the technology stack and explain why I chose each tool and what responsibility it will have within the overall architecture.

The design process will involve more than creating new page mockups. I want to establish a structured visual system that can be implemented consistently across the site, while still giving content editors appropriate flexibility. I will also need to look at how the existing WordPress content is structured and decide what needs to change when WordPress is no longer responsible for rendering the frontend.

Once those foundations are in place, the series will move into implementation. I will build the new frontend, connect it to the WordPress content, create the reusable components and templates, work through the development and release workflow, migrate the existing site, test the new platform, and eventually replace the version that is currently in production.

I also want to document the decisions that change along the way. Architecture always looks cleaner after a project is complete. During the actual work, assumptions are tested, unexpected constraints appear, and some ideas that looked good during planning turn out not to be the best choice once they are implemented. Those adjustments are part of building software, and I think they are worth including rather than presenting the finished result as though every decision was obvious from the beginning.

Who this approach is for

This series is not intended to suggest that every business running WordPress needs to move to a headless architecture. A traditional WordPress site can still be an excellent choice, particularly when the website is relatively simple, the number of people managing it is small, and the existing tools are not creating meaningful operational problems.

Introducing a separate frontend application adds complexity of its own. There are more systems to maintain, integrations have to be designed, and features that might work automatically in a traditional WordPress environment may require a different approach. That additional architecture needs to provide enough value to justify the work required to build and maintain it.

The businesses I have in mind are the ones that have started to feel the limitations of the model that helped them get started. They may have several people working on the website and need clearer publishing controls. Maintaining a consistent design may be getting harder. Plugins may be supporting increasingly important business processes. The website may be integrating with more systems, or development work may be difficult to release without interfering with ongoing content changes.

Those are not necessarily signs that WordPress has failed. They are often signs that the website has become more important to the company.

The architecture of the platform needs to be allowed to grow with that importance.

For Morgan Web Development, the next step will be to keep the parts of WordPress that remain useful while creating clearer boundaries around content, design, development, and application logic. The website is due for a redesign anyway, so it gives me a practical opportunity to work through that transition and document what it actually takes.

That is what I want this series to become: a real example of how a growing business can move from a flexible website toward a more structured digital platform, why it might choose to make that transition, what tradeoffs are involved, and how the process works from the initial planning through the final launch.

In the next article, I will get into the technology stack and the tools I am going to use to build it.