Overview
Final-year projects, capstones, master's software theses and research tools share a problem: most of the assessment or impact depends on things other than whether the code runs. Examiners and reviewers look for justified requirements, a coherent architecture, evidence of testing and documentation a stranger can follow. These are often left until the last week.
We support the project lifecycle as advisers and reviewers. For students, that means reviewing your requirements and design documents, explaining UML notation, commenting on your repository structure and documentation drafts, and coaching you on how to present design decisions. For researchers and small teams, we can also write documentation, configure documentation generators and continuous integration, and prepare software for release or publication.
Documentation is treated as part of the software. We favor formats that live in the repository and are built automatically, so the documentation does not drift away from the code it describes.
Who it’s for and the problems it solves
This is for you if you are…
- Undergraduate and master's students on capstone, final-year or team software projects
- Master's and PhD researchers whose thesis includes a software artifact
- Research software engineers and labs preparing a tool for release, a software paper or archiving
- Small technical teams and startups that need a documentation baseline
- Instructors who want example documentation standards for student projects
Common problems we help with
- Your project report must include UML diagrams and you are unsure which ones, or how detailed
- The code works but the repository has no README, no install instructions and no tests
- Your supervisor asked for an architecture justification and you only have the implementation
- Docstrings are inconsistent, so generated API documentation looks empty or broken
- You plan to publish your research software and do not know what a citable release requires
What’s included — and what isn’t
Included
- Review of requirements specifications: functional and non-functional requirements, user stories, acceptance criteria
- Architecture and design review: layering, modularity, coupling and cohesion, common design patterns and where they fit
- UML coaching and review: use case, class, sequence, activity, state machine and component diagrams, with tool advice (PlantUML, Mermaid, draw.io, StarUML)
- Repository structure advice: source layout, configuration, tests, examples, licenses and .gitignore
- README review or writing (for research and professional clients): purpose, installation, quick start, usage, citation and contribution sections
- Docstring conventions: Google, NumPy or reStructuredText styles in Python, Javadoc, Doxygen for C/C++, roxygen2 for R, JSDoc
- Documentation sites with Sphinx (autodoc, Napoleon, Read the Docs) or MkDocs (including the Material theme and mkdocstrings)
- Testing and continuous integration guidance: unit tests, coverage reports and GitHub Actions or GitLab CI pipelines that build docs and run tests
- Preparation for software release and citation: semantic versioning, CHANGELOG, CITATION.cff and archiving with a DOI (for example via Zenodo)
Not included
- Building or completing a graded student project, or writing a project report that will be submitted for assessment
- Writing reflective sections, individual contribution statements or peer assessments on a student's behalf
- Maintaining commercial production systems or providing ongoing operational support
- Security audits or compliance certification of software
What you receive
- Design review memo
- Written comments on your requirements, architecture and diagrams, with the strongest issues listed first and suggested questions to discuss with your supervisor or team.
- Annotated UML feedback
- Your diagrams marked up with notation corrections and consistency checks against the code, or, for professional clients, diagrams produced as PlantUML or Mermaid source.
- Documentation audit
- A checklist-based review of README, docstrings, API reference and user guide, with gaps prioritized.
- Documentation build setup
- For research and professional clients: a configured Sphinx or MkDocs project, docstring templates and a CI workflow that rebuilds documentation on each push.
- Release checklist
- Steps for versioning, changelog, license, citation file and archival deposit, tailored to your repository.
How it works
Project intake
You share the brief or project goals, the repository and any assessment criteria or style guides. We confirm whether this is assessed student work, research software or professional work.
Review
We read the code structure, design documents and existing documentation, and note the most significant gaps.
Feedback and coaching
We discuss findings in a session, explain the reasoning behind each recommendation and agree priorities.
Build or revise
Students revise their own documents and diagrams with follow-up review; for research and professional clients we can implement the documentation and CI setup directly.
Handover
You receive written notes, templates and a short walkthrough of how to keep documentation current as the code changes.
Documentation formats and tools
- Diátaxis-style structure
- Separating tutorials, how-to guides, reference and explanation so each document has one purpose and readers find the right one.
- Sphinx
- Python-ecosystem documentation generator using reStructuredText or Markdown via MyST, with autodoc for API references and hosting on Read the Docs.
- MkDocs
- Markdown-based static site generator configured with a YAML file, with a live-reload preview and plugins such as mkdocstrings for API documentation.
- Doxygen, Javadoc, roxygen2, JSDoc
- Language-native tools that generate references from structured comments in C/C++, Java, R and JavaScript.
- UML as code
- PlantUML and Mermaid diagrams stored as text in the repository, so they are versioned and reviewed with the code.
- Architecture decision records
- Short dated notes explaining why a design choice was made, which help in viva questions and in team handovers.
Choosing the right UML diagrams
UML has many diagram types, and reports often include too many at too little depth. A use case diagram with brief descriptions frames scope; a class diagram shows the static structure of the core domain; one or two sequence diagrams show the most important interactions. State machine diagrams earn their place when an object has a genuine lifecycle, such as an order or a device connection. We help you choose diagrams that answer an examiner's likely questions and make sure they match the code.
What a useful README contains
A README is the front door of a repository. Readers should know within a minute what the software does, whether it fits their need and how to run it.
- One-paragraph purpose statement and project status
- Requirements and installation steps that work on a clean machine
- A minimal usage example with expected output
- Links to fuller documentation, license and how to cite
- How to run tests and how to contribute or report issues
Research software that can be cited and reused
Software written for a thesis or paper is increasingly expected to be archived and cited. A tagged release, a CITATION.cff file, an open license and a DOI from an archive make your software findable and give others a stable way to credit it. If you plan a software paper, for example in the Journal of Open Source Software, we can review your repository against the journal's published checklist, but acceptance decisions rest with the journal.
What the work can look like
Illustrative example — fictional data
Sample documentation audit excerpt for a research tool
A postdoctoral researcher asked for a review of a Python package for processing microscopy metadata before releasing it to collaborators. Details are invented to show the format.
High priority
Installation instructions assume a local Conda environment that is not included in the repository. Add an environment.yml with pinned versions and test installation in a clean container or CI job.
Medium priority
About 40% of public functions have no docstring, and the rest mix Google and NumPy styles, so Sphinx autodoc output is inconsistent. Standardize on NumPy style (common in scientific Python) and enable the Napoleon extension.
Release readiness
No license file or CITATION.cff is present. Choose a license with your institution's technology transfer office if required, add citation metadata and tag version 0.1.0 before sharing.
Illustrative example with invented findings. Real audits reflect your repository, your audience and your institution's policies.
What you’ll need to provide
- Repository access or an archive of the code
- Project brief, marking rubric or supervisor guidance where relevant
- Existing requirements, design documents and diagrams
- Target audience for the documentation (examiners, users, developers)
- Preferred tools and hosting (GitHub, GitLab, institutional servers)
You don’t need everything ready to ask for a quote — tell us what you have and we’ll say what’s missing.
What affects price and turnaround
Price depends on
- Size of the codebase and number of modules to document
- Review and coaching only, or documentation and CI implementation for research and professional clients
- Number and complexity of UML diagrams to review or produce
- Whether a hosted documentation site, release process or software paper preparation is included
Turnaround depends on
- Access to the repository and a working build at the start
- Number of review rounds you want before your deadline
- Availability of the team or supervisor to confirm design intent
Every project is quoted individually. How we price our work.
Questions people ask before starting
Can you write the report for my capstone or final-year project?
No. The project report and code are assessed as your work. We review your drafts, explain design and documentation conventions, comment on your UML diagrams and help you prepare to explain your decisions. Check your module rules on outside feedback; some projects require you to declare it.
Which UML tool should I use?
Use what your course expects. If there is no requirement, text-based tools such as PlantUML or Mermaid work well because diagrams live in the repository and render in many platforms; draw.io and StarUML suit people who prefer visual editing. What matters is that notation is correct and diagrams match the code.
Sphinx or MkDocs?
Sphinx is the long-established choice for Python projects that need detailed API references, cross-referencing and PDF output. MkDocs is simpler to configure and write in Markdown, and with plugins it can also generate API references. We recommend based on your language, team habits and hosting.
Do you document non-Python projects?
Yes. We work with Javadoc for Java, Doxygen for C and C++, roxygen2 and pkgdown for R packages, and JSDoc or TypeDoc for JavaScript and TypeScript.
Is our code kept confidential?
Yes. Repository access is used only for the agreed work, and we can work from a private fork or an archive. Tell us if the code is under a non-disclosure agreement and we can sign one.