Should you put an unfinished project on your resume?

You have a project that works in parts and a deadline for applications. Here is how to decide whether it belongs on your resume, and how to word it honestly.

By Howard Davner

You have a project that does about 60 percent of what you planned. The login works, the main page loads, and the feature you were most excited about is half wired up. Applications are due, and you are wondering whether to list it, hide it, or spend another three weeks on it first.

The answer depends less on how finished the project is and more on whether the part that exists can be checked.

The short answer

Put it on your resume if all of these are true:

• Something real works. A person can use at least one complete flow from start to end.
• A reviewer can see it. There is a link that opens, or at minimum a short demo and a readable repository.
• You can explain every part of it. That includes the parts you did not finish.
• Your wording matches reality. Nothing in the bullet describes a feature that is not there.

Leave it off if the main feature does not run, if the link is broken, or if the honest version of the bullet would sound like a list of intentions.

Unfinished is not the same as unscoped

Most projects that feel unfinished are really projects that were never given an edge. If you never decided what "done" meant, then every missing feature looks like a failure. If you wrote down at the start that version one would do three things, and it does three things, then it is finished, and the other ideas are a roadmap.

This is the most useful reframe for a student with a half-built project. Go back and ask what the smallest version would be that still does something a stranger would understand. If you can cut to that version in a day or two, you probably have a finished small project hiding inside an unfinished large one.

For example, suppose you planned an app that imports a spreadsheet of expenses, categorizes them, charts them, forecasts next month and sends alerts. If import, categorize and chart work, that is a complete project. Forecasting and alerts are version two. Cut them from the interface, move them to the README and stop apologizing for them.

How a recruiter reads this

A recruiter or hiring manager skimming a junior resume is not grading ambition. They are asking a simpler question: is there evidence this person can build something that works? A project link they can open in a few seconds answers that. A bullet that says "building a platform that will..." does not, because the reader cannot check any of it.

There is also a trust cost. If a reader opens your link and finds that a headline feature is a button that does nothing, they will discount everything else on the page. A smaller claim that holds up is worth more than a bigger claim that cracks.

How to word the bullet

Describe what runs today, in the past tense, with the concrete thing a user can do.

Weak:

• Developing an AI-powered finance platform with budgeting, forecasting and alerts.

Better (example wording):

• Built a web app that imports a CSV of expenses, sorts them into categories and charts spending by month; deployed with a public demo.

The second version claims less and proves more. It names the input, the processing and the output. A reader can open the link and confirm each piece.

A few rules for the wording:

• Do not use "developing" or "working on" as a hedge. Either it does the thing or it does not. If it does, say so.
• Do not list technologies for features you did not build. If the forecasting model is not there, do not mention the library you planned to use.
• Do not invent impact. No made-up user counts or performance numbers. If you have a real number you can defend, use it. If not, describe what the app does.
• Keep it to what you can explain. If an interviewer asks how the categorization works, you need an answer that is not "the tutorial did it."

Put the rest in the README

The README is the right place for honesty about scope. Add a short section called something like "Status and next steps" with two lists: what works now, and what is planned. This does three things.

• It shows you can scope and prioritize, which is a real skill on a junior team.
• It sets expectations before anyone clicks around looking for features.
• It gives you something concrete to talk about in an interview.

Keep it short. Three or four items per list is plenty. Do not write a manifesto.

When to leave it off

Sometimes the right call is to cut the project from this round of applications:

• It only runs locally. If no one can see it work, it is closer to a claim than a project. Either deploy it or hold it back.
• The core feature is broken. A demo that fails on the first click does more harm than having no demo.
• You cannot explain your own code. This happens when most of a project came from a tutorial, a template or generated code that you never read through. That is fixable, but fix it before you list the project.
• It duplicates a stronger project. Two similar projects, one finished and one not, only make the weaker one visible. List the finished one.

Leaving something off is not a loss. A resume with one project that holds up reads better than one with three where two fall apart.

What to say in an interview

If the project comes up, the unfinished parts can help you. A clear account of tradeoffs is something interviewers often want to hear from junior candidates, and most people never give one.

A structure that works:

• What I set out to build. One sentence.
• What I shipped. The working flow, shown if you can.
• What I cut, and why. For example, "I dropped forecasting because the categorization needed to be reliable first."
• What I would do next. One concrete step, not a wish list.

This tells the interviewer you can make decisions under a deadline. Do not apologize, and do not oversell. Just describe what is true.

Decide in ten minutes

Open your project in a private browser window, as if you were a stranger, and ask:

• Does the link load?
• Can I complete one real task in under a minute?
• Is anything on the page promising something that does not work?
• Could I explain each piece to an interviewer?

If the answers are yes, yes, no, yes, list it. If not, spend a day or two fixing the specific gap, not adding features. Cut the broken button, write the README status section and redeploy.

Scoping it right from the start

Most of this problem comes from scope set too wide at the beginning. If you want to avoid it next time, start from a specific job description, pick the two or three skills it asks for, and define a version one that demonstrates them and can be finished and deployed. Provieo is built around that sequence: it takes a job description and helps you scope, build and deploy a project, so the end result is a working link rather than a repository full of intentions.

Whichever way you work, the principle is the same. A project is ready for your resume when someone else can open it and see that it works.

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.