A developer portfolio should show what you can really do. A developer portfolio becomes even more convincing when it is based on real code rather than mere claims.
If you are looking for guidance on what belongs in a strong portfolio, how to present real work credibly and how not to rely solely on self-promotion, you are in the right place. This text is aimed at developers applying for roles and freelancers who want to show new clients how they work in a way that can be understood and assessed.
In practical terms, it covers how to
- not just present projects,
- make work from the Git repository verifiable through the Proof Engine methodology,
- hold proof for developers with a free repo audit,
- and understand how companies verify credentials and how the pricing model works.
The focus is on trust, traceability and your ownership of the proof.
What a good developer portfolio needs to do today
A good developer portfolio today is more than a polished gallery of screenshots, project logos and a few impressive terms. That may create a first impression. But it often does not answer the real question: how do you actually work in a codebase?
Particularly in job applications and freelance enquiries, statements such as “clean code”, “security awareness” or “scalable architecture” are rarely enough on their own. What matters is evidence that can be traced back to real work. Anyone reading your portfolio does not just want to see what was produced in the end, but also whether your claims are technically grounded.
Of course, a CV, profile text and project description still have value. They provide context, explain roles and place projects in perspective. Even so, they only prove to a limited extent
- what your contribution to a project was,
- how you worked in an existing codebase,
- how carefully you implemented changes,
- and what your work reveals about quality or technical hygiene.
That is exactly where the difference lies between self-reporting and verifiable evidence. A portfolio is more robust when statements are not just written down, but tied to real technical traces.
Typical weaknesses in many portfolios are easy to spot:
- heavily curated excerpts,
- unclear personal contributions,
- no context on code quality,
- no statement on security,
- no indication of test coverage.
Git repositories are an obvious starting point for this. They contain not only the result of the work. They also show how that work came about: in commits, changes, history and technical context.
So if you want to make your developer portfolio more credible, you should not only show finished outcomes. More importantly, you should provide a clear, traceable basis for how that work was created and what quality it has.
Showing real code instead of claims: the repository as evidence
If a developer portfolio is meant to be robust, a well-written CV is often not enough as a foundation. That is why Acquispect starts directly with the technical work and audits the Git repository rather than the CV.
The first step is Stage A: the Ghostwriter Detector. It analyses the .git history forensically and looks not only at visible end states, but at the traces of how they came to exist.
Among other things, it looks at these points:
- who authored commits,
- whether code was dumped into a repository in large blocks,
- and an Impact Score.
This perspective is particularly relevant for a portfolio because it makes your own contribution more tangible. It helps you do more than simply claim that you were involved in a project: it makes the nature of your contribution easier to understand. That matters far more in team projects or over longer product phases than a single screenshot or a short project description.
What matters here is this: the aim is not to publicly disclose raw repository data. The point is something else. A verifiable proof is derived from real development work without turning your portfolio into an open archive of internal details.
For applicants, that means this: instead of simply writing “I helped build product X”, your portfolio can rest on an audited foundation that feels more technical and more substantial.
For freelancers, the benefit is similar, but the context is different. New clients get a more objective impression that the projects you show are backed by real development work rather than self-presentation alone.
If you want to understand in more detail how the Proof Engine works, you can find the methodology in the Proof Engine methodology.
What is assessed besides authorship
Alongside the commit history comes Stage B: the Safety Check. It adds to the picture of authorship alone by covering questions that are often missing from a developer portfolio, even though they say a great deal about how you work and how carefully you work.
Among other things, it checks for:
- leaked secrets,
- known vulnerabilities in dependencies,
- test coverage,
- and the tech stack.
This matters for a portfolio because it shows more than the mere existence of code. It also makes it clearer what technical environment you worked in and what the state of basic technical hygiene is. A project may be presented neatly on the surface and still leave open questions around dependencies, tests or sensitive data. That layer is usually invisible in a traditional portfolio.
This is followed by Stage C. Here, a panel of five AI expert personas assesses the results together. The perspectives are:
- Tech Lead,
- Security,
- Performance,
- Architect,
- Craftsman.
What matters is this: it does not produce an absolutely certain judgement. The panel reaches a consensus verdict with a confidence score. In practical terms for your developer portfolio, that means not just a collection of separate raw signals, but a consolidated technical assessment, including clearly stated uncertainty.
That is far more useful for readers of your portfolio than a simple claim such as “I care about quality” or “I work securely”. It is only the combination of history, Safety Check and several technical perspectives that makes the picture more complete. It adds context about what your work looks like, rather than just how you describe it yourself.
How to use the proof in your portfolio without disclosing raw data
The proof is issued as a W3C Verifiable Credential via did:web. The key point is this: the credential sits in the developer’s wallet. So you own the proof yourself, rather than merely displaying it on someone else’s platform.
This matters for your developer portfolio because verification works selectively. When a company checks the proof, it sees the verdict rather than the raw repository data. That lets you use a verifiable signal without broadly exposing the entire Git repository or sensitive technical details.
At the same time, the assessment is not reduced to a short claim. The full audit log explains how the result was reached. That creates a level of traceability that goes beyond a simple badge or self-written summary.
In practice, you can use the proof in several situations:
- as part of your portfolio,
- as a reference in application documents,
- in conversations with potential employers,
- in proposal discussions with new clients,
- or as a trust signal directly alongside a project description.
For applicants, this mainly means that your documents are strengthened by verifiable technical proof. That can help support statements about how you work in a more objective way.
For freelancers, the benefit often lies in the first contact. When new clients do not yet have any context for your work, a verifiable proof creates a more neutral basis for the conversation.
How companies verify such credentials on request is described on the page for companies.
What it costs to get started and how to begin
For developers, the audit is free. So if you are applying for roles or approaching new clients as a freelancer, you can build verifiable proof without your entry point depending on your portfolio budget.
Companies pay per verification, with no subscription. So the cost arises where the proof is actually used: when the respective company verifies it. There is also an enterprise offering on request for larger requirements.
Getting started itself is straightforward:
- sign in with a crypto wallet,
- or as a guest.
Even so, it makes sense not to add proof to an unfinished portfolio page straight away. Tidy up the content first:
- Which projects do you want to show?
- What was your own contribution?
- Which statements about how you work do you want to support?
Only then should you add the verifiable proof. That way, the statement does not just sit in your profile text, but is supported by real work from the repository.
Frequently asked questions about a developer portfolio with verifiable code
What should a developer portfolio include if I am applying for a developer role?
A useful developer portfolio should not just show outcomes, but make your contribution understandable. Above all, that includes:
- selected projects,
- your specific contribution to them,
- technical context,
- and indications of how you worked.
Short descriptions are more helpful than long self-descriptions. For example, it is useful to show where you took responsibility, which stack you worked in and how your work can be traced in the repository.
How can I show in my portfolio that the code really comes from me?
The most credible way is with proof based on real repository work. To do this, Acquispect audits the Git repository rather than the CV. In Stage A, the Ghostwriter Detector analyses the .git history forensically: who authored commits, whether code was dumped in in large blocks, and an Impact Score. That turns your portfolio into more than a statement about your work; it becomes proof derived from real technical traces.
Do I have to disclose my entire repository for a verifiable portfolio?
No. Verification is selective. When a company checks it, it sees the verdict rather than the raw data. The full audit log explains the assessment. That is useful if you want to use verifiable proof without broadly disclosing your entire repository.
Is this kind of proof more suitable for freelancers, or also for permanent roles?
For both. Freelancers can use it to give new clients an objective basis for initial conversations. For permanent roles, the proof adds verifiable evidence from real development work to your application documents. In both cases, the point is to make statements about how you work easier to follow, without turning a portfolio into pure self-description.
Conclusion: a developer portfolio is stronger when it is provable
A strong developer portfolio does not just show projects. It supports work with real code.
That is exactly the difference between presentation and proof. When a repository is audited, it becomes possible to derive a verifiable picture that brings together several layers:
- authorship,
- security aspects,
- and a technical assessment with a confidence score.
For your portfolio, this is above all a question of trust. Not everything has to be laid openly on the table. Selective verification is not the same as blanket disclosure.
That makes a portfolio not smaller, but more robust: you still present your projects, but you add evidence from real development work.
If you want to show what you have really built, traceable proof ultimately helps more than mere claims.