Build a Full-Stack App With GitHub Copilot: FastAPI, React and Next.js From Scratch

This guide walks through building a full-stack app with GitHub Copilot as your pair programmer. It covers project setup and a FastAPI plus React or Next.js monorepo, how frontend and backend connect through an API, how much frontend you really need to know, extending an inherited frontend, the Copilot instructions file and the day-to-day workflow.

GitHub Copilot has grown from an autocomplete into an agent that can scaffold a whole full-stack project, front-end and back-end, if you prepare it well. This guide walks you through the tools to install, how to plan the app, how to turn that plan into context Copilot follows, and the order to scaffold in. It then applies the workflow to a real example, a Kanban board with drag and drop, and extends it with an AI chat assistant that knows the board.

Why planning comes before scaffolding

The temptation with Copilot is to jump straight to generating code. When you ask an agent to build with no clear target, it invents structure and makes choices you did not intend, which leaves you with code you do not understand. Planning first gives the agent direction and gives you a blueprint to review against.

The time spent planning is small, and it saves far more time untangling later. Decide the shape before the agent pours the concrete.

Tools to install before Copilot builds anything

Start with a clean toolchain. You need VS Code with the GitHub Copilot extension enabled, the runtimes your stack needs (Node for the front-end and Python for a FastAPI back-end), and Git for version control. Getting these in place mirrors any solid get-started setup, and it means Copilot can actually run and test what it builds. Set up the tools before you ask the agent to build.

Planning the app: purpose, stack, structure, data and API

Define what the app does

Write down what the application should do, its core features, its users and what success looks like. This functional picture comes before any technology choice and keeps the project focused on value rather than tech for its own sake.

Choose the stack deliberately

With the purpose clear, pick the back-end framework, such as FastAPI, the front-end framework and the database. Deciding this yourself gives the agent a concrete stack instead of letting it pick arbitrarily. A mainstream stack that agents know well makes the scaffolding more reliable, and the stack decision shapes everything Copilot generates afterwards.

Sketch the folder structure and the data model

Decide how the project is organized: a backend folder and a frontend folder at the root of one repository. This single-repo layout keeps the whole project together, is easy to version and share, and is the arrangement most agents handle well, as covered in structuring a FastAPI and React monorepo.

Then plan the data. Decide which main entities the app stores and which fields they have, because these models are shared by the back-end and the database and they shape the API too. Everything in the app ultimately reads and writes this data, so a clear model keeps the whole project coherent.

Outline the API contract

Finally, list the endpoints the front-end will need and what each one reads or writes. This defines the contract between the two halves before either is built, so they fit together instead of drifting apart. The API is the seam of a full-stack app, which is why it deserves deliberate design.

Turn the plan into a context file Copilot reads

A plan in a separate document is easy for the agent to ignore. Write your stack, structure, commands, data model, API and coding standards into a custom instructions file that follows the agents.md conventions. Copilot then applies them on every request instead of guessing. That is what turns generic output into code that fits your project.

This file is the bridge between planning and building, and it pairs naturally with a good planning prompt. A well-written context file is the single biggest lever on Copilot’s output quality. Set it up early so it guides every later request.

Create the repository and scaffold the back-end first

Initialize a fresh Git repository as the home for both halves, together with the config. Committing early and often gives you checkpoints throughout the build, so every step the agent takes is saved and reversible.

Scaffold the back-end before the front-end, since the interface depends on it. Ask Copilot to create a FastAPI application with the structure and models from your plan plus a basic health endpoint. Because FastAPI is well known, Copilot produces reliable scaffolding quickly, and because you planned the structure, the result comes out organized rather than arbitrary. Review what it generates before moving on, to confirm the agent followed the plan. A running back-end skeleton is the right first milestone.

Scaffold the front-end and review the skeleton

Next, ask Copilot to create your chosen front-end framework, a React or Next.js app, with a basic page and the structure your plan specified. Keep it minimal at first so it is easy to check and extend. Because both halves follow the same plan, they fit together by design rather than needing to be reconciled later.

Before adding any features, read the generated structure and code and confirm it matches your intent. Catching divergence now, while the project is small, is far cheaper than fixing it after features pile up.

Then wire the two halves together. Have Copilot connect the front-end’s calls to the back-end’s API, start both locally and confirm they talk to each other. A running app with both halves communicating is the payoff of the setup, and from there you build features one at a time.

Worked example: a full-stack Kanban app

Why a Kanban board makes a good Copilot project

A Kanban board, columns of cards you drag between stages, exercises the whole stack. It needs data, an API to manage it, an interactive interface with drag and drop, and storage so the board persists. That makes it concrete enough to finish and rich enough to teach real full-stack skills, which is why it is a popular learning project.

Plan the features and design the data model

Plan the features first: a board with columns, cards you can create and move, and saved state. The heart of the app is its data, so define boards that contain columns and columns that contain ordered cards. Have Copilot help design these entities and their relationships, then review them. This structure is the backbone that the endpoints and the UI are built on.

Build the API endpoint by endpoint

Scaffold the FastAPI back-end with those models, then add the endpoints the board needs: create boards, add columns, create cards and move cards between columns. Add them one at a time, reviewing and testing each, until all of the board’s operations are supported.

Build the board interface and add drag and drop

Scaffold a React front-end with a basic page, then have Copilot create the board, column and card components and fetch them from your API. Confirm each component renders your real data correctly.

Drag and drop is the signature Kanban interaction and the trickiest front-end piece. Ask Copilot to add it so that moving a card updates its column, and make sure that each drop calls the API to save the new position. Build it deliberately and test the moves, because this is the feature that turns a static display into a real Kanban board.

Persist state through the back-end

Every action, creating a card or moving one, should call the back-end and persist to the database. That is what lets the board survive a refresh and what separates a real app from a demo. Persisting through the back-end rather than only in the browser makes the state durable.

Adding an AI chat assistant to the Kanban board

A Kanban board combined with an AI chat assistant is a natural step up. The app gets two connected parts: the board you build normally and a chat feature backed by a language model that can discuss or act on the board. Plan both features together, deciding what the assistant should do, such as answering questions about the board or creating and moving cards on request. Then build the board first, since the assistant needs a real, persistent board to act on, following the usual front-end to back-end wiring.

Add a chat endpoint and wire it to a model

With the board working, have Copilot add an endpoint that takes a user message and calls a language model, sitting alongside the board endpoints in your existing REST API. The endpoint can call OpenRouter or a similar provider, sending the message and returning the model’s reply. A unified provider lets you swap models as you tune the assistant. Routing the call through your back-end keeps the API key off the browser.

Put the chat panel beside the board

On the front-end, add a chat panel next to the Kanban board, with a message list and an input that post to the chat endpoint. Keeping it beside the board makes the two features feel like one app rather than two disconnected pieces.

Give the assistant board context

The assistant becomes useful when it knows the board. Pass the current board state into the model’s context, or let the assistant query it, so it can answer questions about your cards and columns instead of acting like a generic chatbot. This grounding is the most interesting part of the build. With it, the assistant can summarize the board, suggest what to work on next, and create or move cards on request by calling your board endpoints. Review anything that changes the board so the assistant stays safe as well as helpful.

The review, test and commit loop that keeps it maintainable

Read everything Copilot generates before accepting it, front-end or back-end. Understanding each change catches bugs and bad patterns early and keeps you the owner of the code, while skipping review is how a fast start becomes an unmaintainable tangle.

Test each piece and commit after each working step, so you always have a safe point to return to, as in a real full-stack workflow. For the chat version, keep the model API key on the back-end and never in the browser, and test the board and the chat alike. Copilot supplies the speed, and this loop is what turns that speed into an app you understand and can maintain.

What’s the Best Way to Structure a FastAPI Backend With a React/Next.js Frontend in a Single Repository?

A common question when building full-stack is whether to keep the FastAPI back-end and the React or Next.js front-end in one repository or two. For most projects, especially solo or AI-assisted ones, a single repository is simpler, as long as it is structured well. A clean layout keeps the two halves separate but together, easy to build and reason about. Here is the best way to structure a FastAPI back-end with a React or Next.js front-end in one repo.

Why a single repository

Keeping both halves in one repo, a monorepo, has real advantages for a full-stack app. You version the whole project together, so a change spanning front-end and back-end is one coherent commit, and there is one place to clone, one history, and one setup. For a project built by one person or an agent, this simplicity outweighs the separation of two repos. A single repo keeps the front-end and back-end in step. It is the pragmatic default for full-stack building.

The top-level layout

The core of a good structure is a clear top-level split. A backend folder and a frontend folder at the repository root immediately signal where each half lives, keeping their code, dependencies, and config from tangling. Anyone, human or agent, can see the shape of the project at a glance. This simple two-folder division is the backbone of the layout. Everything else hangs off it. Two clearly named folders at the root are the foundation of a clean monorepo.

Inside the back-end folder

The backend folder holds a self-contained FastAPI application. Inside, you keep the app code, the API routes, the data models, the database logic, and the back-end’s own dependency file, so it could almost stand alone. Organizing the back-end internally, routes here, models there, keeps it maintainable as it grows. The folder is the back-end’s whole world. Keeping it self-contained means the back-end has everything it needs in one place. A well-organized back-end folder is half of a clean structure.

Shared configuration at the root

Some things belong at the repository root, above both folders. A top-level README, a gitignore, a Docker Compose file, and project-wide config sit at the root because they concern the whole project, not one half. Keeping shared, project-level files here and half-specific files inside each folder is the organizing principle. The root is for what spans both halves. This keeps the two folders focused while the whole project’s setup lives above them. Root for shared, folders for specific, is the rule.

Front-End, Back-End and APIs: How the Parts of a Web App Work Together

Every web app is two halves working together: a front-end that users see and click, and a back-end that stores the data and runs the logic behind the scenes. The API is the bridge between them. This guide explains what lives in each half, how they talk through HTTP, REST and JSON, why the split keeps apps secure and maintainable, and how the same pattern lets you wire in AI features and direct AI coding tools to build both halves.

What the front-end is

The front-end is everything that runs in the user’s browser: the layout, the buttons, the text, the forms and the interactions. It is built with HTML, CSS and JavaScript, often through a framework like React.

Its job is to present information and capture what the user does, then send that to the back-end. It is the face of the app. If you can see it or click it, it is the front-end.

What the back-end is

The back-end is everything the user does not see: the server, the application logic and the database. It receives requests from the front-end, does the real work, such as checking a password, saving a record or running a calculation, and sends back a response. It is often built in a language like Python with a framework like FastAPI, and it is where the data and the rules live.

The database behind the back-end

Behind the back-end sits the database, where the app’s data actually persists. When the back-end needs to save or retrieve a user, a post or an order, it talks to the database, which stores everything durably between sessions.

The database is invisible to the front-end. It is the app’s long-term memory, so without it nothing would be remembered after you close the page. The back-end is its gatekeeper.

A restaurant analogy for the two halves

Think of a restaurant. The front-end is the dining room: the menu, the tables and the waiter you talk to. The back-end is the kitchen where the food is made, with the pantry where ingredients are stored. You never enter the kitchen, but every dish comes from it, and the waiter carries your order back and the food forward. That carrying is exactly what an API does.

What an API is: the contract between the halves

API stands for application programming interface, but the useful way to think of it is as a menu of things the back-end can do. It defines the requests the front-end can make, such as get this user or save this post, and what it will get back. The API is the set of doors into the back-end, and only those doors.

The most important idea is that an API is a contract. It specifies exactly how to ask for something and what the answer will look like, so the front-end and back-end can be built separately as long as both honor it. Either side can change internally without breaking the other, provided the API stays stable. That is what lets teams and tools work independently. Agree on the API, and the halves fit together.

What Are React, Next.js, and Other Popular Front-End Frameworks Used in AI-Assisted Development?

When you build the visible half of a web app, you rarely start from raw HTML and JavaScript. Instead you use a front-end framework, and the names you will meet most are React, Next.js, and a handful of others. These frameworks structure how the front-end is built, and AI coding tools are especially fluent in them. Here is what React, Next.js, and other popular front-end frameworks are, how they differ, and why they matter so much in AI-assisted development.

What a framework is

A front-end framework is a structured toolkit for building user interfaces. Instead of manually wiring up every piece of HTML and JavaScript, a framework gives you patterns and tools to build interfaces faster and more reliably, handling the tedious parts. It is the difference between building a house from raw lumber and using a proven kit. Frameworks are how professional front-ends are actually built. They provide the structure so you focus on your app, not the plumbing.

React, the dominant library

The most popular of all is React, a library for building user interfaces out of reusable components. React lets you describe what the interface should look like for a given state, and it efficiently updates the page as that state changes. Its huge ecosystem and popularity make it the default choice for many front-ends. React is the foundation much of the modern web is built on. If you learn one front-end framework, it is usually React.

Next.js, React with batteries

Built on top of React, Next.js adds the structure a full app needs: routing between pages, server-side rendering, and a clear project layout. It takes React from a UI library to a complete framework for building production websites and apps. Next.js is a frequent choice for AI-built projects because it is powerful, well-documented, and agents know it deeply. It is React plus everything else you need. For full apps, Next.js is often the sensible default.

Vue, Svelte, and others

React is not the only option. Vue offers a gentler learning curve, Svelte compiles away much of the framework overhead for speed, and others each have their fans and strengths. They solve the same problem, structuring the front-end, with different trade-offs in style and performance. Knowing they exist keeps you from thinking React is the only way. The ecosystem is rich, though React and Next.js dominate. The right one depends on the project and your preference.

Do You Actually Need to Know Front-End Coding to Build Complex Apps in Minutes Using AI?

One of the most exciting promises of AI coding is that you can build a complex app in minutes by describing it, even a slick front end, without writing the code yourself. This raises a genuine question for beginners and non-front-end developers: do you still need to know front-end coding at all? The honest answer is that AI dramatically lowers the barrier but does not remove it entirely. Understanding exactly where the line falls is what lets you build confidently without being blindsided.

What AI genuinely lets you do without it

For a large class of work, AI really does let you build without deep front-end knowledge. Describing a layout, a form, or an interactive component and having an agent generate working code is entirely feasible, and for prototypes and simple apps it can be enough on its own. This is the real democratizing power of AI coding, opening building to people who could not have done it before. For getting an idea onto the screen, you can go remarkably far without writing front-end code yourself. The barrier to a first working version has genuinely dropped.

Prototypes are where it shines most

The lower your stakes, the less front-end knowledge you need. For a prototype, a demo, or a personal project, pure vibe coding where you accept what works can carry you to a functional result without understanding the underlying code. Here the goal is to see the idea work, not to maintain a codebase, so gaps in your knowledge rarely bite. This is the natural home of building without traditional skills. When it is disposable, understanding matters far less.

Where a lack of knowledge starts to bite

The trouble begins when something goes wrong or needs to grow. If the AI produces a bug, an odd layout, or behavior you did not want, fixing it is much harder if you cannot read the code well enough to know what is happening. Without front-end understanding, you are dependent on the agent to solve every problem, and when it cannot, you are stuck. This is where the promise of no knowledge needed quietly breaks down. Building is easy, and repairing is where skill returns.

Reviewing requires understanding

Even when the AI works well, you cannot truly review what you cannot understand. Accepting front-end code you do not follow means trusting it blindly, which quietly accumulates fragile, mysterious parts you cannot judge for quality or security. The accountability for what you ship does not transfer to the AI just because it wrote the code. This is the same reason a language model producing plausible output still needs a human check. You can only be responsible for what you understand.

How Can a Complete Beginner Learn Front-End Coding by Having an AI Agent Explain Its Own Work?

A complete beginner has a remarkable learning tool available: an AI agent that will write front-end code and then explain every line of it, patiently and on demand. Instead of just accepting the code, you can ask why each piece exists, what it does, and how it fits, turning the agent into a tutor that never tires of questions. Here is how a beginner can learn front-end coding by having an AI agent explain its own work, and how to avoid the trap of passive copying.

The AI-as-tutor idea

The insight is that an agent is not just a code generator, it is an explainer. It can produce a working front-end and then teach you how that front-end works, adapting to your questions at any level, which no static tutorial can do. For a beginner, this combination of real code plus tailored explanation is a uniquely effective way to learn. The agent answers the questions a book cannot. Treating it as a patient teacher, not just a producer, is the key shift. Learning, not just building, is the goal.

Start with a small project

Learning works best with something concrete. Asking the agent to build a small front-end, a simple page, a button that does something, a basic layout, gives you real, understandable code to learn from in an editor like VS Code rather than abstract theory. A small scope keeps the code readable and the concepts manageable, following the same get-started habits that ease any beginning. Start tiny and grow. A small working project is a better teacher than a large confusing one. Build something little you can fully understand.

Ask it to explain every line

The core practice is simple: ask for explanations. After the agent writes code, have it walk through each line, what this tag does, why this style is here, what this function accomplishes, so you understand the whole thing rather than a black box. Asking line by line is how the code becomes a lesson. Never accept front-end code you cannot explain back. The explanation is where the learning happens. Make asking why a habit after every piece of generated code.

Ask why, not just what

Go beyond what the code does to why it is written that way. Asking why this approach over another, what problem this pattern solves, and what would happen without it builds real understanding, drawing on the agent’s step-by-step reasoning. The why is what transfers to your next project, while the what is just this one. Push for the reasoning behind the code. Understanding the purpose, not just the syntax, is what makes you a coder rather than a copier. Always ask the deeper question.

How Do You Inherit an Existing Frontend Codebase and Extend It Into a Complete Full-Stack App With AI Tools?

A common situation is having a front-end, a design, a prototype, a handed-over codebase, with no back-end behind it. Turning that into a working product means building the server, the database, and the connection, and AI tools make extending an inherited front-end into a full-stack app very doable. The key is understanding what exists before building onto it. Here is how to inherit an existing front-end codebase and extend it into a complete full-stack app with AI tools.

The common scenario

This situation comes up constantly. You might have a front-end built by a designer, generated from a template, or inherited from someone else, and it looks right but does nothing real because there is no back-end to store data or run logic. Extending it means adding the missing half. Recognizing that you have a front-end shell needing a back-end frames the whole task. The front-end is the starting point, not the finished app. Understanding the scenario is the first step to completing it.

Understand the existing code first

Before building anything, understand what you inherited. Reading through the front-end to see how it is structured, what framework it uses, and what data it expects is essential, because you are extending it, not replacing it. Rushing to add a back-end without understanding the front-end leads to a mismatch. Taking time to learn the existing code is what makes the extension fit. Know what you have before you build onto it. Understanding the inherited front-end is the foundation of extending it well.

Let AI map the codebase

AI tools are excellent at helping you understand inherited code. Asking an agent to explain the front-end’s structure, how its pieces fit, and what data it seems to need turns an unfamiliar codebase into something you grasp quickly. This is one of the best uses of an AI agent on an existing project, documenting and explaining it. Letting AI map the code accelerates your understanding enormously. Use the agent as a guide to the inherited front-end. A quick AI-assisted tour reveals what the front-end expects from a back-end.

Identify the API the front-end expects

The crucial clue is what API the front-end is trying to call. Front-ends usually assume a back-end with certain endpoints and data shapes, so finding those calls, or where data would be fetched, tells you exactly what back-end to build. The front-end effectively specifies the API it needs. Identifying that expected contract is what lets you build a back-end that fits without changing the front-end. Let the front-end tell you what the back-end must provide. Its data needs are the blueprint for the server.

Can an AI Coding Agent Build a Full Kanban App From One Instructions File or Prompt?

A good way to test any coding agent is to hand it one clear brief and ask it to build a complete app, then see how far it gets on its own. This article looks at two versions of that test with a Kanban board as the target: GitHub Copilot’s agent working from a single instructions file, and an agent like Codex building from a single zero-shot prompt. The short answer is largely yes, with important caveats. You will see where the agents succeed, where they struggle, and how to set up the brief, the tool and the review so the result is usable.

Why a Kanban board is a fair benchmark for coding agents

A Kanban board, with its columns, draggable cards and saved state, hits a useful sweet spot for testing an agent. It has clear, familiar requirements, several interacting features and a visible result you can judge immediately.

That makes it demanding without being ambiguous, exactly the kind of clear, verifiable task where agents tend to do well. It is complex enough to be a real test and defined enough to be a fair one. A todo app would be too trivial, and a novel system too fuzzy.

Two ways to run the test: an instructions file or a zero-shot prompt

The single instructions file

In the first approach, all your requirements go into one instructions file: what the app should do, the features it needs, the conventions to follow and how to run it. It is essentially a detailed agents.md style file scoped to this one project. The file is the whole input and the app is the whole output, though you can still iterate on the result afterwards.

Zero-shot prompting

Zero-shot is the stricter version. The agent gets one prompt, no worked examples to learn from and, in this test, no back-and-forth iteration. You describe the whole app once and judge only the final result. This is much harder than conversational building, where you refine as you go, and its value is in showing how far raw autonomy reaches. One prompt in, a whole app out, with no safety net.

What the agent does with the brief

Given a good brief, the agent works through it methodically, executing your spec step by step. Copilot’s agent scaffolds the project, creates the files, implements the columns and cards, wires up the interactions and adds the saving behavior, all while you watch. With a single zero-shot prompt, an agent like Codex works through the whole thing autonomously in the same way: it plans the structure, creates the files, builds the board and adds persistence from that one instruction. Both are running the same kind of build loop.

Seeing a working board emerge from a single brief is genuinely impressive. The agent is running a full build loop on your description, turning a spec into a running app without hand-holding. This is autonomy doing real, visible work, and it shows how much an agent can execute when the target is clear.

Where the agent succeeds

For the conventional parts of the app, both approaches work well. Rendering columns, creating cards and basic interactions are common patterns the agent has seen many times, so it implements them competently. The clearer and more standard the requirement, the more reliably the agent gets it right, and most of a typical Kanban board falls into this well-trodden territory. This is the heart of why agents excel at familiar, verifiable work.

What Does a Real Development Workflow Look Like When Combining FastAPI, React, and AI-Assisted Coding?

Knowing the tools is one thing, but what does a day of building with FastAPI, React, and an AI agent actually look like? The real workflow has a rhythm: plan the feature, build the back-end, build the front-end, connect them, and review, test, and commit throughout. It is less about any single tool and more about the loop you run across the full-stack. Here is what a real development workflow looks like when combining FastAPI, React, and AI-assisted coding, day to day.

The setup

The workflow assumes a working setup: a repo with a FastAPI back-end and a React front-end, the agent, in Copilot or a similar tool, ready in your editor, and Docker or local servers to run both halves. With the project structured and the tools in place, you are ready to build features rather than fight configuration. A solid starting setup is what makes the daily workflow smooth. Everything else assumes this foundation is in place. Get the environment right once, then work in it repeatedly.

Start with a plan

Each feature starts with a quick plan, not a prompt to build. Deciding what the feature needs, an endpoint or two on the back-end, some components on the front-end, and how they connect, gives the agent a target and you a blueprint. This small planning step, even just a few lines, keeps the feature coherent across both halves. Planning before building is the first beat of the rhythm. A moment of planning shapes the whole feature. Know what you are building before the agent starts.

Build the back-end first

With a plan, you build the back-end before the front-end, since the front-end will depend on it. Having the agent add the FastAPI endpoints the feature needs, with their data handling, gives the front-end something real to call. Reviewing and testing each endpoint as you go keeps the back-end sound. Building the server side first means the API is ready when the front-end needs it. Back-end first is the natural order. Get the data and logic working before building the interface on top.

Then build the front-end

With the endpoints ready, you build the front-end to use them. Having the agent create the React components the feature needs and wire them to the back-end’s endpoints brings the feature to life visually. Reviewing the components and checking they call the API correctly keeps the front-end aligned with the back-end you just built. The front-end is built against a real, working server, not a guess. Building the interface second means it connects to something that already works. Front-end follows back-end in the rhythm.

Related guides
Build a FastAPI Backend With AI: REST API, Authentication and a Persistent Database
Docker for AI-Built Apps: Containers Explained, First Project and Production
GitHub Copilot in VS Code: Setup, Plan vs Agent Mode and Free Tier Limits

Common questions