How Do I Turn a Class Project Into Something a Recruiter Can Actually Click?
Your class project is a zip file, a notebook, or a repo that no longer runs. Here is how to get it to a working URL, and the four things you have to strip out first.
By Howard Davner
Quick Answer: Deploy it. A class project becomes clickable the moment it has a URL that opens in a browser with no setup. Before it goes up, strip the four things tying it to the course — hard-coded paths, the class dataset, the campus database, any committed key — and check what your syllabus allows.
You have a folder. Inside it is the thing you spent six weeks on, and it works — on your laptop, with the dataset from the course page, on the Python version the lab machines had in February.
That folder is not evidence yet. Nobody outside your course can open it, run it, or tell what it does. The distance between "I built a course-scheduling app" on your resume and something a stranger can verify is one URL, and closing that distance is mostly a cleanup job, not a rebuild.
What you actually have right now
Class projects come out in three shapes, and each one fails a stranger differently.
A notebook. It runs top to bottom in the order you last ran it, which may not be the order the cells are in. Pushed to GitHub, it renders as a static preview — a reader sees whichever output cells you happened to save and cannot change a single input.
A zip file. Submitted to the course portal, never opened since. Nothing about it is reachable.
A repo that no longer runs. This is the common one. The requirements.txt pins whatever the lab machines had, there is a pd.read_csv("/Users/you/Desktop/cs340/train.csv") on line 12, and the database it talks to lives behind the campus VPN.
All three have the same problem: they require the reader to do work before they see anything. That is the whole reason a GitHub link on its own does not function as a portfolio — not because the code is bad, but because looking at it costs the reader more than they are willing to spend.
Check the syllabus before you deploy anything
This step gets skipped in every guide on the internet, and it is the one that can actually cause you a problem.
Plenty of courses reuse assignments term after term, and their academic integrity policy treats a public solution as a violation whether or not you are still enrolled. Problem sets and graded exercises are the risky category. Open-ended work is usually the safe one: a capstone, a final project you scoped yourself, a hackathon build, anything where the specification was yours.
If the syllabus does not say, ask the instructor in writing and keep the reply. If the answer is no, you have not lost anything — take the technique you learned and point it at a different problem. The rebuild is faster the second time, and the result is unambiguously yours.
Strip the four things that keep it local
Hard-coded paths. Every absolute path that starts with your home directory becomes a relative path or an environment variable. This is usually a ten-minute find-and-replace and it is the single most common reason a project runs for you and nobody else.
The class dataset. Do not republish it reflexively. It may be licensed to the institution, scraped under terms you never read, or contain real records. Substitute a comparable public dataset and say so in the README, or ship a small synthetic sample so the app has something to run on.
The campus database. If it lives behind the university network, nothing you deploy can reach it. Move to a SQLite file committed alongside the code, or a managed Postgres instance you control.
Credentials in the repo. Move keys to environment variables, then rotate them, because git history keeps the old ones. git log -p | grep -i "api_key" will usually find what you forgot. If the history is messy, starting a clean repo is often faster than scrubbing it.
Pick the host by what you built
| What you have | Where it goes | What a visitor sees | |---|---|---| | Notebook or trained model | Hugging Face Spaces, wrapped in Gradio or Streamlit | An input box and a real result | | Frontend or static site | Vercel or Netlify | The app itself | | API or backend service | Render, Railway or Fly.io | A page that calls it live | | Analysis or dashboard | Streamlit Community Cloud | Charts they can change |
One tradeoff to plan around: on several of these, a no-cost plan puts an idle app to sleep and the first visitor waits for it to wake. Open your own link from a phone on mobile data before you put it anywhere. A slow blank screen reads as broken.
Rename it and write one sentence
COMP3700-assignment2 tells a reader nothing. Rename the repo and the deployed app after what the thing does.
Then write the first line of the README as one plain sentence describing what happens when someone opens it — not the stack, not the course, not the team. The stack goes underneath. This is the same discipline that makes a deployed project work as resume evidence: the reader should understand the point before they scroll.
The hard part is scope, not deployment
Most class projects survive this trip fine. The ones that do not usually fail for the same reason: they were scoped to a rubric, not to a job. A project built to demonstrate three sorting algorithms deploys perfectly and still says nothing to someone hiring for a data role.
That is the gap Provieo's project builder exists to close. It starts from a real job description, scopes a project against what that role actually asks for, and takes it through to a deployed URL you can put in an application — so the scoping problem and the deployment problem get solved in the same pass rather than one of them getting solved twice.
If your class project already matches the kind of work you are applying for, deploy that one. Do the cleanup, get the URL, click it yourself from a device that has never seen the code. If it opens and does something, you no longer have a folder. You have something a stranger can check.
Frequently Asked Questions
How do I turn a class project into a portfolio project?+
Deploy it so it has a URL that opens in a browser with no setup. Before you can, remove the four things that tie it to the course: hard-coded file paths, the dataset the class provided, any database or service that only exists on the campus network, and credentials committed to the repo. Then pick a host that matches what you built. A notebook or model goes to Hugging Face Spaces wrapped in Gradio or Streamlit. A frontend goes to Vercel or Netlify. An API goes to Render, Railway or Fly.io. The code does not change. What changes is that someone can now check it without asking you for anything.
Am I allowed to publish a class project publicly?+
Check your syllabus before you deploy, because the answer differs by assignment. Many courses reuse problem sets across terms and their academic integrity policy forbids publishing solutions where future students can find them. Open-ended work is usually treated differently from graded exercises, and a capstone or final project you scoped yourself is normally yours to show. If the syllabus is unclear, ask the instructor in writing and keep the reply. If the answer is no, build something adjacent using what you learned rather than publishing the assignment itself.
Where can I deploy a class project without paying for hosting?+
Vercel and Netlify host frontends and static sites at no cost. Render, Railway and Fly.io run small backends and APIs. Hugging Face Spaces runs machine learning demos through Gradio or Streamlit. Streamlit Community Cloud runs data apps straight from a repo. The tradeoff worth knowing: no-cost plans on several of these put an idle app to sleep, so the first visitor waits for it to wake up. A recruiter who clicks a link and sees a blank loading screen usually reads it as broken, so test the link cold before you send it anywhere.
My class project needs a dataset the professor gave us. What do I do?+
Do not republish it by default. Course datasets are often licensed to the institution, scraped from somewhere with terms attached, or contain real records that were never meant to leave the class. Three options work: swap in a comparable public dataset and note the substitution in the README, ship a small synthetic sample that lets the app run so a visitor can see the behaviour, or keep the model and drop the raw data entirely so the deployed version only accepts input the visitor supplies.
Is a GitHub link enough if I cannot deploy the project?+
It is weaker, and you should treat it as a fallback rather than the plan. A notebook on GitHub renders as a static preview: a reader sees the output cells you happened to save, but cannot run anything or change an input. If deployment is genuinely blocked, do the next best thing, which is to record a short screen capture of the project running and put that in the README above the fold, so the first thing a visitor sees is the thing working.
Put a working link in your next application.
Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it — so what a recruiter clicks is the work itself, not a description of it.
Free to use, and your first deployed project is free. Or tailor your resume to the same posting.