Documentation Completion, Portfolio Assembly, and Project Defense

Documentation Completion, Portfolio Assembly, and Project Defense

This lesson brings your capstone project to its professional conclusion. You will finalize every piece of written documentation, assemble a polished portfolio entry, and present your work before a review panel. Each of these tasks reflects real workplace expectations: developers are routinely asked to document systems clearly, represent their work publicly, and defend technical decisions to stakeholders.

Completing Your Repository Documentation

A well-written README is often the first thing a reviewer, employer, or collaborator reads. Your README must include a project overview (what the application does and why it exists), the full technology stack, step-by-step setup and deployment instructions, known limitations or open issues, and a link to the live demo. Write for an audience that has not seen your code before — assume they are competent developers but know nothing about your specific project.

API documentation describes every endpoint your application exposes. Use Markdown tables or the Swagger/OpenAPI format (available at editor.swagger.io) to show the HTTP method, route, required parameters, request body format, and example responses for both success and error cases. Swagger/OpenAPI has the added advantage of generating an interactive documentation page automatically. Before you submit, exchange your API docs with a peer and ask them to follow the instructions cold — if they get confused, revise until the path is clear.

Your reflection report is a short professional document (typically one to three pages) that explains the choices you made, what you would do differently, and what you learned. Be honest about limitations. Reviewers — including potential employers — value self-awareness over overconfidence.

Assembling Your Portfolio Entry

Your portfolio is a living professional artifact. For this project, add three items: a one-paragraph project summary written in plain language (avoid excessive jargon), the URL of your GitHub repository, and a link to a three-to-five-minute screencast walkthrough.

Record your screencast using Loom or OBS Studio. Show the application running in a browser, walk through each major feature, and narrate what you are demonstrating. Keep the recording focused and professional — start a new recording if audio quality is poor or if you spend more than a few seconds on a dead screen. Upload the video to a stable public location (YouTube, Loom's shareable link) and confirm the link works from an incognito browser window before adding it to your portfolio.

Your portfolio platform (GitHub Pages or a personal site established earlier in the program) should present this entry alongside your other projects. A consistent visual layout and correct grammar across all entries signal professionalism.

Preparing for the Defense Presentation

Your slide deck should contain ten to fifteen slides. Plan for roughly one slide per minute, leaving time for natural transitions and panel questions. Recommended slide sequence:

1. Title slide — project name, your name, date

2. Problem statement — what real-world need does this application address?

3. Application architecture — diagram showing frontend, backend, database, and any external services

4. Technology stack and why you chose each component

5. Key technical decisions — for example, why you chose a particular authentication strategy or database schema design

6. Security measures implemented — input validation, authentication, HTTPS, environment variables for secrets

7. Testing approach and results — unit tests, integration tests, any coverage metrics you collected

8. Deployment process — hosting platform, CI/CD steps if applicable

9. Lessons learned and what you would do differently

10. Live demo reference or screenshot gallery

11. Questions slide

Practice your talk at least twice before the defense — once alone and once in front of a peer. Time yourself. Aim to finish the presentation portion in eighteen to twenty minutes so there is a natural pause before the panel begins its ten-minute question period.

During the Defense

Speak clearly and at a measured pace. When a panel member asks a question you cannot answer fully, it is appropriate to say, "I am not certain of the exact mechanism; my understanding is…" and explain what you do know. Guessing confidently and incorrectly is worse than honest uncertainty. Take a brief moment to organize your thoughts before answering complex questions.

Immediately after the session, complete your self-assessment using the provided defense rubric. Honest self-scoring helps you identify gaps even if you passed.

Scoring and Remediation

The panel scores your defense on technical accuracy, completeness of documentation, clarity of communication, and ability to answer questions. An average score of 70 percent or higher across all rubric domains is required to pass. If your average falls below 70 percent, the panel will identify specific areas for remediation. You will address those areas and repeat the defense within ten business days. Targeted preparation — not a complete redo — is the expectation, so take the panel's feedback seriously and act on it precisely.

Professional and Safety Considerations

Protect credentials and personal data throughout the documentation process. Never commit API keys, database passwords, or other secrets to a public repository — use environment variables and confirm your `.gitignore` file excludes `.env` files. If your application handles any user data, your documentation should acknowledge relevant privacy practices. These habits reflect the security awareness tested in your credentialing exams and expected by every professional employer.