For a first app built with an AI tool, answer one Next.js app. Choose a separate frontend and backend only if something other than this one website needs to talk to the same server code, or if a second person will own the server side as their own project.
The reason is simple. Your app is almost certainly one website with a few pages, a login, a database, and one or two calls to an AI. Next.js can hold both halves of that in a single project: the pages people see, and the code that runs on a server where your secrets live. One project means one thing to deploy, one place to look when something breaks, and one set of files for your builder to keep straight. A split doubles all of that before you have a single user.
What your builder is really asking
Every web app has two halves. The frontend is what runs in the visitor’s browser: the screens, the buttons, the text they type. The backend is code that runs on a computer you control, out of the visitor’s reach. That is where your API key lives (the long secret string that lets your app call the AI), where the database is read and written, and where anything you do not want a stranger to see or change belongs.
The question is whether those two halves live in one project or two. Next.js, the framework Vercel maintains, describes itself as a React framework for full-stack web applications. In plain words, it lets you put your pages and your server code in the same folder, and it knows which is which. The server parts, which Next.js calls route handlers, are small pieces of code that answer requests from your pages and never get sent to the browser.
The other shape is two projects. The frontend is built with a tool like Vite, which describes itself as a build tool for modern web projects and only concerns itself with what runs in the browser. The backend is a separate program, in its own folder, with its own deploy, that the frontend talks to over the internet. Nothing is wrong with that shape. Large companies use it because different teams own different halves. It just costs more to run and to reason about, and for one person with one website there is nothing to buy with that cost.
The three things that flip the answer
First, more than one thing needs the same backend. If you are planning a phone app alongside the website, or a second website that shares the same accounts and data, a separate backend earns its keep. Both apps talk to one server, and you fix a bug once. A single Next.js project can still serve a phone app from its server code, so even this is a soft rule, but it is the moment a split starts to make sense.
Second, the backend needs to do something Next.js on Vercel is not built for. Work that runs for a long time without stopping, a live connection that stays open for hours, or a program written in another language because a library only exists there. If your builder names a specific need like that, ask it to say so plainly, and treat that as a real reason.
Third, someone else will own the server side. If a developer friend or a contractor is going to build and run the backend as their thing, a separate project gives them a clean boundary. Until that person exists, the boundary only gets in your way.
If none of those describe your app today, and they almost never do at the first-app stage, one project wins.
What a wrong pick costs you
Picking one Next.js app and later needing a split is cheap. The server code is already separated into its own files inside the project, so moving it out into its own backend is a relocation, not a rewrite. Your pages keep working and get pointed at the new address. I have watched this happen at exactly the moment a second app showed up, and it took an afternoon, not a month.
Picking a split too early costs you every day. Two deploys to keep in sync. Two sets of settings where the secrets go. A whole category of bugs where the frontend and backend disagree about the shape of a message, and the app breaks in a way that looks like nothing you did. Your builder spends credits on plumbing instead of features, and you spend evenings learning words like CORS, a browser rule about which sites may talk to which servers, that a single project would never have made you meet.
There is one cost that has nothing to do with the number of projects, and it is the one that matters. Whichever shape you choose, the AI key and the database must be on the server side, never in the pages. A single Next.js app makes this easy to get right because the server part is right there. Even so, it can still go wrong. If your builder ever puts the key in the frontend “just for now,” that is the thing to catch.
What to tell your builder
Paste this back:
“Keep it as one Next.js app, with the pages and the server code in the same project, and make sure every secret and every call to the AI runs on the server side, never in the browser.”
That is the whole decision. You do not need to name the database, the hosting, or the login service in the same breath. Each of those is its own fork, and each has its own plain answer.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 5, The Front Door and the Kitchen. The first lesson is free, no card.
In the next ten minutes, answer your builder with the sentence above and let it carry on. Then ask it one question in plain words: where does the AI key live right now, and can a visitor’s browser ever see it. If the answer is anything but “on the server, and no,” you have found the first real thing to fix, and it has nothing to do with how many projects you have.