For a first app built with an AI tool, answer Vercel. Choose your own server only if a part of your app has to keep running between visits, or if you are already paying for a server that someone knows how to look after.
The reason is who built what. Vercel is the company that maintains Next.js, the framework most AI builders reach for when you ask for a web app with a backend. Deploying a Next.js app to Vercel needs no configuration: you connect the folder on GitHub where your code lives, Vercel recognises it, and from then on every change your builder pushes becomes a new live version at a real address. Your own server is a computer you rent and are responsible for. Everything Vercel does for you, from installing the pieces to keeping the machine patched and restarting the app when it falls over, becomes a chore you own. A first app has enough chores.
What each option actually is
Vercel is a hosting platform. You do not see a computer. You see your project, its live address, and a list of versions. Underneath, your app’s backend runs as short-lived workers: when a request arrives, one wakes, answers, and disappears. That is why there is nothing to keep running and nothing to restart, and it is also the single limitation to remember, because a worker that disappears cannot keep a file it wrote or a task it was halfway through. The free plan, called Hobby, is for personal and non-commercial use; a business needs its paid plan.
Your own server means a virtual machine you rent from a provider such as DigitalOcean, which calls them Droplets, or one of Oracle Cloud’s always-free machines. It is a blank Linux computer on the internet. Your builder installs the runtime, copies the app over, starts it, and it runs all day whether anyone visits or not. That constant running is the whole appeal, and the whole cost: security updates, disk filling up, the app crashing at 3am with nobody to restart it, and a web address that only works once you have set up the certificate that makes the padlock appear.
There is a middle road worth naming, because your builder may offer it. Services such as Render and Railway run an always-on app for you without giving you a machine to manage. Render’s free web services go to sleep after fifteen minutes with no visitors and take about a minute to wake, which is fine for a demo and awkward for a launch. Railway has a small free allowance and bills by what the app uses. These are where you go when Vercel’s model stops fitting and you still do not want a machine.
Why Vercel is the right first answer
A first app’s job is to get in front of people quickly and change often. Vercel turns “publish the new version” into a push your builder already does, gives every version its own preview address, and lets you roll back with a click when a change breaks something. Nothing about the machine can go wrong, because there is no machine.
It also makes your builder’s job smaller. On your own server, every request for a change carries a hidden second request: “and make sure it still starts, and stays up, and the certificate still renews.” On Vercel those are not your problem, so the builder’s mistakes stay in your app rather than spreading to the computer under it.
The three things that flip the answer
Something has to keep running between visits. A chat that holds a live connection open, a bot that watches a feed all day, a report that takes twenty minutes to build. Short-lived workers cannot do those, and stretching them to try is where first apps get strange. If your app has one of these at its core, answer your own server or one of the middle-road hosts, and tell your builder which piece is the reason.
You are selling from day one. Vercel’s free plan is for non-commercial use, so a business either pays for its plan or runs elsewhere. The paid plan is still the least work by a wide margin, so this flips the answer only when money is tighter than time.
You already have a server and a person for it. An existing machine with someone who patches it, or a team that already runs everything one way, is a good reason to stay. The point of Vercel is to spare you that role, not to replace someone who already fills it.
What a wrong pick costs you
Picking Vercel and outgrowing it costs an afternoon. Next.js is built to run on an ordinary server too, so your builder packages the app, starts it on the machine, and points your domain at it. The only pieces that need rethinking are the ones that leaned on Vercel’s conveniences, such as image handling and the way it runs background work.
Picking your own server too early costs you evenings, spread out over months. A machine nobody is watching drifts: an update that was never applied, a disk that quietly fills, an app that died at night and stayed dead until a user emailed. None of those are dramatic and every one of them lands on you. There is also a quieter cost: on a server, your builder writes files to disk because it can, and that habit has to be unlearned later when you move, because the file was never the right home for saved data anyway.
What to tell your builder
“Deploy to Vercel from my GitHub repository, and tell me first if any part of the app needs a server that keeps running between requests.”
That second half is the whole check. If your builder answers “yes, this piece”, you have found the flip, and you can decide with a name in hand instead of a hunch.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 9, It Lives on the Internet. The first lesson is free, no card.
In the next ten minutes, ask your builder one question in plain words: does anything in this app have to keep running when nobody is using it? If it says no, paste the sentence above back and let it deploy. If it names a piece, ask whether that piece could be triggered when needed instead of running all the time. Most first apps hear “yes” to that, and Vercel is back on the table.