Final Year and the Capstone¶

For students approaching or completing their final-year project

The Most Significant Professional Moment of Your Degree¶

The final-year project or capstone is the most complex, most sustained, and most professionally relevant work most students produce during their degree.

It is also the work most students fail to capitalise on.

They complete it, submit it, receive their grade, and move on — leaving behind the most compelling professional evidence they have produced, in a format that no employer will ever read (a formal academic report) and on a platform that was never designed for professional visibility (an institutional submission system).

If this is your situation, Itan exists partly for you.

The final-year project, properly documented and interpreted, is the centrepiece of a Stage Ⅱ portfolio. It demonstrates sustained engagement with a complex, real-world problem over an extended period. It shows how you work under pressure, how you make decisions under constraint, how you handle difficulty, and what you produce when given significant autonomy. These are exactly the qualities that professional employers are trying to evaluate.

The challenge is not finding the material. The material exists. The challenge is translating it from its academic form into its professional form.

If You Used Vestigia¶

If you have been using Vestigia throughout your final-year project, you are in a significantly stronger position than students who are approaching this retrospectively.

Your Guide A records contain what most students lose: the real-time account of decisions made, problems encountered, and learning as it happened. Your Guide B extraction work has already identified what mattered, connected your thinking to real project artefacts, and shaped a narrative from the material.

What Itan provides is the next layer:

◆ Framing within a wider portfolio — your Guide B output is the capstone case study. Itan shows you how to place it within the context of a full portfolio that includes earlier work, a professional bio and positioning statement, and a consistent identity across platforms.

◇ Calibrating for professional audiences — Guide B was written for the transition from student record to professional showcase. Itan helps you calibrate that showcase further — for specific roles, specific audiences, and specific professional contexts.

◆ The master portfolio and tailored versions — your capstone case study is the centrepiece of your master portfolio. Itan's guidance in Part Ⅲ — Master Portfolio and Tailored Versions shows you how to draw targeted portfolios from it for different applications.

◇ Platform strategy — your Vestigia records and Guide B output live in a GitHub repository. Itan helps you connect that to a wider platform presence — LinkedIn, a personal site, and any discipline-specific platforms relevant to your field.

If you have Vestigia output, your starting point for the capstone case study is already substantially complete. Move to the structuring and framing guidance below.

If You Are Working Retrospectively¶

Not every final-year student will have kept systematic records during the project. If you are working retrospectively — building the portfolio after the project is complete, from memory and from the project artefacts — the guidance in Part Ⅲ — Retrospective Gathering applies directly.

The specific challenge for a retrospective capstone case study is that the project was long and complex — more material existed than for most earlier projects, but also more time has passed, and the specific decision reasoning may be less clear than it was in the moment.

Work through the retrospective process systematically:

◆ Gather all artefacts first — your report, your codebase or design files, your presentation materials, your meeting minutes, any supervisor feedback, any client communication. These are your primary source material.

◇ Identify the three to five most significant decisions in the project — the ones that shaped the direction most substantially. These are usually visible in the artefacts: a design that reflects a significant choice, an architecture that had alternatives, a methodology that was chosen over competing approaches.

◆ Recover the difficulty — what was the hardest part? What did not work at first? What required a rethink? This is often easier to remember than specific decision details, because difficulty tends to leave a stronger trace.

◇ Use your supervisor meetings — if you have any record of supervision conversations, or if you can recall the themes of those meetings, they often contain the most honest account of what was genuinely challenging and what changed across the project.

◆ Write from what is solid — begin the case study from the elements you can speak to most specifically. The project context, the problem, and the outcome are usually clearly recoverable. Build the decision and difficulty sections from there, using what is genuinely available rather than what you wish you had documented.

Structuring the Capstone Case Study¶

The capstone case study is the longest and most detailed entry in a Stage Ⅱ portfolio. It earns that length because the project warrants it — not because length demonstrates effort.

Apply the universal structure from Part Ⅳ — The Universal Structure with these calibrations for a capstone entry:

Context — name the project, the duration, your role, and whether it was individual or group. For group projects, establish immediately what your individual responsibility was. This framing prevents ambiguity about whose work the reader is evaluating.

Problem — describe the real-world problem or challenge the project addressed, not the academic brief. The brief describes what was required. The problem describes what mattered. These are related but not identical.

Approach and decisions — for a capstone project, two to four decisions are appropriate. These should be the ones with the most consequence — where the project's direction, technical approach, or methodology was most substantially shaped. Each decision should be developed with its alternative, its reasoning, and its accepted trade-off.

Difficulty — the capstone almost certainly produced significant difficulty. One to two well-developed difficulty accounts, each connected to what changed as a result, is stronger than a comprehensive list of everything that went wrong.

Outcome — what was produced, where it can be found or accessed, and an honest assessment of how well it addressed the original problem. Link to the repository, the deployed system, the published report, the design file — the primary artefact that proves the work existed and reached a real conclusion.

Reflection — the most substantive reflection you have written in any portfolio entry. A project of this duration and complexity produces real learning. Identify the most significant change in your understanding — the one that will demonstrably affect how you approach the next project — and write it with specificity.

Incorporating Earlier Work¶

A Stage Ⅱ portfolio should not consist only of the capstone.

Two to four supporting entries from earlier in your degree serve two purposes: they demonstrate that your capability predates the final year, and they show a trajectory — the difference between your earliest documented work and your capstone is evidence of growth that the capstone alone cannot provide.

Select supporting entries using the curation principles from Part Ⅲ — What Belongs. Quality and narrative alignment matter more than recency or grade. An earlier project that demonstrates a specific thinking process, an honest engagement with difficulty, or a distinctive approach is more valuable than a higher-graded project that cannot be specifically explained.

Supporting entries at Stage Ⅱ can be shorter than the capstone — 300 to 500 words using a compressed version of the universal structure. Their job is to provide context and demonstrate range, not to compete with the capstone for the reader's attention.

The Group Project Question¶

Most final-year projects involve group work. The individual portfolio challenge this creates is not unique to Itan — it is the challenge Vestigia was built to address at the recording stage, and it persists into the portfolio stage.

The principle is the same in both contexts: present your individual contribution specifically and honestly, acknowledge the collaborative context clearly, and attribute shared work fairly.

Practical guidance for the portfolio:

◆ establish your individual role in the opening frame of the case study — not generically ("backend developer") but specifically ("I was responsible for the database schema design and all API endpoints, and made the lead architectural decisions for the server layer")

◇ when describing decisions, be clear about which were yours, which were collaborative, and which were made by others. Claiming collaborative decisions as solely yours is a misrepresentation. Omitting your individual decisions because the project was collaborative undersells you.

◆ link to the shared repository and the shared artefacts — these demonstrate the collective work — while the case study demonstrates your individual thinking within it

◇ if your group built a shared project website as part of a Shared Presence practice, link to it as additional context. It provides the group frame within which your individual contribution sits.

The Timeline Pressure¶

Final year is the most time-pressured period of a degree. Building a portfolio alongside the project, the assessment requirements, the job search, and the personal demands of the final year is a genuine challenge.

Two practical framings that help:

The portfolio is not separate work. The documentation you produce for your portfolio is built from material you are already producing — project records, design decisions, meeting outcomes, testing results. The case study is not a new document — it is the interpretation of material that already exists.

The best time to write the capstone case study is immediately after submission. The project is complete, the details are still clear, and the reflection is available before the distance of time softens the honest account. A case study written the week after submission is almost always better than one written three months later.

Continue to Postgraduate — The Translational Model →