All the reading

Portfolio

6 lessons, about 26 minutes. The check's questions come from these.

Picking a clear project

1. Pick a project worth showing

4 min

Key point

One clear project

Your portfolio starts with one project, not five half-finished repos.

Pick the project a reviewer can understand fast. It should solve one clear problem, for one clear user, with one result they can see.

What to choose

Choose something you already built, even if it is rough. Do not start a new idea because it sounds better.

Good examples: a college event tracker, UPI expense splitter, hostel complaint form, campus bus tracker, placement prep dashboard, or mess menu page.

Your to-do

Use this filter

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Ask if someone you know would actually use it.
Check if the result is visible in a screenshot, screen recording, or live demo.
See if you can explain it in 30 seconds without saying it is incomplete.
Pick the one that looks most finished and easiest to understand.
Prefer clear execution over an ambitious idea with broken parts.

0 of 5 done

Common mistake

Do not chase fancy

Do not pick a project only because you spent the most time on it. Time spent is not portfolio value.

A simple HTML/CSS/JavaScript or React app can work well if the story is clear and the main flow works.

Shaping a strong profile

2. Make your GitHub profile readable

4 min

Key point

One idea

Your GitHub profile is not a storage room. It is the front page for your work.

A recruiter, mentor, or founder should quickly see who you are, what you build, and which project to open first.

Your to-do

Set profile basics

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Use a real photo or a clean avatar
Write a one-line bio: what you build, stack, and goal
Add your location if it gives useful context, like Pune or Bengaluru
Add one link you maintain, such as LinkedIn or a portfolio
Use a name that connects clearly to your real identity

0 of 5 done

Tip

Cleaning repo and README

3. Turn code into a strong repo

5 min

Key point

One thing to remember

A strong repo is easy to review. A stranger should quickly see where the app starts, where the code lives, and whether the project can be run safely.

Clean the shape

Start with the top-level view. If the root folder has random files, old drafts, and final-v2 names, clean it before you write a better README.

Keep the structure simple. Do not add folders just to look serious. Use names people understand.

Example

Folder example

For a small web app, this is enough. Source code goes in src. Public files go in public. Notes can go in docs.

Deploying and sharing work

5. Deploy it free and test the link

4 min

Key point

One thing matters

A reviewer should be able to open your project without cloning it.

Your goal today is one working live link in your README. If the project can be deployed, do not submit only a local setup.

Pick a host

Use the simplest host that matches your stack. GitHub Pages is a safe default for static HTML, CSS, and JavaScript projects from a GitHub repository.

For framework projects, Netlify and Vercel are common Git-connected options. Vercel has a free Hobby plan for personal projects and developers. Netlify can deploy from Git providers after you import an existing project.

Your to-do

GitHub Pages path

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Example

Worked example

Suppose you built a quiz app, a hostel mess menu page, and a job alert bot.

The quiz app looks like practice. The bot is hard to verify. The mess menu page solves a campus problem and can be shown in one link. Pick that.

30-second explanation:
This is a hostel mess menu web app. Students can see today’s meals, search by day, and get one shareable link. I built it for my college hostel because the menu was usually posted in WhatsApp messages and got lost.

Before:
- final-final.js
- test2.js
- newcopy.js
- screenshot-1.png
- screenshot-final.png

After choosing one project:
- hostel-menu-tracker/
- src/
- public/
- README.md
- package.json

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

List your projects and shortlist three.
Pick the one with one user, one problem, and one visible result.
Write one sentence for the problem it solves.
Write a 30-second explanation in plain English.
Ask a friend if they understand the project name in one read.

0 of 5 done

Use this template:
Project name:
Problem it solves:
Who it is for:
Main result:
30-second explanation:

Example

Profile README

A profile README appears on your GitHub profile when you create a public repository with the exact same name as your GitHub username. It must have a non-empty README.md in the repository root.

If your username is ritikdev21, create a public repo named ritikdev21. GitHub’s setup flow is: create a new repository, name it exactly like the username, select Public, enable Add README, create the repository, then edit README.

# Hi, I'm Ritik

I build web apps with React and Node.js.
I like projects that help students save time or money.

Projects: https://github.com/ritikdev21
Contact: [email protected]

Before

my-project/
  app.js
  index.html
  styles.css
  logo-final-new.png
  test123.js
  readme draft.txt

After

my-project/
  src/
    app.js
    components/
  public/
    logo.png
  docs/
    notes.md
  README.md
  package.json

Your to-do

Use commits well

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Commit after one clear change.
Write messages that say what changed, like add login form or clean API errors.
Avoid vague messages like update, final, or changes.
Keep making small commits from now on, even if your first commit was messy.
Do not commit node_modules, build folders, .env files, API keys, or private tokens.

0 of 5 done

git add src/app.js
git commit -m "move app logic into src folder"

git add public/logo.png README.md
git commit -m "add project logo and usage notes"

git add package.json
git commit -m "add scripts for local run and build"

Example

Ignore local junk

A .gitignore stops local files from entering GitHub. Add it before you push secrets or heavy folders by mistake.

Example .gitignore for Node

node_modules/
.env
.DS_Store
dist/
coverage/

Tip

License choice

Add a license only if you want others to reuse or build on your code. MIT is a common simple choice for open sharing.

If you use MIT, use the standard MIT text from a trusted source. Update the copyright line with your name and year.

LICENSE

Use a standard MIT text from a trusted source, then update the copyright line with your name and year.

Example

UPI tracker example

Say you built a UPI expense tracker. Move app code into src, keep screenshots in public or assets, and keep notes in docs. Add .gitignore so .env and node_modules stay out of GitHub.

Then commit in small steps: create src structure, add expense form validation, ignore local config and build output.

package.json example

{
  "name": "upi-expense-tracker",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

4. Write the README people need

5 min

Key point

One job

Your README does the first explanation before anyone reads your code. GitHub says a repository README is often the first item a visitor sees.

Make the first screen answer four things: what it does, why it is useful, how to get started, and where to try it live if you have a demo.

What to include

You do not need a long story. You need a clean path from curiosity to testing.

Use these parts: short summary, why it exists, features, live demo, tech stack, local setup, screenshots, and contact or maintainer note.

Example

README opening

This is enough for a reviewer to understand the project quickly. Change the name, stack, and steps for your own app.

RoomSplit

A simple web app to split shared expenses between roommates and track who owes whom.

Why this exists
Many students in hostels and flats pay for groceries, electricity, and delivery orders together. This app helps calculate shares quickly and avoid confusion.

Features
- Add people and expenses
- Split costs equally or by amount
- See balance summary
- Export a simple report

Live demo
https://your-demo-link-here

Tech stack
- React
- Node.js
- Express
- MongoDB

How to run locally
1. Clone the repo
2. Run npm install in frontend and backend
3. Set environment variables
4. Run npm run dev

Screenshots
Add 1 to 3 images in a screenshots folder and link them here

Your to-do

Write the sections

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Start with 2 to 3 short lines saying what the project is and who it helps.
List 3 to 6 real features, like Add expenses or Export report.
Add a live demo link near the top if the project can be deployed.
Add setup steps that work on a fresh laptop.
Add at least one screenshot or a short demo so people can see the result.

0 of 5 done

Example

Setup section

If your app has a frontend and backend, split the setup clearly. If you use environment variables, show the file name and variable names, but never commit secrets.

How to run locally

Frontend
cd frontend
npm install
npm run dev

Backend
cd backend
npm install
cp .env.example .env
npm run dev

Common mistake

Common mistakes

Do not copy the assignment brief. It explains the task, not your finished project.

Do not use vague feature bullets like user friendly, scalable, or modern. Say what the app actually does.

Tip

Place it right

GitHub automatically shows README files from the .github directory, root directory, or docs directory. If there are multiple README files, GitHub displays .github first, then root, then docs.

For this track, keep your main project README simple and easy to find. The root README.md is the safest habit for college project repos.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your project README.md and replace any placeholder text.
Add summary, features, tech stack, setup, screenshot or demo link.
Check the README on a phone-sized screen and cut anything hard to scan.
Test the setup steps once, or mark anything missing clearly.
Commit and push the updated README to your public repo.

0 of 5 done

Example

Vite React example

For a Vite React app, test the production build before you deploy. This catches broken imports, missing packages, and build errors early.

If you use environment variables such as import.meta.env.VITE_API_URL, add them in the host dashboard. Do not depend on a local .env file in production.

# local check
npm install
npm run build

# common Vite publish settings
# Build command: npm run build
# Publish directory: dist

# .env before deployment
VITE_API_URL=http://localhost:3000
VITE_APP_NAME=Campus Notes

# .env after deployment on your host
VITE_API_URL=https://campus-notes-api.onrender.com
VITE_APP_NAME=Campus Notes

Tip

Test like a reviewer

Open the link in an incognito or private window. Then open it on your phone using mobile data or a different Wi-Fi.

Check the first screen, main buttons, one form, route reloads, and API data. If a React Router page shows 404 on refresh on Netlify, add this file.

# public/_redirects for React Router on Netlify
/*    /index.html   200

6. Share it for replies and submit the repo

4 min

Key point

Remove review friction

Your project should be easy to open, understand, and trust. A reviewer should not need to message you for files, setup steps, or the demo link.

GitHub says the README is often the first thing a visitor sees in a repo. Put the goal, live demo, setup steps, and useful links near the top.

Your to-do

Build your share pack

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Write one line that says what the project is
Write one sentence that says who it helps and how
Add the public GitHub repo link
Add the live demo link if the project can be deployed
Keep this text in Notes, Google Docs, or the README

0 of 5 done

Example

Share pack example

Use specific words. Do not write like an ad. Say what the user does inside the app.

This example works for a college UPI expense project.

Project name: FeeFlow
One-line summary: A simple UPI expense tracker for college students.
One-sentence impact: Helps hostel and PG groups record shared payments, split bills, and avoid confusion.
Links: GitHub repo, live demo, portfolio page

README intro:
FeeFlow is a UPI expense tracker for college students.
It helps hostel and PG groups record shared payments, split bills, and settle dues without confusion.

Live demo: https://feeflow.vercel.app
GitHub: https://github.com/yourname/feeflow

Your to-do

Place the links

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Add the project to your resume with GitHub and live demo links
Add it to LinkedIn Featured or Projects
Use the public repo link in hackathon forms unless they ask for another link
If Devpost asks for media, add relevant screenshots or images
If Devpost asks for a demo video, use a public YouTube or Vimeo link

0 of 5 done

Resume entry:
FeeFlow | React, Firebase | GitHub: github.com/yourname/feeflow | Live: feeflow.vercel.app

LinkedIn project text:
Built FeeFlow to help college students track shared UPI payments and settle dues.

Tip

Test like a reviewer

Open the repo in an incognito window. Then open the live demo on mobile data.

If only one link is allowed, submit the public repo link. Make sure the README has the live demo near the top.

Common mistake

Avoid broken trust

Do not submit a private repo, Google Drive zip, or personal folder. Submit the exact public repository link.

Do not leave secrets in the repo. If you used Firebase, Supabase, or an API key, check that only safe public values are committed.

git status
# make sure only intended files are changed

git add .
git commit -m "Prepare project for sharing"
git push origin main

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Write your 2-line project description
Add GitHub and live demo links to your resume and LinkedIn
Open the repo in incognito and check the README first
Test the live link on phone data
Submit the exact public repository link

0 of 5 done

Portfolio

1. Pick a project worth showing

One clear project

What to choose

Use this filter

Do not chase fancy

2. Make your GitHub profile readable

One idea

Set profile basics

3. Turn code into a strong repo

One thing to remember

Clean the shape

Folder example

5. Deploy it free and test the link

One thing matters

Pick a host

GitHub Pages path

Worked example

Name it clearly

Too broad is weak

Do this now

Use a bio formula

Pin strong repos

Know the limit

Profile README

Avoid these

Do this now

Use commits well

Add expected files

Ignore local junk

License choice

UPI tracker example

Common repo mistakes

Do this now

4. Write the README people need

One job

What to include

README opening

Write the sections

Setup section

Common mistakes

Place it right

Do this now

Netlify path

Vite React example

Common breaks

Test like a reviewer

Do this now

6. Share it for replies and submit the repo

Remove review friction

Build your share pack

Share pack example

Place the links

Test like a reviewer

Avoid broken trust

Do this now