Why do side projects count at all?
They count because the Digital Technology endorsement assesses you — your recognition, your contribution, your innovation — not your job title. The Tech Nation criteria ask for the mandatory criterion plus at least 2 of 4 optional criteria, and much of what satisfies those optional criteria lives outside a salaried role. A widely adopted open-source project, a tool other engineers depend on, or a product you built that found its own users is often a cleaner demonstration of individual impact than anything inside a large company, where your specific contribution is easily lost in a team.
This matters most for people whose employment is hard to evidence: engineers at service-based consultancies, staff on internal-only systems, or anyone whose best work sits under an NDA. A side project is public, attributable and yours — three qualities the assessment values highly. So the honest answer is not "side projects are second-best". A used library with a real dependency graph can outweigh the day job entirely.
When does a side project not count?
When nobody outside you uses it, engages with it or recognises it. This is the nuance that catches applicants out. The criteria do not reward the existence of a project; they reward the external evidence of impact a project generates. A private repository, a polished portfolio site with no users, or a hobby app with a handful of downloads shows that you can build — which is assumed — but not that the wider field noticed. Recognition that exists only inside your own head, or only among friends, is one of the recurring reasons applications are marked down.
There is also an attribution test. If a side project is genuinely a group effort, stating its success at team level ("our library reached 10,000 installs") without isolating what you did invites the same "insufficient evidence of individual impact" finding that sinks employer-based evidence. The exception, in short: a side project only counts to the extent that outsiders can see it, and to the extent that its impact is demonstrably yours.
How do I actually present a side project?
Present it as artefacts, not as a story. The evidence pack allows a maximum of 10 documents, each up to three sides of A4, so every side-project document must earn its place with hard, external proof. Reach for:
- Adoption metrics — package download or dependency counts, GitHub stars, forks and contributor lists, active-install figures, or npm/PyPI statistics with dates.
- Named adopters — organisations or well-known projects that depend on or integrated your work, evidenced by their own repositories, changelogs or documentation.
- Independent recognition — coverage in the tech press, a conference invitation to speak about the project, inclusion in a curated list, or community discussion you did not initiate.
- Clear individual attribution — commit history, maintainer status or a contribution breakdown that shows the innovation is yours, especially where others also contributed.
Then map each document to a specific optional criterion rather than leaving the assessor to guess. A side project usually supports the innovation or the technical-contribution criteria best; occasionally it supports recognition. Whether a given project "counts as supporting evidence" is a judgement the endorsing body makes on the strength of these artefacts — presenting it well tilts that judgement in your favour, but it is not a guarantee.
What is the most common mistake?
Describing the project instead of evidencing it. The most frequent error is a heartfelt paragraph about a clever thing you built, with screenshots of the interface and a link to the repository — and no numbers. The assessor cannot bank enthusiasm. Two projects can read identically in prose while one has 40,000 weekly downloads and the other has forty; only the artefacts tell them apart, so a project without external metrics is treated as if it has none.
The second mistake is timing. Evidence should sit within the recent window the criteria expect, so a project you were proud of five years ago, now unmaintained and unused, adds little. And a project spun up in the weeks before applying, with no organic adoption yet, reads exactly as it is. Recognition takes time to accrue; a side project persuades when its traction is real and dated, not freshly manufactured for the application.
Not sure your side project is strong enough to count?
Get a written, scored Fit Assessment — we tell you exactly which of your projects and roles evidence which criteria, and where the gaps are. Credited to any package within 14 days.
How does the £200 Fit Assessment help with this?
Because "does this count?" is a judgement, the useful thing is to have that judgement made before you spend £766 in government fees. The £200 Fit Assessment gives you a score out of 20 and a component-by-component breakdown across the mandatory criterion, the four optional criteria, your letters and your documentation. It tells you plainly whether a given side project reaches the bar, which optional criterion it best supports, and what metric or artefact would make it materially stronger.
You also receive a 10-document evidence plan, a Talent-versus-Promise route recommendation, and a 45-minute review call — a live walkthrough of the report where you can ask, project by project, "is this enough?". Every assessment fee is credited in full to any package you go on to buy within 14 days, so the diagnosis is not a sunk cost. It is the honest, dated answer to whether your side projects earn their place before you commit to a submission.
Frequently asked questions
Yes, a side project can count as supporting evidence when it shows real adoption, recognition or individual innovation — for example a widely used open-source library or a product with independent traction. It is one signal among several, not a guarantee of endorsement, and it strengthens an application most when it evidences an optional criterion the day job cannot.
A side project carries little weight when nobody outside you uses it, engages with it or recognises it. A private repository, a portfolio site with no users, or a hobby app with no downloads shows effort but not the recognition or innovation the criteria ask for. The measure is external evidence of impact, not the fact that the project exists.
Present it inside the 10-document evidence pack (each document up to three sides of A4) using hard external artefacts: dependency or download counts, GitHub stars and contributor lists, press or community coverage, and adoption by named organisations. Attribute your individual role clearly and map the project to a specific optional criterion, rather than describing the idea in prose.
It can contribute to it. If you created something genuinely new — a novel technical approach, a tool others adopted, or a product that opened a new use case — a side project can help evidence individual innovation. The assessment weighs whether the innovation is yours specifically and whether external parties recognised it.
Related reading: the 10-document evidence pack, does GitHub count as evidence?, individual impact vs company success, recommendation letter rules, who can be a referee, and the pain points hub.
Last updated: 6 July 2026. Facts verified against GOV.UK on 6 July 2026.