Build an app, publish it on Vercel, and add it to your phone

Start with one useful job, not a wishlist. “A meal planner that saves five dinners” is buildable. “The next Instagram, but for food” is not a first version. Decide who it is for, what they put in, and the one result they should get back.

This guide uses Next.js + TypeScript because it works neatly with Vercel and has built-in support for a web app manifest. You can use Claude, ChatGPT, Codex, Cursor, or another coding assistant — the prompts are intentionally tool-agnostic.

Open an empty project folder in your coding tool. If it can create the project for you, use the prompt below. If you prefer the terminal, run npx create-next-app@latest my-app --typescript --eslint --app, then cd my-app and open that folder in your tool.

Build one complete flow before adding extras. Use real labels and sample content instead of lorem ipsum, and check the app at a phone-sized width as you go.

Run npm run dev, open the local URL, and use your browser’s responsive mode. Try the whole journey at roughly 390 × 844 pixels. Test blank fields, long text, a refresh, the back button, and the slow or failed path — not just the perfect demo.

Before publishing, run npm run build. A production build catches problems that the development screen can miss. Also make sure private keys live in .env.local and that the file is ignored by Git.

Before clicking anything, here is the whole system. Your project folder is the copy on your computer. Git keeps a history of that folder. GitHub stores a copy of the project and its history online. Vercel reads the GitHub copy, builds it, and publishes it as a website anyone with the link can open.

Repository (or repo) means the project on GitHub. A commit is a named checkpoint, like “the login screen now works.” A push uploads your new commits to GitHub. A deployment is Vercel turning one of those commits into a live website. Production is the version real visitors see.

So when someone says “push it to Vercel,” the beginner-friendly Git workflow is usually: save your work → commit it → push it to GitHub → Vercel notices the push → Vercel deploys it. You are not expected to manually upload the same files to two different places.

Create a GitHub account first. Then create a Vercel account using Continue with GitHub; this lets Vercel see only the repositories you authorize. Keep both browser tabs open for the next two steps.

Easiest route: use GitHub Desktop. Download GitHub Desktop, sign in, then choose File → Add Local Repository and select your app’s project folder — the folder containing package.json. If it says the folder is not a Git repository yet, choose the option to create one there.

Look at the list of changed files. Files such as node_modules, .next, and .env.local should not be included. At the bottom-left, write a short Summary such as Build first working version, then click Commit to main. This makes the first checkpoint on your computer; it is not online yet.

Click Publish repository. Give the repository a simple name with no spaces, such as meal-planner. Choose Private unless you deliberately want everyone to see the code, then publish it. When the button changes to Push origin, click it whenever you have new commits to upload.

If your coding tool has a “Connect to GitHub” or “Publish to GitHub” button, you can use that instead of GitHub Desktop. Check which GitHub account and repository it selected, and choose Private or Public intentionally before confirming.

Terminal route (optional): create a new empty repository on GitHub — do not add a README if the local project already has one. In the project folder run git init, git add -A, git commit -m "Build first working version", git branch -M main, git remote add origin YOUR_REPOSITORY_URL, then git push -u origin main. Copy the repository URL from GitHub; do not literally type YOUR_REPOSITORY_URL.

Refresh the repository page on GitHub. You should see familiar files and folders such as app, public, and package.json. You should not see .env.local. If a secret was uploaded, do not merely delete the file — replace or revoke that key as well, because it may already exist in Git history.

Go to your Vercel dashboard and choose Add New… → Project. You will see repositories from the GitHub account you connected. Find the repository you just published and click Import. If it is missing, use Vercel’s GitHub permissions link and allow access to that repository, then return to the list.

On Configure Project, most beginners should leave the detected settings alone. Check these four things: Project Name is the name Vercel will use in the first web address; Framework Preset says Next.js; Root Directory is the folder containing package.json; and the Build/Install settings say they were automatically detected. If package.json is at the top of the repository, the root directory is simply ./.

If the app has a local .env.local file, open it on your computer and look only at the names to the left of each equals sign. Under Environment Variables in Vercel, add each name and its real value. Environment variables are private settings such as API keys or database addresses. Never paste them into GitHub, a screenshot, or an AI chat.

Click Deploy. Vercel now installs the project’s packages, runs the production build, and publishes the result. This can take a few minutes. A successful deployment shows a congratulations/ready screen and a Visit button. Open it and copy the HTTPS address ending in .vercel.app — that is your live app. A custom domain can wait until later.

A Vercel project contains many deployments. Your newest successful deployment from main becomes Production. A change on another branch usually gets a separate Preview URL, which is useful for checking work without changing the public version.

For the quick-access experience you described, the essentials are a valid web app manifest, proper icons, and an HTTPS site. The manifest tells the phone your app’s name, icon, start page, colours, and that it should open in standalone mode without normal browser chrome.

In a Next.js App Router project, the clean route is app/manifest.ts plus 192 × 192 and 512 × 512 PNG icons in public, and an Apple touch icon. Use a simple, readable icon with padding around the artwork — tiny text disappears on a Home Screen.

A service worker is not required just to create the Home Screen shortcut. Add one only if you want offline pages, push notifications, or deliberate caching. A badly designed service worker can keep an old version of your app stuck on someone’s phone, so “more PWA” is not automatically better.

Run npm run build one more time, then git add -A, git commit -m "Make app installable as a PWA", and git push. Watch the new Vercel deployment until it says Ready.

Open the production URL on your phone — not localhost and not an old preview link. Check that the correct icon and app name appear, the first screen fits without sideways scrolling, and navigation still works after closing and reopening it.

On iPhone: open the live URL in Safari, tap Share, choose Add to Home Screen, turn on Open as Web App, then tap Add. The new icon launches the site in its own app-like window.

On Android: open the live URL in Chrome, tap the three-dot menu, choose Add to Home screen, then Install. The wording can vary slightly by phone and Chrome version.

If Install is missing, make sure you are on the final HTTPS URL, the latest Vercel deployment is live, and the manifest and icons load without errors. You can still create a plain Home Screen shortcut, but a correct manifest gives you the proper name, icon, and standalone window.

There is no app-store review for updates. The loop is always: change the code → test it → commit the checkpoint → push it to GitHub → wait for Vercel to say Ready. Vercel deploys the new version automatically; people opening the Home Screen icon receive the web update.

In GitHub Desktop, changed files appear on the left. Write a short Summary, click Commit to main, then Push origin. Open Vercel’s Deployments tab and wait for the matching commit to finish. If it fails, your previous successful production version normally remains available while you investigate the new build.

Use a preview branch for risky changes. Push the branch, open Vercel’s preview URL on your phone, and merge it into main only when it feels right. If you later add a service worker, test update behavior carefully because cached files can delay what users see.