Skip to content

PATTERN Cited by 1 source

Prototype the path

Prototype the path is Slack's named methodology for executing a large re-architecture: build a barely-working prototype of the new architecture, dogfood it internally (starting with the core team — the heaviest users of the product), let painful edge cases surface via real day-to-day usage, fix them one by one, and expand the user base in concentric rings (core team → engineering org → execs → whole company → customers). The prototype is not a throwaway — it becomes the production path via incremental fixes.

Canonical wiki instance: Slack's Unified Grid (systems/unified-grid, Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers).

The verbatim framing

"Execs — not to mention engineers — were understandably concerned about the cost of Unified Grid, and not convinced that the payoff would be worth the effort. Therefore, rather than start by tackling what were potentially thousands of broken APIs, we decided to build a proof of concept to better understand the benefits of Unified Grid and the work that would be required to ship it end-to-end. At Slack, we call this prototyping the path — that is, building incrementally, proving out and refining our ideas as we go. Because we are some of the heaviest users of Slack, we knew that if we could use Unified Grid in our day-to-day work, we'd start getting good signals about what did and didn't work."

The concentric-rollout ladder

  1. Core-team dogfood. A barely-working prototype is used daily by the team building it. Pain points surface fast because the team can't ignore them — the prototype is their work tool.
  2. Engineering-org expansion. Opt-in peers who are willing to tolerate rough edges in exchange for early access. Broadens the usage-pattern distribution the prototype is hit with.
  3. Exec onboarding. Slack notably onboarded then-CEO Stewart Butterfield; his "This is obviously better" was the signal the investment was worth the effort. The ladder point: execs' feedback converts a tech project into a product priority.
  4. Company-wide rollout. "Summer 2023 — Unified Grid was in a place where much of the company was using it for their day-to-day work."
  5. Customer rollout. "We began rolling out to customers in Fall 2023 and completed the rollout in March 2024."

Each ring's feedback converts into fixes that make the next ring viable. No ring requires "perfect" — only "good enough to start using."

Distinction from prototype-before-production

patterns/prototype-before-production (Figma multiplayer, MongoDB autoscaling) is research-style: build a throwaway simulator to evaluate design choices in the cheap environment, then write new production code once the design is decided.

Prototype the path is incremental re-architecture: the prototype is the production path. You don't throw it away — you fix it into production. Suitable when:

  • The design space is not the ambiguous part — the target shape is clear (org-wide, not workspace-scoped); the uncertainty is "can we incrementally get there from here?"
  • The cost of a research simulator would exceed the cost of just building the thing rough and dogfooding it.
  • The product is being built by people who use the product — dogfood as research instrument.
Axis Prototype-before-production Prototype-the-path
Artifact Research simulator / notebook Actual working-but-rough system
Outcome Inform design; write new code Becomes the production system
Environment Synthetic scenarios Dogfood (real users, real data)
Input uncertainty Design space (multiple algorithms) Migration feasibility (can we get there?)
Exit criterion Design decided Concentric-ring expansion complete

When the pattern pays off

  • You are the heavy user of your own product. Slack is used intensively by Slack employees; dogfood surfaces issues naturally. A product with no employee-user base can't run this pattern as cheaply.
  • The re-architecture's shape is clear; the risk is execution. Unified Grid's target shape (org-wide client) was not in question — the question was whether the thousands of APIs could be re-taught without breaking production.
  • Execs can be onboarded via the prototype itself. Exec endorsement is the project's political capital; the prototype is the artifact that earns it.
  • The prototype can be kept running alongside production. Slack built a flag on their API framework ("an API could be marked compatible with the new Unified Grid client") — APIs graduate into the new context individually, and the old context remains live for customers.

When the pattern is wrong

  • The design space is genuinely open. If you don't know whether OT or CRDT or centralised-CRDT is right, you need a simulator (prototype-before-production), not an incrementally- fixed prototype.
  • The product has no internal heavy users. Dogfood doesn't work without them; the pattern's feedback mechanism collapses.
  • Concentric-ring expansion is blocked by a hard compliance / customer-contract / safety gate. If you can't put the prototype in front of any user before it's fully correct, the discipline of incremental expansion can't compound.
  • The architectural change is all-or-nothing. If the new architecture requires a big-bang cutover (rather than an API-framework flag for graduating individual surfaces), prototype-the-path doesn't apply — the prototype can't coexist with production.

The supporting substrate

Slack shipped multiple platform-level investments to make the pattern tractable:

  • API-framework compatibility flag — per-API "works with Unified Grid" toggle. APIs graduate via patterns/two-pass-api-migration.
  • Parallel integration test suite — same tests under org context; see patterns/parallel-integration-test-suite-for-context-switch.
  • Migration docs — "a detailed guide with step-by-step instructions for ensuring that an API behaves correctly in Unified Grid."
  • Convenience helpers for common patterns (cross-workspace channel permission checks, multi-workspace channel lookup).
  • Spreadsheets tracking API / permission-check counts — "we created a spreadsheet to track the number of APIs and permission checks we needed to fix, and enjoyed watching the graph tend towards zero."

These investments are the pattern's real cost; the "prototype" part is cheap, the substrate is not.

Seen in

Last updated · 470 distilled / 1,213 read