Build Your PM Portfolio. No Coding Required.

Before you open an AI tool, it helps to be clear about what you are making and who it is for. A portfolio website is not a longer resume. It is a small, focused site that shows how you think about products, what you have worked on, and how someone can reach you.

By the end of this chapter you will have a rough list of sections, which is the starting point for Chapter 2.

Product management is hard to judge from a job title. Two people with the same title can have done very different work, and a resume rarely has room to explain the reasoning behind a decision. A portfolio gives you that room.

• It shows how you think, not just where you worked. A short case study can walk a reader through a problem, the options you weighed, and why you chose one. That is the core of PM work, and it is what interviewers try to uncover anyway.
• It gives people one link. Recruiters and hiring managers can see your background, projects, resume, and contact details in one place instead of piecing them together from several sites.
• It demonstrates initiative and taste. Choosing what to include, writing it clearly, and publishing it is itself a small product. A tidy, well-structured site signals that you care about the details users notice.

A portfolio will not replace your resume or your network, and it does not guarantee interviews. It is a supporting asset: something you can share with confidence when someone asks what you have done.

Whatever sections you choose, a reader should come away with clear answers to four questions:

1. Which problems did you choose to work on, and why? Show that you can spot a problem worth solving and explain who had it.
2. How do you make decisions? Describe the trade-offs, the evidence you used, and what you decided not to do.
3. What happened, and what did you learn? Share real outcomes, including the ones that did not go to plan. Honest reflection is more convincing than a perfect record.
4. How do you work with people? PMs work through engineers, designers, and stakeholders. Mention how you collaborated, aligned people, or handled disagreement.

This guide is based on the workflow behind adityagangwani.me, the site you are reading it on. It is fine to look at that site, or any portfolio you admire, to understand how it is structured. Notice the order of the sections, what question each one answers, and how much text sits on each page.

Do not copy the wording, the visual design, or any claims. Your portfolio only works if it describes your own experience in your own voice. A useful exercise is to write down, for each section of a site you like, one sentence on what it is trying to tell the reader. Then ask whether you need that section at all.

These four formats overlap, so it is easy to end up with a website that simply repeats your resume. The table shows what each one is best at.

In practice, your portfolio links to the other three: it hosts your case studies, offers your resume as a download, and links to your LinkedIn profile.

Here are the sections most PM portfolios draw from. You do not need all of them. Read the “include it if” line for each and keep the ones that fit.

The right set of sections depends on what you want the site to do. A few common starting points:

• Applying for your first PM role: hero, about, projects and case studies, product thinking, education, contact.
• Experienced PM changing companies: hero, experience, two or three strong case studies, skills, contact.
• Switching into product from another field: hero, about (explain the switch), projects, transferable experience, contact.

Fewer, stronger sections beat a long page of thin ones. You can always add more later, because updating it is a commit and a push once it is set up.

With a rough list of sections in mind, the next step is to gather the actual content and assets that will fill them.

AI tools are good at turning material into a website. They are not good at knowing your career. If you start with a vague request, you get a generic site full of guesses. If you start with real content, you get a site that sounds like you.

This chapter is about collecting that content before you build anything. Plan for an hour or two, spread over a couple of sittings. It is the part of the process that most affects how good your portfolio is.

Create a folder on your computer called something like portfolio-content and a single text document inside it for your notes. Work through the list below. Rough notes are fine; you will refine them with the discovery prompt later in this chapter.

A case study is a short story about one project that shows your thinking. You do not need a fancy format. This simple structure works for most projects:

1. Context: the product, the team, and the situation, in two or three sentences.
2. Problem: what was wrong or missing, and for whom.
3. Your role: what you were responsible for, and who you worked with.
4. Options and decision: what you considered, what you chose, and why.
5. What shipped: what was actually built or changed.
6. Outcome: what happened as a result.
7. What you learned: what you would keep or do differently.

Use real outcomes. If you have numbers you are allowed to share, use them exactly. If you can only share an approximate figure, say that it is approximate and where it comes from (for example, “roughly a third fewer support tickets in the quarter after launch, based on the support team’s weekly reports”). If you have no number, use a qualitative result (“the sales team stopped asking for manual exports”).

• Resume: export it as a PDF with a clear filename, such as firstname-lastname-resume.pdf, so it looks tidy when someone downloads it. Remove your home address and anything else you would not want published on the open web.
• Profile photo: use a square, high-resolution image with good light and a plain background. A square image is easiest to crop into a circle or card.
• Images and screenshots: only use images you own or have permission to use. Product screenshots from a past employer may be confidential; check before publishing, or create a simple diagram instead.

Put all of these files in your portfolio-content folder so they are easy to find later.

Your notes are now the raw material. The next step is to shape them into a plan: what you will say, in what order, and how the site should feel. An AI chat assistant can help by interviewing you, the way a good career coach would.

Copy the prompt below into a new chat. The AI will ask you questions a few at a time. Answer them using your notes, and paste in sections of your notes when that is quicker. The prompt tells the AI not to invent anything and not to write code yet, so the result is a plan built only from your real information.

You are a portfolio strategist helping me plan a personal portfolio website for a product management career. Your job right now is discovery: interview me, then turn my answers into a clear plan. Do not write any website code yet.

HOW TO INTERVIEW ME
1. Ask your questions in small batches of 3 to 5, and wait for my answers before moving on.
2. Cover these topics, in roughly this order:
   - My background: education, roles, and how I got into product
   - My goals: what I want this website to help me achieve
   - My target roles and audience: who will read the site
   - My projects: for each one, the problem, my role, key decisions, approach, and outcome
   - My strengths and skills, and the tools I use
   - My links and assets: resume, LinkedIn, GitHub, photo, other work
   - My preferred visual style, including 2 or 3 websites I like and why
3. If an answer is vague, ask a short follow-up question instead of guessing.

RULES
1. Do not invent experience, achievements, metrics, employers, job titles, dates, or outcomes. Use only what I tell you.
2. If something is missing, ask me. If I cannot answer, write "[needs input]" in that place.
3. If I give a number, keep it exactly as I gave it. If I describe a result without a number, keep it qualitative.
4. Flag anything that sounds confidential (internal names, revenue, unreleased features) so I can anonymise it.
5. Do not generate website code or a full site design until discovery is finished and I confirm the plan.

WHEN DISCOVERY IS DONE, give me:
1. Positioning statement: 2 or 3 options of one or two sentences each.
2. Proposed sitemap: the sections or pages, in order, with one line on what each one is for.
3. Content outline per section, using only facts I provided.
4. Asset checklist: what I already have and what is still missing.
5. Design direction: tone, typography, colour, and layout, with reference sites.

Format everything as one Markdown document I can save as portfolio-brief.md.

Start by briefly explaining how this will work, then ask your first batch of questions.

When the AI delivers its plan, read it carefully before you accept it.

• Check every fact. Correct anything that is wrong or that the AI added on its own.
• Fill in each “[needs input]” gap, or remove that part of the outline.
• Pick one positioning statement, or combine the options into one you like.

Then save the final version as a document called portfolio-brief.md in your portfolio-content folder. The .md ending means Markdown, a plain text format that uses simple symbols such as # for headings. Any text editor can open it. You will paste this brief into your AI coding tool in Chapter 3.

You now have a portfolio brief. You do not need to know how to code to turn it into a website, but you do need to give clear instructions, review what the tool produces, and ask for specific changes.

The workflow below works with Google Antigravity, Claude Code, or another tool you prefer. No single tool is required.

An AI coding tool is an assistant that writes and edits code from instructions in plain English. You describe what you want, the tool writes the files, and you review the result. For a portfolio, that means the pages, the styling, and the small bits of behaviour such as a mobile menu.

The tool is fast, but it is not the author of your portfolio. It cannot know your career, and it can make mistakes. Your job is to supply accurate content, judge the result, and steer it.

AI tools come in two broad shapes. A coding agent works directly in a folder on your computer (or in a project the tool hosts for you): it creates and edits files, runs commands, and can often start a preview. A chat interface only replies with text, so you copy code into files yourself.

For building the site, use a coding agent. A chat interface is still useful for planning, which is why the discovery prompt in Chapter 2 works in any chat AI.

Plans and features change often, so treat the details below as a summary at the time of writing and check each tool’s official page before you sign up. Some tools offer a free tier with usage limits; others need a paid plan.

Google Antigravity (opens in a new tab) describes itself as an agentic development platform. It is available as an app, a command-line tool, and an IDE (a code editor), on macOS, Windows, and Linux. The Antigravity IDE (opens in a new tab) can work across the editor, the terminal, and a browser, which suits a build-and-preview workflow.

At the time of writing, the pricing page (opens in a new tab) lists a plan for individuals at no charge with basic weekly rate limits, meaning you can only use it so much each week. Google AI Pro and Ultra plans raise those limits. See the plans documentation (opens in a new tab) for current details, and the getting started guide (opens in a new tab) to install it.

This site was built mainly with Antigravity, with occasional help from Claude.

Claude Code (opens in a new tab) is Anthropic’s AI coding assistant. You can use it in a terminal, through extensions for editors such as VS Code and JetBrains IDEs, in a desktop app, or on the web.

It requires a paid Claude plan (Pro, Max, Team, or Enterprise) or a Console account, which is Anthropic’s API platform. The free claude.ai plan does not include Claude Code, though you can still use free Claude chat for planning. Follow the setup guide (opens in a new tab) to install it and the quickstart (opens in a new tab) for your first session.

Many other tools can build a portfolio, including Cursor (opens in a new tab), GitHub Copilot (opens in a new tab), Replit (opens in a new tab), Bolt (opens in a new tab), Lovable (opens in a new tab), and v0 by Vercel (opens in a new tab). They differ in how they work and what they cost, so check each tool’s current plans and limits.

Whichever tool you choose, the work follows the same loop. Expect to go around steps 4 to 6 many times.

This prompt gives the agent everything it needs for a strong first version. Replace each part in square brackets with your own information before you send it. It works whether the folder is empty or already contains a project.

One of its rules keeps secrets out of your code, such as an API key (a password-like code that lets a program use a paid or private service). A typical portfolio does not need one.

Act as a senior frontend developer and product designer. Build my professional product management portfolio website in this project folder.

ABOUT ME
Use only the information below. It is my portfolio brief.
[paste the full contents of your portfolio-brief.md here]

SECTIONS TO INCLUDE
[list the sections you chose, for example: hero, about, projects and case studies, experience, skills, contact]

DESIGN
1. Create a polished, professional design that is fully responsive on phones, tablets, and desktops.
2. Prioritise typography, spacing, visual hierarchy, usability, and readability over decoration.
3. Follow the design direction in my brief. Keep animation subtle and purposeful.

CONTENT RULES
1. Use my real information only. No fake statistics, invented projects, testimonials, employers, or outcomes.
2. Use my real links: [your email], [your LinkedIn URL], [your resume file or URL], [any other links].
3. The finished site must not contain placeholder links or placeholder text. If something is missing, list it and ask me.
4. Every link, button, and interaction must work.

TECHNICAL RULES
1. If this folder already contains a project, use its existing stack. Otherwise choose a simple, beginner-friendly stack that is easy to deploy (for example plain HTML, CSS, and JavaScript, or Next.js) and explain your choice in two or three sentences.
2. The site must be deployable to Vercel from a GitHub repository.
3. Do not add unnecessary dependencies or heavy animation libraries.
4. Build for accessibility: semantic HTML, alt text for images, keyboard navigation, visible focus states, and good colour contrast.
5. Add a page title and meta description.
6. Add a .gitignore that excludes dependency folders, build output, and environment files.
7. Never put passwords, API keys, or other secrets in the code.

PROCESS
1. Before writing code, summarise your plan (stack, file structure, sections) and wait for me to confirm.
2. Ask me before any big decision, such as adding a dependency, changing the stack, or removing content.
3. When you finish, explain in beginner-friendly steps how to run and preview the site on my computer.
4. List every file you created or changed, with one line on what each one does.

The first version will rarely be right. The quality of your feedback decides how quickly it improves. “Make it better” forces the tool to guess, and it may change things you liked. Specific feedback says where the problem is, what you see, and what you want instead.

A few habits make this loop safer:

• Make small changes, one issue at a time. If something breaks, you will know which change caused it.
• Review what changed. Most coding agents show a diff, a view of exactly which lines were added or removed. Skim it, and check the preview, before accepting.
• Keep a copy before large changes. Before a big redesign, save a copy of the project folder, or once you have set up GitHub, make a commit. Chapter 4 explains commits.

Use these once the first version exists. Each one asks the agent to diagnose before changing anything, keep changes small, leave your existing content alone, and report what it changed.

Review the visual design of my portfolio before changing anything.

Focus on typography (sizes, line length, line height), spacing and alignment, visual hierarchy, colour and contrast, and consistency between sections.

What I have noticed: [describe what feels off, for example "the hero text feels cramped and the project cards look unrelated to the rest of the page"]

RULES
1. First list the five most important issues, ordered by impact, with the change you would make for each. Wait for my approval.
2. Do not change any text, links, or section order.
3. Do not add dependencies or heavy animation.
4. Keep changes small and consistent with the existing style.
5. Afterwards, list the files you changed and what I should check in the preview.

Check my portfolio for mobile and tablet problems at widths of 375px, 414px, and 768px.

Look for: horizontal scrolling, text or images that overflow, text that is too small to read, buttons or links that are too small to tap, and navigation that does not work on small screens.

Issues I have already seen: [describe them, including the page, section, and screen width]

RULES
1. Diagnose first. List each issue with the section and width where it happens, and the likely cause.
2. Fix with the smallest possible changes. Do not change the desktop layout unless it is needed for the fix.
3. Do not remove any content to make things fit.
4. Afterwards, list the files you changed and the widths I should re-check.

Help me present one project as a case study on my portfolio.

PROJECT NOTES
[paste your notes for this project]

STRUCTURE
Context, Problem, My role, Options and decision, What shipped, Outcome, What I learned.

RULES
1. Use only facts from my notes. Where something is missing, write "[needs input]" and ask me.
2. Do not invent metrics, quotes, or results. Keep qualitative results qualitative.
3. Flag anything that sounds confidential, such as internal names, revenue, or unreleased features.
4. Keep each part short and easy to scan, with clear headings.
5. Show me the written text for approval before you change any code.
6. Then build it using the site's existing design and components, make sure it reads well on mobile, and list the files you changed.

Audit my portfolio for accessibility and basic SEO. Report first; do not change anything yet.

CHECK
1. One main heading (h1) per page and a logical heading order.
2. Alt text on meaningful images; decorative images hidden from screen readers.
3. Descriptive link text (no "click here").
4. Every interactive element works with the keyboard and has a visible focus state.
5. Text colour contrast meets WCAG AA.
6. Form fields have labels.
7. Each page has a unique title and meta description, Open Graph tags for link previews, a favicon, and a language attribute.

RULES
1. List findings with severity (high, medium, low) and the file where each one is.
2. Wait for my confirmation before fixing.
3. Propose any new alt text, titles, or descriptions for my approval. Do not change other content or the visual design.
4. Do not add dependencies. List the files you changed when you are done.

Something on my portfolio is broken. Help me fix it without breaking anything else.

WHAT I SEE
[describe the problem: which page or section, what you expected, what happens instead, and the steps to make it happen]

ERROR MESSAGE (if any)
[paste the exact error text]

RULES
1. Diagnose first. Investigate and explain the most likely cause before changing any code.
2. Propose the smallest safe fix and wait for my approval.
3. Do not rewrite, refactor, or reformat unrelated code. Do not remove features or content.
4. If you are not sure of the cause, say so and suggest how we can find out.
5. After the fix, explain how I can confirm it works, and check that the rest of the site still works.
6. List every file you changed.

If something breaks after you deploy, Chapter 9 has a fuller diagnostic prompt.

Do a final quality check of my portfolio before I publish it. Report only; do not fix anything until I confirm.

CHECK
1. All internal links and section anchors work.
2. List every external link so I can open and confirm each one.
3. No placeholder text, sample content, "#" links, or leftover notes.
4. No invented metrics, projects, or claims compared with my brief.
5. My resume opens and my contact details are correct.
6. Layout works at 375px, 768px, and 1280px wide, and the site is usable with a keyboard.
7. No errors in the browser console.
8. The production build succeeds, if this project has a build command. Run it and show me the result.
9. No passwords, API keys, or other secrets in the code, and .gitignore covers dependencies, build output, and environment files.

Report the result as a checklist marked pass or fail. For each failure, propose the smallest fix.

Your AI tool has built a portfolio that runs on your computer. Before anyone else can see it, the code needs a home online that a hosting service can read. That home is GitHub. This chapter explains the handful of terms you need, then gives you three main ways to get your project there, plus a browser-upload fallback. Pick one; you do not need them all.

If your project is already on GitHub (some AI tools create the repository for you), check the secrets section below and then move on to Chapter 5.

Git is a tool that records the history of a folder of files. GitHub is a website that stores that history online, so it is backed up, shareable, and readable by services like Vercel. You will meet these words throughout the rest of the guide:

• You can undo a bad AI edit. AI tools sometimes change more than you asked. If you commit each working version, you can return to it quickly instead of trying to describe what used to be there.
• You get a history. Every commit shows what changed and when, which makes it much easier to work out when something broke.
• Vercel deploys from it. In the next chapter, Vercel watches your repository and rebuilds the site every time you push.

Public or private? If you are unsure, private is the safer default.

• Public: anyone on the internet can read the repository, including every file and every past commit (see GitHub’s guide: About repositories (opens in a new tab)).
• Private: only you and people you invite can see it.

Either works with Vercel’s free Hobby plan when the repository belongs to your personal account; on Hobby, Vercel cannot deploy a private repository owned by a GitHub organization (see the Vercel Git docs (opens in a new tab)).

Choose the path that matches how comfortable you feel. If you built the site with an AI coding agent, path A is usually the easiest. If you would rather click buttons, use path B.

Many coding agents can run Git commands for you, inside your project folder. That is convenient, but you should still understand what is happening. Ask the agent to explain each command before it runs, and to stop before it pushes, so you can check nothing private is about to go online.

Publish my project to GitHub safely.

About me
- My GitHub username: [your GitHub username]
- Repository name I want: [repository name, for example my-portfolio]
- Visibility: [public or private]

Do these steps in order
1. Before you run any git command, explain in one plain sentence what it does.
2. Check the .gitignore file. It must exclude: node_modules, build output folders (such as .next, dist, build, out), every environment file (.env, .env.local, .env.*), and operating-system files (.DS_Store, Thumbs.db). Create or update it if needed and show me the change.
3. Scan the project for secrets: API keys, passwords, access tokens, private keys, and personal details such as a phone number or home address. List anything you find with the file name. Do not print full secret values. If you find something, stop and ask me what to do.
4. If this folder is not a git repository yet, initialise one and name the branch main.
5. Make a first commit with a clear message.
6. If I need to create the empty repository on github.com first, tell me exactly what to do.
7. Show me the exact commands you will use to connect to GitHub and push. Wait for my approval before pushing anything.
8. If GitHub asks me to sign in, tell me what to expect. Never ask me to paste a password or token into this chat.
9. After the push, give me the repository URL and a short list of what was uploaded.

Rules
- Do not delete, move, or rewrite my project files, apart from .gitignore.
- Do not force-push.
- If a command fails, show me the error and explain it before trying a fix.

GitHub Desktop is GitHub’s free app for Windows and macOS that does the same job with buttons instead of commands. You add your project folder to the app, make a first commit, then choose Publish repository. The publish dialog has a Keep this code private checkbox; leave it ticked for a private repository. Labels may differ slightly between versions. Adding an existing project to GitHub using GitHub Desktop (opens in a new tab)

A terminal is a window where you type commands instead of clicking. Most code editors have one built in (look for a Terminal menu). Open it so that it is pointing at your project folder, the one that contains your site’s files. This path needs Git installed on your computer; if the first command below prints an error instead of a version number, use path A or B instead. Run these one at a time, in order.

git --version

git init

git add .

git config --global user.name "Your Name"

git config --global user.email "you@example.com"

git commit -m "Initial portfolio"

git branch -M main

git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPO.git

git push -u origin main

On your repository’s page on GitHub you can choose Add file → Upload files, drag files in, and commit them. Browser uploads are limited to 25 MiB per file and up to 100 files at a time, and you will have to repeat the upload by hand every time you change something. Never upload the node_modules or .next folders (they are generated and huge) or any .env file (it may contain secrets). Official guide: Adding a file to a repository (opens in a new tab).

Once your site is on Vercel (Chapter 5), updating it is a loop: edit your files, commit, push. Vercel notices the push and redeploys automatically. Your AI agent or GitHub Desktop can do the commit and push for you; on the command line it looks like this:

git status

git add .

git commit -m "Update projects section"

git push

A secret is anything that grants access or that you would not print on a public poster: an API key (a password-like code that lets a program use a paid or private service), passwords, access tokens, and private details such as your phone number or home address. The good news: a typical portfolio needs no secrets at all. If you add a contact form through a third-party service, it may give you a key that is designed to be public; follow that service’s own documentation on where to put it.

With your code on GitHub and nothing private in it, you are ready to put it on the internet in Chapter 5.

Vercel is a hosting platform: it reads your code from GitHub, runs the build that turns it into a website, and serves that website at a public address. You do not need to buy anything for this chapter. At the end you will have a live site on a free vercel.app address that you can share today. This site is hosted the same way, from a GitHub repository deployed on Vercel.

Vercel’s free plan is called Hobby. It is meant for personal, non-commercial projects, and a personal portfolio is a typical example (see Vercel Hobby plan (opens in a new tab)). Keep these points in mind:

• Non-commercial means non-commercial. Vercel’s fair use guidelines count things like taking payments, being paid to build or host the site, running ads, or affiliate-focused sites as commercial use, which needs a paid plan. Fair use guidelines (opens in a new tab)
• There are usage limits. A small personal portfolio is unlikely to reach them, but if you hit a Hobby limit you usually have to wait for it to reset or upgrade.
• Plans change. Limits and terms can change over time, so check the plan page before relying on any specific number.

Before you deploy, two things should be true: your code is on GitHub (Chapter 4), and the site works when you preview it on your computer. Most failed first deployments come from small problems that also exist locally, such as a misspelled file name or a missing package. Ask your AI tool to look for them first.

Check whether my project is ready to deploy on Vercel.

Act as a careful deployment reviewer. Inspect this project and report what is missing. Do not change any files yet.

Check these things
1. Framework and build: which framework this is, the build command, and the output directory Vercel should use. If it is plain HTML, CSS, and JavaScript with no build step, say so.
2. package.json (if there is one): the scripts (dev, build, start) and any dependency that is missing.
3. Node.js version: whether the project needs a specific version, and where that is declared.
4. File names: imports, image paths, or links whose upper/lower case does not match the real file name. These can work on my computer but fail on Vercel.
5. Broken links and missing files: images, fonts, my resume PDF, internal pages.
6. .gitignore: it should exclude node_modules, build output, and every .env file.
7. Environment variables: every one the code reads, whether each is really needed, and whether any secret is written directly in the code.
8. Hard-coded localhost addresses or other development-only URLs.
9. Basics: page titles, meta description, favicon, and social preview image.
10. If you can, run the production build locally and tell me the actual result.

How to report
- A numbered list of findings, each marked High (blocks deployment), Medium (something visibly broken), or Low (polish).
- For each finding: the file, what is wrong, and the fix you recommend.
- The exact settings I should choose in Vercel: Framework Preset, Root Directory, build command, output directory.

Rules
- Make no destructive changes: do not delete files, remove content, or rewrite git history.
- Ask me before editing anything, and show me the planned change first.

Vercel’s dashboard changes from time to time, so the labels below are accurate at the time of writing but may differ slightly on your screen. The official guide for this flow is Deploying Git repositories with Vercel (opens in a new tab).

Your portfolio is now live. The vercel.app address keeps working without you buying anything. If you would like an address of your own, such as yourname.com, Chapter 6 helps you decide whether it is worth it.

At the end of Chapter 5 your portfolio already has a public web address. You do not need to buy anything to finish this guide.

A quick picture first: your domain is the address people type, DNS is the directory that says which building that address belongs to, and your hosting is the building where the site actually lives. Three different jobs, often done by three different companies.

When Vercel deploys your project, it gives the site an address that looks something like your-project.vercel.app. You can find the exact one on your project’s dashboard. It costs nothing extra, works over HTTPS (the padlock in the address bar: an encrypted connection) straight away, and you can share it the moment your first deployment finishes.

The first part of the address comes from your project name. If you would like a cleaner address, you can rename the project in Vercel’s project settings. New deployments then use the new name — push a change or redeploy, then check the address on your dashboard. Old vercel.app links may stop working after a rename, so do this before you share the address. Official guide: Vercel: Changing your project name (opens in a new tab).

The trade-offs:

• Vercel’s brand is in your URL. For a student or early-career portfolio this is common and perfectly acceptable, but it reads less like a personal brand.
• The address is tied to Vercel. If you later move your site to another host, this URL stops pointing to it, and any links you shared on your resume or LinkedIn break.

A custom domain is a name you buy yourself, such as yourname.com. This site uses one: it is hosted on Vercel, but visitors only ever see my own domain.

What it gives you:

• Professional branding. A short address with your name is easy to remember and looks deliberate on a resume.
• Portability. The domain belongs to you, not your host. If you ever switch hosting providers, you update your DNS records and every link you have shared keeps working.
• Email options. You can later set up an address at your own domain through an email provider, which is usually a separate service with its own setup.

What it costs you:

• Money, every year. A domain is a separate purchase that you renew yearly. Prices vary by registrar and by ending (.com, .me, .dev, and so on), and the renewal price is often higher than the first-year price. Check the renewal price, not just the first-year offer.
• A little setup. You need to add DNS records at whichever company hosts your DNS, which may not be the company you bought the domain from. Chapter 7 walks you through it.

This is the most technical chapter in the guide, but you will not write any code. You will copy a few values from Vercel into a form at your domain company, then wait for the two to recognise each other. Take it slowly, read each step before you click, and keep both browser tabs open side by side. Official guide: Vercel: Set up a custom domain (opens in a new tab).

If you decided in Chapter 6 to stay on the free vercel.app address, you can skip this chapter and Chapter 8 entirely.

Check these three things first. Each one prevents a common dead end.

• Your site is already live on its vercel.app address. Open it and make sure it works. A custom domain only gives a working site a new name; it cannot fix a broken deployment.
• You can log in to the account where your DNS is managed. That is usually where you bought the domain, but not always. If a friend, an agency, or a former employer set the domain up, get access before you begin.
• You know who manages your DNS. Look up your domain’s nameservers (defined below). Your registrar’s dashboard usually lists them on the domain’s overview page. You can also enter your domain in the Google Admin Toolbox Dig tool (opens in a new tab) and choose the NS record type. The nameserver names usually contain the name of the company that answers for your domain, and that company’s dashboard is where you will make every change in this chapter.

DNS (the Domain Name System) is the internet’s directory. Each entry in it is a DNS record: a short line that says “for this name, here is the answer”. You only need to recognise five kinds.

Every DNS record has a field for which name it applies to. Vercel calls it Name; your provider may call it Host, Name, or something similar. This field causes more mistakes than any other, so check it against this table.

Many providers add your domain to whatever you type. If you enter www.example.com in the Host box, you may accidentally create www.example.com.example.com. Only type the full domain if your provider’s instructions ask for it.

Dashboards change, so labels may differ slightly from what you see. The paths below were checked against Vercel’s documentation at the time of writing.

Invalid Configuration on the domain card means one of three things: Vercel cannot see the DNS records it expects yet, it needs a TXT record to confirm you own the domain, or it could not issue the HTTPS certificate. Give a fresh change some time first, then work through this table. Vercel: Troubleshooting domains (opens in a new tab)

Still stuck? Chapter 9 covers more symptoms, including a site that works on one address but not the other.

Keep your Vercel domain card from Chapter 7 open in another tab so you can copy the exact values from it.

The navigation paths below come from each provider’s own help articles at the time of writing. Providers redesign their dashboards from time to time, so if a label on your screen differs, follow the linked help article. There are no screenshots here on purpose: a screenshot of an old layout is more confusing than a short written path.

Vercel describes each record with a Type, a Name, and a Value. Providers use different words for the same three boxes.

For www, every provider above takes just www in the name field. If your screen uses different words, match the boxes by role: record type, then the name it applies to, then where it points.

These steps only take effect if your domain uses Name.com’s nameservers, which is the default for domains registered there. Name.com: Using default nameservers (opens in a new tab)

Namecheap only lets you edit host records when the domain uses one of its own DNS services, such as Namecheap BasicDNS. Check under Domain List → Manage → Nameservers. If it says Custom DNS, edit your records at the provider those nameservers belong to instead. Namecheap: Why can’t I modify host records? (opens in a new tab)

Changes in Hostinger’s DNS editor only take effect if your domain uses Hostinger’s nameservers. If it points somewhere else, manage DNS at that provider. Hostinger: Pointing a domain to Hostinger (opens in a new tab)

Many people keep their domain at one registrar and use Cloudflare for DNS. In the Cloudflare dashboard, select your domain, go to DNS → Records, click Add record, choose the type, fill in the fields (use @ for the root), and save. Cloudflare: Create DNS records (opens in a new tab)

Cloudflare also has a proxy status on each record: Proxied (orange cloud) sends traffic through Cloudflare first, while DNS only (grey cloud) points visitors straight at Vercel. Vercel recommends connecting directly, so set the records you add for Vercel to DNS only. If you choose to proxy anyway, set Cloudflare’s SSL mode to Full (strict); the Flexible mode can cause redirect loops. Cloudflare: Proxy status (opens in a new tab) Vercel: Using a proxy in front of Vercel (opens in a new tab)

Open your Domain Portfolio, select the domain to reach its settings, and open DNS. If there is already an A record on @ (sometimes shown as “Parked”) or a CNAME on www, edit it with Vercel’s values instead of adding a second one; otherwise click Add New Record. Fill in Type, Name (@ for the root), Value, and TTL, then save. This only works while the domain uses GoDaddy’s nameservers. GoDaddy says most changes take effect within an hour but can take up to 48 hours. GoDaddy: Manage DNS records (opens in a new tab) GoDaddy: Add an A record (opens in a new tab) GoDaddy: Add a CNAME record (opens in a new tab)

The same workflow applies almost everywhere, whatever the buttons are called:

1. Look up your nameservers to confirm which company hosts your DNS, and log in there.
2. Find the page called something like DNS, DNS records, Zone editor, or Manage DNS for your domain.
3. Screenshot or export the existing records before you touch anything.
4. Edit the records for the root domain and www to match Vercel’s Type, Name, and Value. Remove only the A, AAAA, CNAME, forwarding, or parking records on those two names that conflict.
5. Save, including any separate confirm step.
6. Return to Vercel’s Settings → Domains and refresh until the domain verifies.

To see what the internet currently returns for your domain, enter it in the Google Admin Toolbox Dig tool (opens in a new tab) and choose A or CNAME. When the answer matches what Vercel asked for, verification usually follows. If your provider’s help center does not explain where its DNS settings are, search it for “add A record” or “add CNAME record”.

Something will go wrong at some point. That is normal, and it is rarely a disaster if your work is committed to GitHub. The most common mistake is not the original problem but the reaction to it: asking an AI tool to “fix it” over and over until five unrelated things have changed and nobody knows which one mattered.

1. Read the evidence. For a failed deployment, open the build log in Vercel (Chapter 5, step 9). For a page that looks or behaves wrong, open your browser’s developer tools and check the console, the panel where the browser lists errors.
2. Check the real configuration. Look at what is actually set in Vercel and at your DNS provider, not what you remember setting.
3. Change one thing at a time. Then test again. If the change did not help, undo it before trying the next idea.
4. Keep a commit you can return to. Commit every version that works, so there is always a safe point to roll back to.

Find the row that matches what you see. The likely causes are listed most common first; the next step is the least risky thing to try.

If the site worked before a change and does not now, going back is often faster than fixing forward. The safe way is a revert: a new commit that undoes an earlier one, without deleting any history.

• With your AI tool: ask it to show you the recent commits, explain which one introduced the problem, and revert that commit with git revert. Tell it not to use commands that delete history.
• With GitHub Desktop: find the commit in the app’s history and choose the option to revert it (labels may differ by version), then push.
• On the command line: the two commands below undo your most recent commit.

git revert --no-edit HEAD

git push

Vercel also keeps a list of your past deployments under Deployments, so you can see which commit was the last one that worked before you choose what to revert.

Use this whenever something is broken and you are about to ask your AI tool for help. Fill in every line you can; the exact error text and what changed recently matter most.

Help me fix a problem with my portfolio site. Diagnose before you change anything.

The problem
- What I see: [describe the symptom]
- What I expected: [what should happen instead]
- Steps to reproduce: [what I open or click, on which device and browser]
- Where it happens: [local preview, Vercel preview URL, live vercel.app URL, or custom domain]
- Exact error text: [paste the error message, the relevant part of the Vercel build log, or the browser console message]
- What changed recently: [the last edit, AI prompt, setting, or DNS change before it broke]

How to work
1. Read the relevant files, logs, and configuration first. Do not edit anything yet.
2. Explain the most likely cause in plain language, with the evidence: the file, line, or log message that points to it. If you are not sure, list the other possible causes too.
3. Propose the smallest safe fix. Say what it changes and what else it could affect.
4. Wait for my OK before editing.
5. Preserve existing functionality, content, and design. Do not refactor, rename, upgrade, or "clean up" anything unrelated.
6. After the fix, show me the diff.
7. Verify it: run the build (and tests, if the project has any) and report the actual result. Then tell me exactly what to check in the browser, at desktop and phone width.
8. If you do not have enough information, ask me for it (for example the full Vercel build log) instead of guessing.

Before you add the link to your resume or post it on LinkedIn, go through this list once on the live site. Tick each item as you confirm it. Nothing is saved, so if you reload the page the list starts fresh, which is handy when you run through it again after a big update.

If an item fails, fix it with your AI coding tool (the prompts in Chapter 3 help), push the change, and check again on the deployed site. Chapter 9 covers the most common problems.

If you followed this guide from the start, you now have:

• A portfolio built from your real experience and projects, with an AI coding tool doing the coding.
• Your code stored on GitHub, with a history of every change you have made.
• A live site on Vercel that updates automatically each time you push a change.
• Optionally, your own custom domain with HTTPS.
• A repeatable workflow: describe a change, review it, push it, and check the live site.

That last point matters most. The portfolio is never really finished, and you now know how to keep improving it without starting over.

• Update it after each project. Add the case study while the details, decisions, and outcomes are still fresh.
• Review your links every few months. Once a quarter, click through your contact, resume, and project links to catch anything that has moved or expired.
• Renew your domain if you bought one. Turn on auto-renew at your registrar, or set a reminder before the renewal date. An expired domain takes your portfolio offline.

My own portfolio at adityagangwani.me is a finished example of this workflow. You do not need to visit it to follow the guide, but if you would like to see where the steps can lead, have a look around.