Savitribai Phule Pune University Students: Frontend Internship Portfolio Evidence Beyond Clone Projects

Clone projects alone rarely prove you can do frontend work, because they show you can reproduce a finished design but not that you can make decisions. Evidence that goes further has five parts: a stated problem, recorded design decisions, responsive screenshots, an accessibility audit and readable code. This article gives Savitribai Phule Pune University (SPPU) students a checklist, a case study template and a worked example for assembling all five.

Why clones fall short as evidence

A Netflix, Spotify or Amazon homepage clone is useful practice. The trouble is that a reviewer looking at one cannot tell what you decided and what you copied. The layout, colour choices, spacing and content hierarchy were all settled by someone else. What remains visible is your ability to follow, which is only a small part of frontend work.

Real frontend work involves ambiguity. Someone has a vague need, the screen sizes vary, users have different abilities, and the code has to be changed by other people later. A portfolio item that shows you handling those conditions is stronger evidence than a pixel-accurate copy.

This article makes no claims about what specific recruiters prefer. The reasoning here is about what a piece of work lets a reader verify: if a reviewer can open your repository, read your reasoning and test your page with a keyboard, they have evidence. If they can only look at a screenshot, they have to trust you.

What counts as evidence, and what does not

The portfolio checklist

Use this as a pass/fail list for each project you plan to show. A project does not need every line, but if it satisfies fewer than about two-thirds of them, it probably belongs in your repository list rather than at the top of your portfolio.

A. Problem and scope

• One-sentence problem statement naming a user and a task (for example, “a first-year student checking a timetable on a phone”).
• A short list of what the project deliberately does not do.
• Where the content came from: your own, placeholder, or a public dataset with its source named.

B. Design decisions

• At least three decisions written as “I chose X over Y because Z”, covering layout, state handling and styling.
• A rough sketch or wireframe made before coding, photographed or exported.
• A note on one thing you changed after testing it.

C. Responsive evidence

• Screenshots at a minimum of three widths: small phone, tablet, desktop.
• A note on the breakpoint strategy: mobile-first or desktop-first, and why.
• Checked with real browser developer tools device emulation, and ideally on at least one physical phone.
• Text that remains readable and tap targets that remain usable at the smallest width.

D. Accessibility audit

• Keyboard-only walkthrough: can you reach and operate every control, and is focus visible?
• Colour contrast checked for text and interactive elements, with the tool named.
• Semantic HTML: headings in order, landmarks, labels on every form field, meaningful alt text.
• An automated scan (for example, Lighthouse in Chrome or the axe browser extension) recorded with date and results, plus a manual check, since automated tools do not catch everything.
• An honest list of issues still open.

E. Code quality

• README with setup steps that actually work from a fresh clone.
• Folder structure explained in two or three lines.
• Linter and formatter configuration committed (ESLint and Prettier are common choices).
• Commit history with readable messages rather than a single “final” commit.
• No unused dependencies, no commented-out blocks, no secrets in the repository.
• Components or functions with one clear job each.

F. Delivery

• Live link that still works, on free static hosting such as GitHub Pages, Netlify or Vercel.
• Repository link on the same page as the case study.
• Case study published as a page or README section, not only a PDF.

Case study template

Copy this structure into a README or a portfolio page. Keep the whole thing to roughly 500 to 800 words with images. Each heading corresponds to a checklist section above.

Project title: [Name] - [one-line purpose]
Role: [solo / team of N, what you personally built]
Timeframe: [dates or number of days]
Links: [live site] | [repository]

1. Problem
   - Who is the user, and what are they trying to do?
   - What goes wrong today?
   - Scope: what is in, what is out.

2. Approach and design decisions
   - Decision 1: chose [X] over [Y] because [reason]
   - Decision 2: ...
   - Decision 3: ...
   - Sketch / wireframe image.

3. Responsive behaviour
   - Screenshots: 360 px | 768 px | 1280 px
   - What changes at each breakpoint and why.

4. Accessibility audit
   - Date, tools used.
   - Keyboard test result.
   - Contrast results.
   - Issues fixed: [list]
   - Issues still open: [list]

5. Code quality
   - Structure overview.
   - Linting/formatting setup.
   - One piece of code you are proud of, and one you would refactor.

6. What I would do next
   - Two or three concrete improvements.

Case studies are written in the first person by convention, even though this guide is not. Use “I” for your own project, and be specific about your own contribution when you worked in a group.

Worked example: frontend portfolio evidence (illustrative)

The following is an illustrative example of how a filled-in case study might read. It is not a real student project, and no code or tests are claimed to have been run. It exists to show the level of specificity to aim for.

Project: Hostel Mess Menu Viewer

Problem. Students living in a hostel check the weekly mess menu on their phones, usually in a queue with poor signal. The existing menu is a photographed notice that is slow to load and hard to read. The goal is a page that shows today’s menu first and loads quickly. Out of scope: logins, ordering and feedback forms.

Design decisions.

1. Plain HTML, CSS and a small amount of JavaScript over a framework. The menu is static data in a JSON file, so a framework would add weight without adding value. Trade-off: if the page later needs filtering and user accounts, a rewrite may be needed.
2. Mobile-first layout with today’s meals at the top. A sketch showed the weekly grid pushing today’s meals below the fold on a phone. The weekly grid now sits in a collapsible section below.
3. Text over images. The photographed notice was replaced with real text, which is searchable, scalable and readable by screen readers.

Responsive evidence. The case study would include three screenshots. At 360 px, meals stack in one column with large tap targets for the day selector. At 768 px, the day selector becomes a horizontal tab row. At 1280 px, the weekly grid is visible by default with today highlighted.

Accessibility audit. An illustrative audit table might look like this:

Listing an open issue is a strength, not an embarrassment. It shows you tested rather than ticked boxes.

Code quality. The README would give the folder layout (index.html, styles/, scripts/, data/menu.json), the lint command, and one function the author would refactor, such as a date-handling helper that mixes formatting with data lookup.

Turning clone projects into evidence

If you already have clone projects, you do not need to discard them. Convert them into case studies by adding a layer of your own decisions.

1. Change the content and the user. Rebuild the same interface pattern for a real need, such as a college club events page, rather than a streaming catalogue.
2. Remove one feature and add one. Drop something you only copied, and add something the original lacks, such as keyboard support or a dark mode that respects the system setting.
3. Audit the original. Run the same accessibility checks on the page you copied and document where it falls short. Be careful to describe this fairly and avoid overstating.
4. Write down the trade-offs. Even two honest paragraphs on what you would do differently lift a clone above a copy.

A seven-day plan for one strong project

If you are looking for structured practice to build this kind of work, CareerSwami offers a free two-week online internship with 26 tracks, a free offer letter and a free completion certificate after successful completion. Treat any internship output the same way as any other project: the certificate is a record, while the case study and code are the evidence.

SPPU engineering internship rules and your frontend portfolio evidence

For engineering students, the most useful SPPU document for portfolio planning is the 2019-pattern UG engineering rules and regulations, issued under the Faculty of Science and Technology. It is a 2019-20 document, so it may have been superseded for newer cohorts. Check which version applies to your admission year before relying on any detail below.

That document states that the internship is completed after semester 5 and assessed in semester 6, lasting 4 to 6 weeks at most. In practice, a frontend project built in a short window needs a tight scope. The seven-day plan in this article suits that kind of timeline, with the case study finished before assessment.

The same document says the semester VI internship carries 4 credits, evaluated through 100 marks of term work. Because evaluation is based on term work rather than an exam, what you can show matters. It also says students must keep documentary proof of internship activities, which the programme head, cell in-charge, project head, faculty mentor or industry supervisor evaluates as an overall compilation, with a participation certificate where applicable. A dated repository history, screenshots at several screen widths, an accessibility audit log and a written case study are the kind of material that can sit in such a compilation. Your department decides what is actually accepted.

The rules also allow the requirement to be met in an industry, government body, NGO, MSME or rural setting, or through innovation, IPR or entrepreneurship work, following AICTE guidelines. The text opened does not use the words online, virtual or remote for internships, so do not assume a self-directed online portfolio project counts. Ask first.

These points cover UG engineering only. Rules for other programmes may differ. CareerSwami is an independent resource and is not affiliated with, approved by or recommended by SPPU or any college affiliated to it.

Questions to settle before you start building

• Open the regulations and syllabus for your admission year and confirm whether the 2019-pattern internship clauses still apply to your cohort.
• Ask your internship in-charge or faculty mentor in writing whether a self-directed frontend project, or an online internship, can satisfy the internship requirement.
• Ask who evaluates your compilation and what proof they expect: certificate, supervisor letter, repository link, or report.
• Confirm the dates of your post-semester-5 internship window and the semester 6 submission deadline.
• Ask whether term-work reports must follow a department template and whether a public repository link may be included.
• Keep a copy of every written reply with your project files.

Frontend portfolio mistakes that weaken internship evidence

• Screenshots only. A reviewer cannot test a screenshot. Always link a live page.
• Tool lists as skills. A row of logos tells a reader nothing about depth. Tie each tool to a decision.
• Hiding the flaws. An audit with zero issues looks untested. An audit with honest open items looks real.
• Broken setup. If the README steps fail, many readers will stop there. Clone your own repository into a fresh folder and follow the steps.
• Too many projects. Three well-documented projects are easier to assess than ten undocumented ones.
• Unclear authorship. In group work, state exactly which parts you wrote.

Frequently Asked Questions

Are clone projects useless for a frontend portfolio?

No. They are good for practising layout and component skills. They just carry little evidence of your own judgement, so pair them with at least one original project and a written case study.

How many frontend projects should an SPPU student show in a portfolio?

Two or three documented projects are enough for most early-career portfolios. Make sure at least one starts from a real problem rather than an existing design.

Do I need a framework like React to look credible?

Not necessarily. What matters is that your choice fits the problem and that you can explain it. A static page built with solid HTML and CSS can show stronger fundamentals than an unnecessary framework setup.

Which tools can I use for an accessibility audit for free?

Lighthouse is built into Chrome developer tools, and the axe browser extension is a widely used free option. Combine them with a manual keyboard walkthrough and a contrast check, because automated tools do not catch every problem.

Can I use a college project in my portfolio?

Often yes, but check any rules on confidentiality, group ownership or report submission first. State clearly which parts you built, and do not publish anything your department has asked you to keep private.

Will an internship certificate be enough on its own?

A certificate records participation or completion, but it does not show what you built. Link the actual work, such as the repository and case study, alongside it. CareerSwami’s free completion certificate is issued after successful completion of its two-week online internship, and it makes no promise of credit, placement or a job.

How do I show responsive design if I only have a laptop?

Use the device emulation mode in your browser’s developer tools to capture screenshots at set widths. If you can, also open the deployed link on a real phone and note any differences you find.

Where should I host the case study?

A README in the repository is the minimum. A page on your own portfolio site, hosted free on GitHub Pages, Netlify or Vercel, is better, as long as it links to both the live project and the code.

Related Frontend Development guides

• University of Mumbai Students: Writing a Frontend Development Internship Report with Screenshots and Code
• JNTUH Students: Frontend Developer Internship Interview Preparation for React and JavaScript
• JNTUK Students: How to Evaluate a Frontend Development Internship Offer Before Applying
• All Frontend Development internship guides