In the first two articles in this series, I established why I am redesigning the Morgan Web Development website and the architecture I am going to use to do it. The existing WordPress site will evolve into a headless architecture where WordPress remains responsible for content management, Next.js becomes the public-facing application, and the production platform is eventually deployed on AWS.
At this point, it would be easy to open Figma, initialize a Next.js application, or start configuring a local WordPress installation. Those are the more visible parts of the project, and they are usually the parts people are most excited to start. Before I do any of them, though, I want to turn the broad idea of “redesign the Morgan Web Development website” into an actual software project.
A project like this involves much more than creating a new design and writing some frontend code. I need to understand the existing site, decide what content and functionality need to be preserved, define the new information architecture, establish how WordPress and Next.js will divide their responsibilities, create the design system, build the application, migrate and restructure existing content, handle SEO and redirects, test everything, design the AWS deployment, and eventually move the new platform into production.
Some of those activities depend on decisions that have not been made yet, while others need to happen in a particular order. If I start building immediately, it is easy to make technical decisions simply because I need an answer in the moment. I would rather spend some time understanding the work first and then begin implementation with a clearer idea of where the project is going.
For this project, I am going to use Cursor’s Plan Mode to help me work through that process. Once I have developed and reviewed a plan I am comfortable with, I will use the Lancer MCP server to turn that plan into the project I will actually manage while completing the redesign.
Starting with the project, not the code
The first thing I am going to create is the GitHub repository for the new Morgan Web Development application. I want the project to have a home before I start filling it with application code, design exports, or configuration.
I am intentionally creating the repository before initializing Next.js. There is nothing in the application yet that I need in order to think through the project. Starting with an empty repository also helps reinforce that planning and implementation are separate activities. I can establish what I intend to build without allowing the structure generated by a framework to start influencing decisions that should come from the requirements.
Once development begins, this same repository will become the source of truth for the Next.js application. It will contain the history of how the frontend evolves, allow changes to be developed in branches where appropriate, and eventually become part of the automated build and deployment process when I move the application into AWS.
Creating the repository is a simple step, but it establishes the development environment and gives the project a clear starting point. From there, I can open it in Cursor and begin working through the project plan.
Using Cursor to develop the plan
I use Cursor for development, but I do not want the first use of AI in this project to be generating code. I want to use it to help me reason through the project before implementation begins.
There is an important difference between asking an AI tool to “build a website” and using it to assist with software planning. I already know quite a bit about what I am trying to accomplish. I know why I am changing the architecture, the broad technology choices have been made, and I have an established direction for how Morgan Web Development should be positioned. I also know that this is more than a visual redesign because the project involves changing the relationship between the CMS, the frontend application, the content model, and the development and release process.
What I do not yet have is a complete view of all of the work required to get from the current platform to the new one.
That is where I think Plan Mode can be useful. I can provide the context I already have and ask Cursor to help organize it into logical phases, identify dependencies between areas of work, surface decisions I have not made yet, and point out things I may have overlooked. The result should not be treated as an automatically correct project plan. It is a structured starting point that I can evaluate and refine.
My initial planning prompt will be something along these lines:
I’m redesigning the Morgan Web Development website and want to create a detailed project plan before beginning design or development.
The existing site is built with WordPress. The new architecture will continue using WordPress, but it will operate as a headless CMS responsible for content management rather than rendering the public-facing website. The frontend application will be built with Next.js, React, and TypeScript, and the production platform will eventually be deployed on AWS.
I will use Figma to create the visual design system and interface designs, XAMPP for local WordPress development, Cursor as my development environment, GitHub for source control, and Lancer for project management.
Morgan Web Development is being positioned around consulting and custom application development, with the core client-facing message: “I help businesses plan, build, and improve custom software.”
Treat this as a complete software modernization project rather than simply a visual website redesign. Help me develop a project plan that considers discovery and requirements, evaluation of the existing site, information architecture, content strategy and modeling, the Figma design system, configuring WordPress for headless use, Next.js application development, the integration between WordPress and Next.js, migration and restructuring of existing content, SEO and redirects, accessibility, performance, testing, AWS architecture and deployment, production cutover, and post-launch validation.
Break the work into logical phases and identify the major deliverables, dependencies, decisions, and open questions within each phase.
Do not invent requirements, integrations, existing functionality, or business needs that have not been established. When important information is missing, identify it as an open question rather than making an assumption.
Do not begin implementation. The purpose of this step is to understand and plan the project before I start designing or writing application code.
I expect that prompt to change once I actually start the planning process. I do not think there is much value in pretending that one carefully written prompt will perfectly define a project of this size. The first prompt needs to provide enough context to begin a useful planning conversation, and the plan can then improve through review and iteration.
That is also an important part of how I want to use AI throughout this project. I do not want the workflow to be based on giving Cursor a large request and accepting whatever comes back. I want to use it as another tool for working through decisions while I remain responsible for deciding what actually belongs in the project.
Reviewing the plan before turning it into work
The most important part of this process will probably happen after Cursor produces the initial plan.
I need to review it like I would review a plan created by anyone else. I will look at the phases it proposes and determine whether the order makes sense. I will compare its assumptions against what I actually know about the existing site and the requirements of the redesign. If it identifies decisions that have not been made, I can decide whether they need to be resolved immediately or should remain open until another stage of the project.
I also expect there will be work in the initial plan that is technically reasonable but unnecessary for this particular project. AI tools can be very good at producing comprehensive lists, but comprehensive is not always the same as useful. A project plan can become so detailed that maintaining the plan becomes a project of its own.
I want enough detail to understand the major pieces of work, their dependencies, and what needs to happen next. I do not need hundreds of tasks representing every small implementation action I might eventually take.
That balance matters because the plan needs to remain useful after planning is complete. If the project structure is too broad, it will not help guide execution. If it is too granular, I will spend more time maintaining tasks than completing them.
The planning process should also help expose questions that I need to answer before development begins. For example, I already know that WordPress will become the CMS and Next.js will become the frontend, but there are still decisions to make about how content should be modeled, what flexibility editors should have, how the frontend will consume WordPress data, how previews should eventually work, and what the production AWS architecture should look like.
I do not necessarily need every answer before the project begins. I do need to know that those decisions exist and understand when they need to be made.
That is what I want the plan to provide: enough structure to guide the project without creating the illusion that every decision can be predicted before the work starts.
Turning the approved plan into a Lancer project
Once I am satisfied with the plan, I need to move it from a planning document into something I can actually manage while I work.
That is where I will use Lancer.
The redesign will likely include major areas of work around discovery and requirements, information architecture, content modeling, design-system development, WordPress configuration, Next.js development, integration, content migration, SEO and accessibility, testing, AWS deployment, launch, and post-launch validation. The exact structure should come out of the planning exercise rather than being predetermined now, but whatever that structure becomes needs to translate into manageable project work.
I am going to use the Lancer MCP server to make that transition.
Because the planning work is already happening inside Cursor, the project context and approved plan are available in the same environment that can communicate with Lancer. Instead of manually reading through the final plan and recreating every phase and task in a project-management system, I can ask Cursor to create the project based on the plan we have already reviewed.
The prompt for that step will look something like this:
Using the project plan we have just created and approved, use the Lancer MCP server to create a new project for the Morgan Web Development website redesign.
Translate the plan into manageable project work while preserving its major phases, dependencies, and intended sequence. Tasks should represent meaningful units of work rather than creating a separate task for every minor implementation detail.
Use the approved project plan as the source of truth. Do not introduce new requirements, functionality, or assumptions while creating the project.
After creating the project in Lancer, compare the resulting project structure with the approved plan and identify anything that could not be represented accurately or requires manual follow-up.
I am particularly interested in this part of the workflow because planning and project management are often disconnected. An AI tool may help someone produce a detailed plan, but that plan then becomes a document that has to be manually translated into another system before anyone can start using it.
The MCP connection gives me a way to carry more of that context forward. Cursor can help me think through the project, and after I have reviewed and approved the result, it can use that same context to create the work I will manage in Lancer.
This is also a useful real-world test of Lancer itself. I am not creating an artificial example designed to demonstrate the feature. I will be managing an actual software project, and if I find that parts of the planning structure do not translate well, the workflow is awkward, or I need project-management capabilities that are missing, that becomes useful feedback for Lancer as a product.
The plan is a starting point, not a prediction
I do not expect the project plan created at the beginning of this redesign to perfectly describe everything I will do between now and launch.
The design process will teach me things that are difficult to know today. Once I start examining the existing WordPress content more closely, I may discover inconsistencies or structures that need more work than I expected. Building the headless integration will almost certainly force decisions that do not need to be made during initial planning. The AWS deployment may introduce infrastructure considerations that are not relevant until the application is much closer to being complete.
That is normal software development.
The purpose of the plan is not to eliminate uncertainty. It is to make the uncertainty visible enough that I can manage it.
I want to understand the major areas of work before I start, identify dependencies before they become blockers, know which decisions need to be made at different points in the project, and have a structure that helps me see where the work stands as the redesign progresses.
The plan can change as I learn more. Tasks can be added, removed, or reorganized. A phase that originally looked straightforward may turn out to need more work, while something I expected to be difficult may end up being relatively simple. Having a plan does not prevent those changes; it gives me a framework for making them intentionally.
That is also why I want to manage this redesign as an actual software project rather than keeping a mental list of what I think needs to happen next. The architecture is changing, the content is changing, the design is changing, and eventually the production infrastructure will change as well. Having a shared structure for that work should make it much easier to understand how the pieces fit together.
Once the repository exists, the project plan has been developed and reviewed in Cursor, and that plan has been turned into manageable work in Lancer, I will have enough structure to start the first major phase of the redesign.
Then I can finally open Figma.