How to Turn a University Assignment Into a Portfolio Project

You already have four or five pieces of code you spent weeks on. Most students look at them, decide they "only" count as coursework, and start something new from scratch — which is how three weekends disappear into choosing a framework.

A reviewer cannot tell whether a project began as an assignment. What they can tell is whether it was finished, deployed, documented and thought about. Those are the four things marking schemes do not reward, which is exactly why upgrading is cheap: the code already exists and the missing parts are the parts nobody made you do.

Here is the upgrade, in the order that gives the most improvement per evening.

1. Deploy it

This is the single largest change and it usually takes one evening.

An assignment that runs on your laptop is invisible. The same code at a URL a reviewer can click is evidence. Free hosting covers almost every stack: Vercel and Netlify for front-end and full-stack JavaScript, Railway, Render or Fly.io for anything with a server or a database, GitHub Pages for static sites, Streamlit Community Cloud for Python data apps.

If it genuinely cannot be deployed — a desktop app, a game, an embedded project — record a 30-second screen capture and put it at the top of the README. Never make someone imagine it working.

The common blockers, in the order you will hit them:

• Hard-coded connection strings. Move them to environment variables. This is a five-minute change that also fixes a security problem you probably have.
• A database that only exists locally. Most free tiers include a small Postgres instance. Write a migration or a seed script.
• Absolute file paths. C:\Users\you\Documents\project\data.csv will not exist on a server.
• A build step you never ran. Try a clean clone into a new folder and follow your own setup instructions. This fails more often than people expect.

2. Rewrite the README

Your current README is almost certainly the assignment brief, or the default text your framework generated. Neither tells a reviewer anything.

The structure that works answers a reviewer's questions in the order they occur to them: what is this, can I see it working, what is it built with, how does it work, can I run it, what did you learn. Notice that installation instructions come fifth — nobody installs a project they do not yet care about.

Two sections do most of the work:

The problem. Rewrite the assignment brief as a real problem. "Implement a library management system demonstrating inheritance and polymorphism" becomes "A lending system for a small library: staff can catalogue stock, members can borrow, and the system enforces loan limits and due dates." Same code, completely different first impression.

The technical decisions. Pick one place where you had a genuine choice and explain it. Even a constrained assignment has these — why that data structure, why that error-handling approach, why you split those classes the way you did.

3. Add one feature nobody asked for

This is what makes it stop reading as coursework, and it does not need to be large.

Good candidates, roughly in order of effort:

• A search or filter over data the assignment only listed
• A CSV or JSON export
• A small REST API in front of what was a console application
• Input validation on the cases the sample data never triggered
• A basic web interface over a command-line tool
• Rate limiting, caching, or pagination if it talks to anything

One feature is enough. The signal is that you kept going after the mark was in.

4. Add a few tests

Not full coverage. Five meaningful tests beat a coverage badge.

Test the thing that would actually break: the loan-limit rule, the date calculation, the parser on malformed input. Then say in the README what is covered and what is not — being honest about the gaps reads better than implying coverage you do not have.

If you want a disproportionate return for fifteen minutes, add a GitHub Actions workflow that installs dependencies and runs those tests on every push. It is about fifteen lines of YAML and it puts a green tick on every commit in your history.

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

5. Handle the cases the marking scheme ignored

Assignments are graded against sample data. Real reviewers open a project and immediately do something unexpected.

Work through the obvious ones: what happens with an empty database, with a 500-character name, with a negative number, with a duplicate entry, when the external API is down, when a required field is missing. You do not need to handle all of them elegantly — you need the application not to crash with a stack trace on the screen.

An empty state is worth special attention. "No books yet — add your first one" is a small thing that makes a project feel finished rather than abandoned.

What this looks like as a before and after

Before: cs2043-assignment-3. No description. README contains the brief. Runs locally with a hard-coded SQLite path. No tests. Last commit message: "final".

After: library-lending-system. Description: "Lending system with loan limits and due-date tracking. Java, Spring Boot, Postgres." Deployed on Railway with OpenAPI docs. README opens with the problem, a live link and a screenshot, and explains why loan-limit enforcement was moved into a database constraint after two concurrent requests could both pass the service-layer check. Eight tests, running in CI.

That is roughly two evenings of work and the second version is not distinguishable from a personal project.

What not to do

Do not misrepresent it. If it was a group project, say so and say clearly which parts you wrote. Interviewers ask, and being caught overstating your contribution ends the conversation immediately.

Do not upgrade all of them. Pick your best two. Six upgraded assignments is worse than two, because a reviewer looking at six similar coursework projects sees a course, not a person.

Do not check the licence question too late. If the assignment includes starter code from your department, check whether you are allowed to publish it. Most of the time you are; occasionally you are not, and it is better to find out now.

The check

When you have finished, open the repository in a private browser window and read it as a stranger. If your first thought is "this is a university assignment", something in the framing is still doing that — usually the repository name, the README opening, or a folder called submission.

The README template and the GitHub profile guide cover the two halves of this in more detail.