What Should a Developer Tools Founder Portfolio Include Across CLI, SDKs, Docs, and Enterprise Use?

A developer tools founder should give each distinct product one portfolio entry, connect its CLI, SDKs, documentation, and integrations through one canonical destination, and describe enterprise use only with approved, attributable evidence.

A devtool can appear fragmented across a package registry, repository, docs site, changelog, marketplace, and private customer deployment even though it is one product. The portfolio's job is to explain what developers can do with it, what the founder built, where to start, and whether the tool is active, experimental, sold, or retired.

When are a CLI, SDK, and docs one project?

They are one project when they are interfaces to the same maintained product, share users and releases, and lead to one developer outcome.

Use one card for the product and route it to the best onboarding destination, usually the docs or canonical product page. The description can name the available CLI, SDKs, API, integrations, and your contribution without creating artificial project volume.

Split a component only if it has independent users, ownership, versioning, and a distinct proof destination. Credit maintainers and team members rather than treating every repository as solely founder-authored.

Active product: canonical docs or product page.
Open-source component: maintained repository or package page.
Private enterprise deployment: approved case or no public claim.
Retired tool: Archived with the last useful destination.

What is the fast way to organise the devtool portfolio with IndieShow?

The fast way is to create one IndieShow card per product or genuinely independent component, set its lifecycle, and point it to the single destination where a developer should begin.

Use the description for developer problem, supported surface, founder role, and current state; use the tag for CLI, SDK, API, infrastructure, or another clear category. Include a metric only when its source, time window, and meaning are supportable.

Order the page around the user or buyer you want next and review every card in the private preview. IndieShow provides the durable founder overview while docs and registries retain version-specific details.

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

How should private enterprise adoption be described?

Describe enterprise adoption only with customer permission and a defined statement, and otherwise explain the deployment class or requirement without naming the organisation or inventing scale.

Do not expose customer names, logos, usage, contract value, internal architecture, support tickets, roadmap access, security documents, or private package locations without authority. An anonymous Fortune-style label can still be misleading and identifying.

A precise capability claim—such as support for a documented deployment mode—is often more useful than a vague customer count. Keep customer references inside the sales process when they are not public.

What should the canonical project link be?

Choose the page that gets a new developer to an accurate overview and first successful use with the fewest unsupported assumptions.

A repository is suitable when it is the maintained source of truth; otherwise use product documentation or the current product page. Avoid stale launch pages, old package versions, private dashboards, or a link list that makes the visitor reconstruct the product.

Audit destinations after renames, acquisitions, deprecations, and major releases. Related IndieShow guides cover open-source maintenance and API evidence across docs and SDKs.

Why does IndieShow fit a developer tools founder portfolio?

IndieShow fits because it gives active tools, open-source components, experiments, acquired products, and retired projects one status-aware founder page without duplicating technical documentation.

Editable cards keep the product promise, role, category, canonical destination, optional defensible metric, and lifecycle together. Reordering makes the portfolio useful for users, partners, hiring, or acquisition conversations.

Use IndieShow to close with the accurate product map; docs, repositories, registries, changelogs, and approved customer cases remain the detailed evidence.