MAKAUT Students: Full Stack Web Development Internship Portfolio Evidence Recruiters Can Check

Recruiters can check a full stack portfolio when every claim links to something they can open: a README that explains the project, a live demo, API documentation, screenshots, a readable commit history and a one-page architecture note. If you are a MAKAUT student, build those six items for each project and keep them consistent with each other. Whatever format your department asks for in project reports, treat this evidence pack as a separate, public layer on top.

Why “checkable” matters more than “impressive”

A project list that says “built an e-commerce site using React, Node and MongoDB” is a claim. A reviewer cannot tell whether you wrote it, whether it runs, or whether you understand it. Evidence converts the claim into something verifiable in a few minutes.

Most people who screen portfolios are short on time. They typically open the repository, look for a README, click the demo, and skim recent commits. If any step fails, they move on. Your job is to make each step succeed without effort.

This guide gives you a template, a scorecard to rate your own work, a worked illustrative example, and a list of things to confirm with your college. It does not promise any hiring outcome. It only helps you present real work honestly and clearly.

The six pieces of evidence

1. Repository README: the front door of the project.
2. Live demo link: proof the application runs outside your laptop.
3. API documentation: proof you designed the backend contract deliberately.
4. Screenshots: a fallback when the demo is slow or down.
5. Commit history: a record of how the work actually progressed.
6. Architecture note: a short explanation of why the system is shaped the way it is.

1. The repository README

Write the README for someone who has never met you and has ninety seconds. Put the most useful information first, and avoid long tool-name lists.

README structure to copy

• Title and one-line purpose: what problem the app solves and for whom.
• Live demo and test credentials: a link, plus a demo user if login is needed. Use a throwaway account, never real data.
• Screenshots: two to four images embedded near the top.
• Tech stack: frontend, backend, database, hosting, each with its role.
• Features: five to eight bullets describing what a user can do.
• Setup: exact commands to clone, install, configure environment variables and run.
• API overview: a short table and a link to the full documentation.
• Architecture note link: pointing to the file in the repository.
• Known limitations: what is unfinished. Honest limits build trust.
• Your role: especially for group projects, state which parts you built.

Include an .env.example file listing variable names without secrets. Never commit real keys, database passwords or tokens. If you already did, rotate them; deleting the file later does not remove it from history.

2. The live demo link

A deployed app shows that you handled configuration, build steps and environment differences. Free hosting tiers are enough for a portfolio project, though they may sleep when idle.

• State in the README if the first load may take a while because of a sleeping server.
• Seed the database with realistic sample data so pages are not empty.
• Provide a demo login rather than forcing registration.
• Check the link from a phone and from a different network before sharing it.
• Recheck the link before any application deadline, since free services change their limits.

If you cannot host the backend, say so, and rely on screenshots and a short screen recording instead. A clearly labelled limitation is better than a dead link.

3. API documentation

API documentation is what separates a full stack project from a front-end exercise with a hidden backend. It can be a Markdown file, a Postman collection exported to the repository, or an OpenAPI specification rendered through a documentation tool.

For each endpoint, document the method, path, authentication requirement, request body, success response and error responses.

The table above is illustrative, not taken from a real project. Notice that it lists failure cases such as 403 and 409. Documenting error behaviour shows that you thought beyond the happy path.

4. Screenshots

Screenshots protect you when a demo is offline and let a reviewer judge the interface at a glance. Keep them organised.

• Capture the main flow in order: landing page, sign-in, core feature, result or dashboard.
• Include one mobile-width screenshot if the layout is responsive.
• Include one screenshot of an error or empty state, which most students skip.
• Store images in a docs/screenshots folder with descriptive file names.
• Add alt text or a caption saying what each image demonstrates.
• Crop out personal data, browser bookmarks and anything unrelated.

5. Commit history

A reviewer reads commit history to judge whether the work grew step by step. A single commit named “final” containing the whole project invites doubt. A series of small, labelled commits tells a believable story.

Habits that make history readable

• Commit small units of work: one feature, one fix, one refactor.
• Write messages in the imperative: “Add pagination to task list endpoint”.
• Use feature branches and merge them, even if you work alone.
• Keep commits under your own name and email configured in Git, so authorship is visible.
• Do not rewrite history to hide mistakes after sharing the link; a visible fix is normal.
• Do not fabricate dates or bulk-commit someone else’s code under your name.

If you built something in a team, the history should show each member’s contributions. If you followed a tutorial, say so in the README and describe what you changed or extended. Honest attribution is part of the evidence.

6. The architecture note

This is a single page, ideally 250 to 400 words, saved as docs/ARCHITECTURE.md. It shows judgement, which is hard to fake.

1. System overview: a simple diagram of browser, frontend, API, database and any third-party service.
2. Data model: main entities and their relationships.
3. Request flow: what happens from button click to database write and back.
4. Authentication approach: how sessions or tokens work and where they are stored.
5. Key decisions: two or three choices with the reason and a trade-off, such as relational versus document database.
6. Deployment: where each part runs and how configuration is supplied.
7. What you would change next: scaling, testing or security improvements.

Portfolio evidence scorecard

Rate each project honestly before you share it. Score each row 0 (missing), 1 (partial) or 2 (complete). The scale is a self-check tool of our own design, not an industry standard.

Reading your total (maximum 16):

• 0 to 7: the project is not yet checkable; fix the zero rows first.
• 8 to 12: a reviewer can follow it, but gaps remain; improve the README and API documentation first.
• 13 to 16: the evidence pack is strong. Keep it current.

Worked example: full stack portfolio evidence (illustrative)

This is a made-up scenario to show the template in action. It does not describe a real student, and no code or tests were run for this article.

Imagine a third-year student building “CampusNotes”, a note-sharing app where students upload class notes by subject and semester. The stack is React, Express, PostgreSQL and a free hosting tier.

Before: what a weak entry looks like

CampusNotes - Full stack note sharing app
Tech: React, Node, SQL
Code: github.com/example/campusnotes

The repository has two commits, no README and no deployment. A reviewer cannot confirm anything.

After: the same project with an evidence pack

CampusNotes - note sharing for semester-wise class notes
Live demo: (hosted link; demo login in README)
Repo: (link) | API docs: /docs/API.md | Architecture: /docs/ARCHITECTURE.md
My role: designed the database, built the REST API and the upload flow;
a teammate built the landing page and styling.
Limitations: no email verification yet; uploads limited to PDF under 5 MB.

Now the supporting files. The README has three screenshots: upload form, search results filtered by semester, and the error message shown for an oversized file. The API file documents eleven endpoints with response codes. The commit history shows work grouped by branch: authentication, upload, search, pagination, deployment fixes.

The architecture note explains one decision in plain words: files are stored in object storage while only metadata and the file URL live in the database, because storing large binaries in the database would slow queries and inflate backups. It also admits the trade-off, which is an extra service to configure. A reviewer reading this learns more about the student’s thinking than a list of tools could convey.

Scorecard for this example: README 2, demo 2, API docs 2, screenshots 2, commits 2, architecture 2, security 1, testing 1, for a total of 14 out of 16. The gaps are listed openly under limitations, which is the honest way to present them.

Where an internship fits into the evidence

A short internship is useful mainly as a structured reason to build and finish something. A free two-week online internship such as the CareerSwami free two-week internship offers a 14-day window, a free offer letter, and a free completion certificate after successful completion, across 26 tracks. Treat the certificate as one supporting document. The recruiter-checkable proof is your repository and demo, not the certificate.

A realistic 14-day plan for a small full stack project:

• Days 1 to 2: define scope, write the README skeleton, sketch the data model.
• Days 3 to 6: build the API, document each endpoint as you finish it.
• Days 7 to 10: build the frontend flows and connect them to the API.
• Days 11 to 12: deploy, seed data, capture screenshots.
• Days 13 to 14: write the architecture note, record limitations, run your scorecard, fix the lowest rows.

Documenting while building is far faster than reconstructing details at the end.

MAKAUT portfolio evidence: what to check at university and college level

MAKAUT was set up under the West Bengal University of Technology Act, 2001, and its About page says it began its academic programme through the affiliation of engineering and management institutions and colleges. The university also keeps an Affiliated Colleges page with lists by academic year, including 2026-27, and intake PDFs for B.Tech, MBA and MCA. For a full stack student, this means most programmes run through an affiliated college, so the college you study in is usually the first office to ask about project guides, report formats and review schedules.

The About page says the School of Engineering & Technology offers B.Tech in CSE and IT. If a web project is meant to support a project, training or seminar component in your programme, the place to confirm that is your own syllabus, not this article. The university’s homepage menu links to Rules and Regulations, Syllabus and Placements pages, which are the places to look for university-wide rules. Check which regulation year applies to your batch before assuming anything about how internship or project work is counted.

In practice, keep the public evidence (README, live demo, API documentation, commit history, architecture note) separate from any academic report. Do not describe an external or online internship as counting towards a MAKAUT requirement unless your college confirms it in writing. For group projects, state your own role plainly in the public README, and ask before publishing code if a guide or outside organisation is involved.

The site’s Students menu also links to a Placements page. Read it for current information on how placement support is described, and do not assume it offers portfolio reviews.

Questions to settle before sharing your portfolio

• Open the Syllabus section on the university site and find the document for your branch and admission year; note what it says about project, training or internship in your semester.
• Read the Rules and Regulations page and any recent notices for rules on internships and project work, and save the version you used with its date.
• Ask your department office or project guide in writing whether an online or external internship is accepted for any requirement, and what proof is needed.
• Confirm the report format your department expects, and whether you may publish project source code and a live demo.
• Ask your college’s training and placement cell whether it reviews student portfolios or resumes, and how to book a session.

Portfolio mistakes that weaken Full Stack evidence

• Broken demo links: test them again before every application.
• Tutorial clones presented as original work: credit the source and describe your changes.
• Leaked credentials: scan the repository before making it public.
• Inflated bullet points: do not write numbers such as users or performance gains unless you measured them and can show how.
• Too many shallow projects: two fully evidenced projects beat six bare repositories.
• Inconsistent details: the resume, README and LinkedIn should agree on dates, stack and role.

A final pre-share checklist

1. Open the repository in a private browser window; confirm it is public and the README renders.
2. Follow your own setup steps on a clean folder or another machine.
3. Click every link in the README.
4. Log in to the demo with the credentials you published.
5. Scan for secrets and personal data.
6. Check that the commit author name matches the name on your resume.
7. Pin the best two repositories on your profile and put the demo link on your resume next to the project title.

Frequently Asked Questions

How many projects should a MAKAUT student show recruiters?

Two or three well-evidenced projects are enough. Each should score at least 13 on the scorecard above. One of them should include authentication and a database so the full stack is visible.

Is a live demo mandatory?

It is not mandatory, but it is the quickest proof that the app works. If hosting is not possible, provide clear screenshots, a short screen recording and exact local setup steps, and say why there is no hosted version.

Which format is best for API documentation?

Use whichever you can keep accurate. A Markdown table in the repository is fine for small projects. An OpenAPI file or an exported Postman collection is better when endpoints are many, because it can be tested directly.

Can I use a college project as my portfolio project?

Often yes, but confirm with your guide first, particularly about publishing the code. Then write a separate public README that states your role clearly if the work was done in a group.

Does an internship certificate replace repository evidence?

No. A certificate says you completed a programme; a repository and demo show what you built. Present the certificate as supporting information and lead with the project links.

What if my commit history is messy?

Do not rewrite it dishonestly. Start writing clearer commits from now on, add a README and architecture note, and use the limitations section. Recruiters mainly look for steady, understandable progress and honest authorship.

Should the architecture note include a diagram?

Yes, a simple one helps. Boxes and arrows for browser, frontend, API, database and external services are enough. Export it as an image and embed it in the note.

Will this evidence pack guarantee an interview or job?

No. It makes your work easier to verify and discuss, which is all it can do. Hiring depends on many factors outside your portfolio.

Related Full Stack Web Development guides

• Structuring a Full Stack Web Development Internship Report: A Guide for GTU Students
• Savitribai Phule Pune University Students: Full Stack Web Development Internship Interview Preparation
• University of Mumbai Students: Comparing MERN, Django and Java Paths for a Full Stack Internship
• All Full Stack Web Development internship guides