A prospect scans a service page and sees a row of logos they recognize elsewhere. It is an efficient shortcut: someone else has worked with this provider. But a new firm, independent consultant, or confidential project may not have permission to display those marks. The absence of famous names does not mean the absence of evidence.
The useful task is to show what a buyer needs to evaluate: whether you understand the problem, how you approach it, what the work looks like, and what a realistic engagement can produce. A logo wall is only one kind of evidence, and often a thin one.
Replace borrowed familiarity with inspectable detail
A useful project example can explain the client context without naming the client, if confidentiality permits. Describe the type of organization, the challenge, constraints, what the team did, and what changed in the deliverable or process. Be precise about what is known. If no outcome measurement exists, do not imply one.
For example, “We designed a dashboard” tells little. “The team needed to compare three kinds of applications across a multi-step education journey; the work reorganized those decisions into a clearer product flow” gives a prospect something to assess. It does not require a famous logo or an invented metric.
Possible evidence includes:
- A redacted artifact or annotated excerpt, with permission.
- A demonstration using sample data that is clearly labeled as illustrative.
- A before-and-after explanation of a specific design decision, without claiming business impact you did not measure.
- A transparent account of constraints, tradeoffs, and what was outside scope.
- A process outline showing how research, review, and handoff work.
- A reference a prospect may contact, only with that person’s consent.
The aim is not to make every example sound impressive. It is to make the work legible and relevant.
Build a proof page around buyer questions
Group examples by the kind of problem solved, not just by deliverable or industry. A prospect comparing providers may want to see how you handle ambiguity, complex information, regulated claims, multiple stakeholders, or a launch deadline. Describe the situation before showing the polished outcome so the buyer can judge relevance.
Use a simple case structure:
- Context: What kind of organization or user was involved?
- Challenge: What was difficult or unclear?
- Decision: What did the team choose to do, and why?
- Artifact: What work can the reader inspect?
- Boundary: What did this example not test or prove?
- Outcome: What changed, with measurement and attribution if available?
This structure helps avoid turning every case study into a claim that the work caused revenue growth. Where multiple changes happened, say so. Where the result was qualitative, label it as feedback or observed behavior rather than a quantified business result.
Use relevance instead of prestige
A small, specific example can be more useful than a famous client name unrelated to the prospect’s needs. If the buyer operates a local clinic, evidence about understanding appointment questions may be more relevant than a household-name consumer campaign. If the work is confidential, explain the category and constraints only to the level permitted by contract.
Do not invent anonymized details that the client could not recognize as theirs, and do not imply permission where none exists. Ask before publishing screenshots, testimonials, names, or recognizable assets. If permission is unavailable, use a clearly labeled reconstructed illustration that does not expose confidential information and does not pretend to be a real project outcome.
What to do when the portfolio is genuinely small
Show the work in progress that demonstrates judgment: a prototype, a sample audit, a clearly marked concept, or a public demonstration. Explain why it is a demonstration and what it can and cannot show. For a new software product, offer a sandbox or guided walkthrough. For a consultant, publish a sample framework and walk through how it applies to a fictional scenario, labeled as such.
Founders’ own experience can provide context, but it should not become an invented origin myth. State relevant expertise, responsibilities, and limits plainly. A buyer can respect a new company that is candid about its history if the next commitment is clear.
Evidence and its limits
One B2B site owner in a forum discussion asked how to turn traffic into serious inquiries and mentioned examples and focused service pages among possible improvements. This is one owner’s account of what they believed prospects needed; it does not prove that portfolio examples alone produce qualified leads.
GOV.UK user-needs guidance recommends understanding the task people are trying to complete and describing it in familiar language. That supports organizing proof around the buyer’s question rather than the provider’s internal list of capabilities. It is a research method, not a conversion statistic.
A quick portfolio audit
Pick one priority service and ask three people unfamiliar with the work to review its page. Can they explain what problem the work addressed, what the provider contributed, and why the example might matter to them? Do they mistake concepts for shipped work or assume an outcome that was never measured? Update labels and context until the evidence is accurately understood.
A credible portfolio does not need famous names to borrow authority from. It needs examples that let a buyer inspect how you think, what you can deliver, and where the evidence stops.