Building Quickly from Existing Work¶

For students and professionals who need a portfolio soon, working from existing but undocumented work

The Situation¶

You have existing work. You have not documented it for a portfolio. You need something credible, soon — for an application, an interview, a professional conversation, or a programme that starts in weeks.

This is a recoverable position. It is not the ideal position — the ideal is a portfolio built consistently over time, with documentation produced as each project happened. But it is the real position many students and professionals find themselves in, and it deserves direct, honest guidance rather than advice to start earlier next time.

This document is that guidance.

What You Are Working Against¶

Building quickly from existing work has two genuine constraints that need to be understood before beginning.

The honesty constraint
The specific detail that makes a strong portfolio entry — the decision reasoning captured in the moment, the honest account of difficulty as it was experienced, the reflection written before the outcome was known — is harder to produce retrospectively. Not impossible, but harder. The guidance here is calibrated to what is achievable honestly, not what would be ideal.

The time constraint
A complete, polished portfolio across five disciplines, twelve entries, and four platforms is not a reasonable goal in two weeks. A credible, honest portfolio with two to three strong entries, a current bio, and a consistent platform presence is. The goal of building quickly is not a finished portfolio — it is a defensible portfolio that can be extended over time.

Hold both constraints clearly. They define what success looks like here.

The Rapid Inventory¶

Before writing anything, spend sixty minutes doing a rapid inventory of everything you have produced.

Work through each of the following:

◆ Completed projects — academic, professional, personal, open source, volunteer. Every project that involved real decisions and produced a real outcome.

◇ Artefacts — code repositories, design files, reports, presentations, data notebooks, prototypes, videos, publications. The things that exist and can be linked or shown.

◆ Any existing records — emails that captured decisions, meeting notes, supervisor feedback, client communication, version history in a repository. Anything that preserves a trace of what happened and why.

◇ Memory prompts — for each project, what is the one decision you remember most clearly? The one thing that went wrong? The outcome you are most certain about?

Write this inventory as a list — quickly, without evaluating. Everything goes in. The selection happens next.

Selecting the Two or Three Strongest Entries¶

From the inventory, select the two or three entries that best meet these criteria:

Ⅰ — You can speak to it specifically
You remember enough detail to describe at least one decision and one difficulty with genuine specificity — not vague recollection, but something you could explain clearly in a five-minute conversation.

Ⅱ — The artefact exists and is accessible
There is something to point to — a repository, a file, a deployed system, a published document. Something that grounds the case study in verifiable reality.

Ⅲ — It advances your narrative anchor
It connects to the professional direction you are presenting. Even a two-entry portfolio should tell a coherent story about who you are and what you can do.

Ⅳ — It can be documented honestly
You are not going to fabricate decision reasoning or invent difficulty. The entry you select should be one you can document at whatever depth is genuinely available — not at the depth you wish you had recorded.

If two entries meet all four criteria, build two strong entries. If three meet them, build three. Do not build five weak entries in order to appear more comprehensive.

The Rapid Case Study Process¶

For each selected entry, work through the following in order. Set a time limit — ninety minutes per entry is achievable for a first draft.

Step Ⅰ — Write the context and problem first (15 minutes)¶

Start with what is most clearly recoverable: what the project was, when it happened, what your role was, and what problem it was addressing.

Do not edit as you write. Write quickly and factually. The project name, the duration, the client or context, the problem in two or three sentences.

This is the part most people can write without difficulty. Getting it down first creates momentum for the harder sections.

Step Ⅱ — Identify the one decision you remember best (20 minutes)¶

From the project, identify the single decision you can describe most specifically — the one where you remember the alternatives considered, the reasoning, and the consequence.

Write it out:

◆ what was decided
◇ what the main alternative was
◆ why this path was chosen
◇ what happened as a result

If you remember two decisions at this level of specificity, include both. If you remember only one, one is enough. Do not include decisions you cannot actually explain — a decision described vaguely is weaker than no decision at all.

Step Ⅲ — Write the difficulty honestly (20 minutes)¶

What went wrong, or what was hardest? Even at the general level, this section needs something. Write what you genuinely remember.

If the specific detail is gone, write at the level available:

"The most significant challenge in this project was integrating the payment gateway — the documentation was inconsistent and the test environment behaviour did not match production. We resolved it by [X], which added approximately [Y] to the timeline."

That is honest and specific enough to be credible, even if it does not reach the depth of a real-time record. It is better than omitting the difficulty entirely.

Step Ⅳ — State the outcome and link the artefact (15 minutes)¶

What was produced? Where can it be found?

Be specific about the outcome. Avoid vague success language. If the project produced a deployed system, a published document, a completed campaign, or a delivered intervention — say so, and link to it.

If the outcome was less clear — a project that was submitted but not deployed, a proposal that was not implemented — be honest about this. "The project produced a strategy proposal accepted by the client; implementation began after the project scope concluded" is a legitimate and credible outcome.

Step Ⅴ — Write the reflection (20 minutes)¶

What would you do differently? What does the project, viewed now, tell you about how you would approach this type of work going forward?

Retrospective reflection has an advantage over real-time reflection in one specific way: you know how it turned out. You can identify, with hindsight, the decision that most shaped the outcome and what a better-informed version of that decision would have looked like.

Write that. It is honest, it is specific, and it demonstrates the self-awareness that makes a portfolio entry worth reading.

Writing the Bio Under Time Pressure¶

While the case studies are your primary effort, do not neglect the bio. A bio that was written in first year and reflects where you were then, placed next to case studies from your final year, creates a jarring inconsistency.

Spend thirty minutes on a current bio using the guidance from Part Ⅱ — Writing Your Bio and Positioning.

Write it for where you are right now. It does not need to be polished — it needs to be current and honest. It can be refined after the immediate pressure has passed.

Platform Priorities Under Time Pressure¶

When building quickly, focus on one platform and ensure it is credible before expanding to others.

For CS, IT, and Engineering students — GitHub is the priority. Update the profile README, pin the strongest repository, and ensure the repository for your primary case study has a clear README. A strong GitHub profile alone is a credible professional presence for technical disciplines.

For Design students — one Behance case study, produced to the standard described in Part Ⅴ — Design and UX, is more valuable than a half-built personal website.

For all disciplines — update LinkedIn. A current headline, a current summary, and a featured link to your strongest work is enough to establish a coherent presence. A LinkedIn profile that reflects who you are now, linked to whatever artefacts exist, is a defensible professional presence for any application.

What to Say in the Application or Interview¶

If you are building quickly because of an imminent application or interview, be aware of the distinction between what your portfolio contains and what you are able to speak to in conversation.

A portfolio built quickly from retrospective material is a starting point. In conversation — in an interview where you are asked to walk through a project — you can go further than the portfolio text, drawing on memory that is richer than what the written entry captured.

The portfolio tells the reader what to ask about. The conversation is where you demonstrate what you know.

Prepare for the conversation by going back through each entry and asking:

◆ if someone asks me to expand on this decision, what would I say?
◇ if someone asks what I would do differently, what is my specific answer?
◆ if someone asks about the difficulty, can I describe the diagnosis process?
◇ if someone asks for the outcome in more detail, what do I have?

The answers to these questions are your interview preparation. The portfolio created the opportunity; the conversation closes it.

After the Immediate Pressure Passes¶

Once the application, interview, or professional moment has passed, the portfolio you have built quickly becomes the foundation for one built properly.

The two or three entries you produced under time pressure are almost certainly not as deep as they could be. Return to them when you have more time — add the decision detail you did not have, improve the reflection, link the artefacts more completely.

And for the next project: document it while it is happening.

The difference between a portfolio built quickly from memory and a portfolio built from real-time records is not the difference between bad and good. It is the difference between good and genuinely compelling. The effort of building quickly teaches exactly what the habit of ongoing documentation would have prevented.