Last year, with Portal 2025, we ran the first structured pass over a plan: the project showcase got moved, builder tools got a slight refresh, and the fundamentals were rearchitected to get started faster. That effort wrapped up earlier this year.
What comes next?
Portal 2026 pulls together portal-relevant work drawn from several sources: feedback from community developers, the feedback loops of existing onboarding efforts, discussions in the Intersect Developer Experience working group, and opinions surfaced across broader ecosystem conversations. It's not a top-down mandate, it aims to coalesce those ideas into a clear direction for the portal.
The cleanup worked, but the portal still carries the symptoms of organic growth beyond what the first pass could address. The same concept gets explained three times in tool-flavored places. Governance content spans three directories with overlapping titles. So Portal 2026 is less about removing debt and more about building on top of the cleaner base. The Developer Portal should be the canonical learning platform for Cardano developers: up-to-date, highly curated, and designed to lower the cost of acquiring new developers for the ecosystem.
The concrete bar we anchor to is getting an onboarding developer from zero to MVP on testnet in the shortest possible time, using the portal alone. Everything in the pillars below moves new developers closer to that.
Portal 2026 is written as an open-ended strategy rather than a finalized checklist. The pillars define directions the portal should move in, and the work under each gets proposed and tracked as it lands. I've structured the scope into six pillars. The first four shape the content and structure; Pillars 5 and 6 cover the periphery that keeps the site sound and the design that gives it a coherent look. They run in parallel rather than in sequence, though the structural work (Pillar 3) is a prerequisite that benefits the others, so it took priority.
Pillar 1: One story, many tools
Sub-issue: #1772
The portal organizes around learning targets and practical outputs ("how to mint an NFT"), not around which SDK a developer happens to pick up first. One authoritative page per concept, with the relevant tools shown inside it side by side as tabs. This pillar owns how a concept gets explained.
Pillar 2: Building blocks
Sub-issue: #1773
The reusable assets a developer reaches for once they know what they're building: ready-to-run templates, a curated builder-tools catalog, a smart-contract reference library, and task recipes. Filterable, curated, and wired into the rest of the portal so people can skip ahead to working code.
Pillar 3: A legible portal structure
Sub-issue: #1809
One clear rule for where content lives, so contributors stop guessing and readers can predict where to find things. An audience-first top level (developers, operators, community, contribute), a numbered-module curriculum, and no by-tool or by-language buckets. This pillar owns where a page lives, and folds that rule into the contribution standards.
Pillar 4: LLM-native
Sub-issue: #1830
LLMs are now part of how developers read documentation and build apps, so the portal should be as readable by an agent as it is by a human. Machine-readable output, a copy-as-markdown affordance, AI-crawler readiness, and pointers to agent skills and templates an agent can use. Whatever the portal publishes gets indexed, summarized, and quoted back to developers by the tools they use, so if it's structured well the developer gets a good answer. This pillar owns the AI-facing surface.
Pillar 5: Periphery and upkeep
Sub-issue: #1839
The non-content plumbing that keeps the repo and the deployed site clean and correct: CI workflows, redirects, security headers, PR and issue templates, README and CONTRIBUTING, site metadata, and search config. Passthrough fixes that do not belong under the content pillars. This pillar owns the plumbing.
Pillar 6: Design and the Cardano 2026 brand
Sub-issue: #1847
The portal's look has grown organically, with one-off social cards, page screenshots, and a default system font that predates the brand. This pillar is the design pass that brings the portal's surfaces onto the Cardano 2026 brand one at a time: shared templates, Open Graph and social cards, typography, colour, and high-traffic surfaces like the landing page. This pillar owns how the portal looks.
A lot of what Portal 2026 covers fits alongside broader developer experience work happening across working groups. In particular, #1738 from @rober-m points in the same direction: clearer user paths, up-to-date onboarding-optimized content, and LLM-native documentation. We're working toward the same thing, and I'd like to use this issue as the place where the pillars get tracked and coordinated for the portal itself. Work that sits outside the portal's scope but still matters for Cardano's developer experience is tracked separately in the companion issue, Ecosystem DevEx 2026.
Last year, with Portal 2025, we ran the first structured pass over a plan: the project showcase got moved, builder tools got a slight refresh, and the fundamentals were rearchitected to get started faster. That effort wrapped up earlier this year.
What comes next?
Portal 2026 pulls together portal-relevant work drawn from several sources: feedback from community developers, the feedback loops of existing onboarding efforts, discussions in the Intersect Developer Experience working group, and opinions surfaced across broader ecosystem conversations. It's not a top-down mandate, it aims to coalesce those ideas into a clear direction for the portal.
The cleanup worked, but the portal still carries the symptoms of organic growth beyond what the first pass could address. The same concept gets explained three times in tool-flavored places. Governance content spans three directories with overlapping titles. So Portal 2026 is less about removing debt and more about building on top of the cleaner base. The Developer Portal should be the canonical learning platform for Cardano developers: up-to-date, highly curated, and designed to lower the cost of acquiring new developers for the ecosystem.
The concrete bar we anchor to is getting an onboarding developer from zero to MVP on testnet in the shortest possible time, using the portal alone. Everything in the pillars below moves new developers closer to that.
Portal 2026 is written as an open-ended strategy rather than a finalized checklist. The pillars define directions the portal should move in, and the work under each gets proposed and tracked as it lands. I've structured the scope into six pillars. The first four shape the content and structure; Pillars 5 and 6 cover the periphery that keeps the site sound and the design that gives it a coherent look. They run in parallel rather than in sequence, though the structural work (Pillar 3) is a prerequisite that benefits the others, so it took priority.
Pillar 1: One story, many tools
The portal organizes around learning targets and practical outputs ("how to mint an NFT"), not around which SDK a developer happens to pick up first. One authoritative page per concept, with the relevant tools shown inside it side by side as tabs. This pillar owns how a concept gets explained.
Pillar 2: Building blocks
The reusable assets a developer reaches for once they know what they're building: ready-to-run templates, a curated builder-tools catalog, a smart-contract reference library, and task recipes. Filterable, curated, and wired into the rest of the portal so people can skip ahead to working code.
Pillar 3: A legible portal structure
One clear rule for where content lives, so contributors stop guessing and readers can predict where to find things. An audience-first top level (developers, operators, community, contribute), a numbered-module curriculum, and no by-tool or by-language buckets. This pillar owns where a page lives, and folds that rule into the contribution standards.
Pillar 4: LLM-native
LLMs are now part of how developers read documentation and build apps, so the portal should be as readable by an agent as it is by a human. Machine-readable output, a copy-as-markdown affordance, AI-crawler readiness, and pointers to agent skills and templates an agent can use. Whatever the portal publishes gets indexed, summarized, and quoted back to developers by the tools they use, so if it's structured well the developer gets a good answer. This pillar owns the AI-facing surface.
Pillar 5: Periphery and upkeep
The non-content plumbing that keeps the repo and the deployed site clean and correct: CI workflows, redirects, security headers, PR and issue templates, README and CONTRIBUTING, site metadata, and search config. Passthrough fixes that do not belong under the content pillars. This pillar owns the plumbing.
Pillar 6: Design and the Cardano 2026 brand
The portal's look has grown organically, with one-off social cards, page screenshots, and a default system font that predates the brand. This pillar is the design pass that brings the portal's surfaces onto the Cardano 2026 brand one at a time: shared templates, Open Graph and social cards, typography, colour, and high-traffic surfaces like the landing page. This pillar owns how the portal looks.
A lot of what Portal 2026 covers fits alongside broader developer experience work happening across working groups. In particular, #1738 from @rober-m points in the same direction: clearer user paths, up-to-date onboarding-optimized content, and LLM-native documentation. We're working toward the same thing, and I'd like to use this issue as the place where the pillars get tracked and coordinated for the portal itself. Work that sits outside the portal's scope but still matters for Cardano's developer experience is tracked separately in the companion issue, Ecosystem DevEx 2026.