A new feature request
WeeksShips in the next scheduled minor
A consuming team needs a component or an API the platform does not have yet. The full pipeline, and the only one of the four that spends real time in design.
Where the shape breaks The stage that costs the most is the one before any code exists — most of what arrives is one application’s problem wearing a platform costume, and design is where that gets settled.
Intake
~2 daysHow the work arrives and gets recorded
A team files a component or API request against the central queue, with the screen it is blocked on attached.
Decided by Platform intake
Triage
~1 weekSeverity, priority, and who owns the call
Weighed against the roadmap, and against the harder question: does this belong in the platform at all, or in the application that asked for it?
Decided by Platform lead
Design
~2 weeksThe API shape and its trade-offs, settled before code
The expensive stage. API shape, accessibility acceptance criteria, and a tech-feasibility session with the requesting team’s designers — non-standard usage gets caught here rather than in review.
Decided by UX + platform architect
Build
~2 weeksImplementation, tests, and the migration path
Implementation against the agreed API, with tests and the documentation entry written alongside it rather than after.
Decided by Owning engineer
Verify
~1 weekAccessibility, visual regression and contract checks
Accessibility audit, visual regression across both themes, and the contract tests every consuming application leans on.
Decided by QA + accessibility
Release
ScheduledThe version that carries it, and to which supported lines
Additive by definition, so it rides the next scheduled minor and nothing downstream has to move.
Decided by Release manager
Adopt
At their paceHow consuming applications take it up
Teams pick it up on their next version bump. No migration, no deadline, no chasing.
Decided by Consuming teams