What Should a Developer Relations Portfolio Include Across Talks, Sample Apps, Docs, and Community Projects?

A Developer Relations portfolio should group talks, sample apps, documentation, workshops, and community projects by the developer problem they solve, with your role and one accessible proof link on every entry.

DevRel work spans formats that live on unrelated platforms, and a playlist or GitHub profile does not explain the connection between them. The portfolio should show how you help developers understand, evaluate, or build with a product while keeping team ownership accurate.

Which DevRel projects deserve their own portfolio entry?

Give a project its own entry when it represents a substantial developer resource, event program, sample application, documentation initiative, or community outcome you can explain and verify.

A single talk can be a project when the recording, slides, and code form a useful package. A series of small posts may be better grouped as one maintained program rather than a card for every publication.

For team initiatives, state your contribution: curriculum, speaking, code, editorial work, community design, program management, or another specific responsibility. Do not present organisation-wide results as individual output.

What is the fast way to assemble the DevRel portfolio with IndieShow?

The fast way is to create one IndieShow card per meaningful initiative, choose a clear tag, and organise the cards by shipped, active, in-progress, or archived status.

Write the description around the developer audience, problem, artifact, and your contribution. Use the single destination for the most complete public proof: event page, recording, sample repository, documentation, workshop, or case study.

IndieShow's profile bio and supported social links provide identity around the project evidence, while the dashboard lets you update the same personal URL as programs end and new resources launch.

Build your IndieShow pageClaim your handle, organise the evidence in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.

Should a talk, its sample app, and documentation be separate projects?

Keep them together when they support one learning journey, and separate an artifact only when it has independent users, maintenance, and a distinct destination.

A workshop with slides, starter repository, and guide is usually one portfolio project. Its description can list the components and send visitors to a hub or the best starting point.

A sample app that becomes a maintained reference for a wider audience may deserve its own card. The decision should reflect how developers use the work, not how many URLs exist.

How do you report DevRel outcomes without vanity metrics?

Use a metric only when it is attributable, approved, and relevant to the developer outcome; otherwise describe the observable artifact and your role without a number.

Views and registrations can lack context, and community or product analytics may belong to the employer. Explain what you built, who it was for, and how it was distributed before considering a public figure.

Avoid implying that a team adoption, launch, or community total came from one talk. IndieShow's metric is optional, so a precise description and strong destination can stand alone.

How does IndieShow make a DevRel portfolio easier to maintain?

IndieShow makes it easier by placing every talk, resource, sample, and program in a consistent project card with an editable status and one controlled link.

Audit recordings, repositories, and docs while signed out. Archive event pages that no longer work, replace moved resources, and mark initiatives as historical when you no longer maintain them.

The IndieShow page becomes a durable overview for hiring managers and collaborators, while the original platforms keep hosting the detailed code, video, and documentation.