An unfinished project can be useful portfolio evidence when its status, working parts and unresolved issues are explicit. It should not masquerade as a completed product. Show what you have learned through actual decisions and checks, explain what prevents completion and give the reviewer a reliable way to inspect the current work without encountering misleading promises.
Build the evidence before polishing the presentation
Define the current state precisely. Separate implemented features, prototypes, planned work and known failures. A roadmap is an intention, not evidence that a capability exists. If a demo contains nonfunctional controls, label the limitation or remove the misleading interaction from the public path.
Choose a meaningful slice that can be inspected now. Document the problem, what you tried and what the result taught you. Explain a blocker in terms of the work rather than using a vague excuse. If you stopped deliberately because the approach was unsuitable, say why. Reflection becomes useful when it changes the next decision, not when it merely announces that the project was challenging.
| Area | Useful approach | What to check |
|---|---|---|
| Implemented | A feature or artefact that currently works as described | Provide a reproducible way to inspect it |
| In progress | Work partly completed with a clear present state | Explain what remains and avoid implying delivery |
| Planned | An intention for a later stage | Do not count it as demonstrated capability |
A fictional worked example
Fictional example: Omar is building a reading-list application. Adding and filtering items work locally, but account synchronisation is not implemented. His original portfolio calls it a complete cloud app. He changes the status to a local prototype, lists the working features and explains the missing synchronisation.
He provides a short demo of the functioning slice and documents a data-loss problem he discovered during testing. The next step is specific: revise persistence and test recovery before adding more features. The project now demonstrates investigation and honest progress without asking the reviewer to assume planned capabilities already exist.
Implemented
Show: A feature or artefact that currently works as described
Check: Provide a reproducible way to inspect it
In progress
Show: Work partly completed with a clear present state
Check: Explain what remains and avoid implying delivery
Planned
Show: An intention for a later stage
Check: Do not count it as demonstrated capability
Apply the process to your own material
- State: Label the project status and distinguish working, incomplete and planned parts.
- Isolate: Choose a meaningful current slice that a reviewer can inspect reliably.
- Explain: Document a real decision, blocker or failed approach and what it taught you.
- Prioritise: Define the next useful step before adding new scope or stronger claims.
Use an actual piece of your own work for this exercise, or create a clearly labelled practice example. Keep the original and revised versions so you can explain what changed. Ask a reviewer to identify the main contribution without additional explanation, then note where their interpretation differs from what you intended. Revise the evidence or wording that caused the mismatch rather than adding an unsupported claim to make the result sound stronger.
- State
Label the project status and distinguish working, incomplete and planned parts.
- Isolate
Choose a meaningful current slice that a reviewer can inspect reliably.
- Explain
Document a real decision, blocker or failed approach and what it taught you.
- Prioritise
Define the next useful step before adding new scope or stronger claims.
Move forward only when the previous step is clear enough to explain. A finished-looking file still needs a content and usability review.
Review the result before sharing
Decide whether the unfinished sample adds stronger evidence than a smaller completed project. If it mainly shows an idea with little working substance, keep it private while developing it. Check that links and instructions match the current state. Date the status where useful and update it when the work changes, so an old progress note does not become another source of confusion.
A closer check that strengthens the evidence
Distinguish a useful stopping point from an abandoned promise. A project can be intentionally limited because you answered the learning question or discovered that the original approach was unsuitable. Explain that decision and preserve a coherent artefact. By contrast, a page listing many broken features with no clear current purpose may not help a reviewer. Decide what the sample is meant to demonstrate now, then remove claims that depend on future work. This gives the project a truthful present-tense value even when you may return to it later, and avoids making the portfolio depend on intentions alone.
Common questions
Should unfinished projects appear in every portfolio?
No. Include one only when the current work provides useful evidence and its status is clear. A small complete sample may be stronger than an ambitious project with little inspectable progress. Consider the intended role and what the project demonstrates now, not what it might demonstrate if every planned feature were finished.
How should I label a prototype?
Use a plain status description and explain its scope. Distinguish a visual prototype from a working implementation, and a local demo from a deployed service. Labels should appear near the project introduction. Do not rely on a hidden limitations note to correct a title that implies a complete production product.
Can I show a failed approach?
Yes, if you explain the evidence, decision and resulting learning. A failed attempt can reveal judgement when it leads to a better next step. Avoid presenting failure as automatically impressive or filling the case study with excuses. The reader should understand what you tested and how it changed your understanding.
What if the demo has broken controls?
Fix, remove or clearly label them before sharing. A reviewer should not have to discover that a button is only decorative. If the work is a noninteractive prototype, say so. Accurate expectations make an unfinished sample easier to assess than a supposedly complete demo whose central interactions silently fail.
Does a roadmap count as portfolio evidence?
It can demonstrate planning, but it does not prove implementation or successful delivery. Keep planned work separate from completed capabilities. Explain why the sequence is sensible and what evidence would justify moving forward. Do not list future features in a way that makes them appear to be functioning parts of the current project.
How much detail should I give about blockers?
Enough to explain the current limitation and the next decision, without turning the page into a long apology. Name the technical, research or scope issue and describe what you have checked. Avoid blaming others or claiming a problem is impossible merely because you have not yet solved it.
Can I use an unfinished project in an interview?
Yes, when it is relevant and honestly framed. Be ready to demonstrate the working slice, explain the unresolved issue and discuss your next step. Do not let the conversation imply a completed result. A clear account of current evidence can support a useful discussion of how you investigate and learn.
When should I remove an old in-progress project?
Review it when the status is stale, the demo no longer works or it adds little evidence compared with newer work. You can archive it privately and keep a concise reflection if useful. A portfolio should represent your current capabilities accurately, not accumulate abandoned promises that a visitor cannot distinguish from active development.
Sources and further reading
Reviewed 7 November 2026. Examples and exercises are original editorial guidance. University advice reflects its own context; employer instructions and local requirements take priority.
Resume & Workplace Desk
MP Job Hub’s organisational byline for presenting genuine work and communicating clearly in professional settings.
Resumes · Portfolio evidence · Interviews · Workplace communication
View profile →Read our research process or request a correction.
