PATTERN Cited by 2 sources

Prototype before production¶

Prototype before production — before committing to an architectural choice that will be expensive to revisit, build a standalone simulator that exposes the choice space cheaply and visually, iterate on alternatives there, then graft the winning idea onto the production codebase. The simulator is a throwaway artifact; its only job is to answer "which design survives adversarial scenarios?" before that answer is baked into a codebase where every change costs orders of magnitude more.

Canonical instance: Figma Multiplayer (2019)¶

Before building real-time collaboration into the Figma editor, the team (Source: sources/2019-figma-how-figmas-multiplayer-technology-works) built a web-page playground that:

Simulated three clients connecting to one server.
Visualized the whole state of the system — not just the final convergence outcome, but intermediate per-client state mid-propagation.
Let them set up specific adversarial scenarios cheaply: offline clients, bandwidth-limited connections, ordering inversions.

The playground was where Figma "researched and evaluated different collaborative algorithms and data structures." OT, CRDT variants, and the final CRDT-inspired-centralized design all got eliminated or selected in this simulator, not in production. When the design was settled, "it was straightforward to graft the ideas from our prototype onto our existing codebase."

When the pattern pays off¶

Three preconditions that make the investment worthwhile:

The design space is ambiguous and the cost of picking wrong compounds. Real-time collab, consensus, sharding, and concurrency-control choices are famously hard to reverse because their shape leaks into every consumer.
Adversarial scenarios are hard to construct in a full stack. In the real Figma editor, reproducing three clients with asymmetric latency requires running three browsers, a test harness, network-shaping — too expensive per iteration. The playground had those as first-class controls.
Visualization is cheap. The playground rendered per-client state simultaneously — you can see divergence. Production logs don't have that affordance.

When the pattern is wrong¶

The design space is well-understood. If the choice is "use Raft" or "use Kafka," the prototype work has been done upstream. Building a simulator duplicates effort.
The production codebase is thin enough that the simulator and production converge. Then you're just building production slowly.
The simulator's assumptions drift from production's. Classical failure mode: simulator uses mock network, real system uses WebSocket; the new edge cases (reconnect logic, heartbeat handling) invalidate simulator findings.

Sibling patterns¶

Shadow-mode validation (patterns/shadow-validation-dependency-graph) — run a derived structure alongside production. Different: shadow mode operates on real production traffic; this pattern operates on a synthetic model before the real system exists.
Deliberately-noisy evaluation environments (patterns/noisy-simulated-evaluation-environment) — same spirit (construct adversarial scenarios outside production) but aimed at eval-metric realism for agents, not pre-design choice-selection.
Hackathon-to-platform (patterns/hackathon-to-platform) — related cultural pattern: ship prototype first, productize only what survives customer validation. Different scale (product-level, not component-level).

Research-rewrite variant: prototype as "godparent"¶

A second shape of the pattern appears when the artifact is not a throwaway simulator but a substantial research prototype whose learnings — not whose code — seed a later production system. MongoDB's 2023 predictive-auto-scaling prototype is the canonical wiki instance (Source: sources/2026-04-07-mongodb-predictive-auto-scaling-an-experiment):

"The algorithms are different, and the code is new — the experiment is more of a godparent to the product, rather than its parent."

The prototype ran on 10,000 random MongoDB Atlas replica sets, exercised MSTL + ARIMA long-term forecasting + trend-interpolation short-term forecasting + boosted-decision-tree CPU estimator + cheapest-tier planner, and produced five load-bearing learnings that shaped the (different) production code:

Only some replica sets are predictable — most daily, ~25% weekly, hourly irrelevant at ~15-min scaling horizon.
Short-term trends often beat daily/weekly cycles for scaling-horizon forecasts.
Forecast exogenous customer-driven metrics (QPS, connections, scanned-objects rate), not CPU — otherwise you get a self-invalidating forecast.
The forecaster must self-censor on recent-accuracy and fall back gracefully.
Asymmetric risk → production ships scale-up-only initially; reactive backstop keeps scale-down.

What shipped in MongoDB Atlas November 2025 is new code on the same architectural skeleton with different algorithms — the prototype's contract (Forecaster + Estimator + Planner, exogenous inputs, confidence gate) survived; the prototype's implementation did not.

Contrasts with the Figma-style throwaway-simulator variant above: the research prototype is deliberately substantive (statistical models trained on large samples, validated against a test window), because the learnings themselves are the deliverable and learning-robustness requires real scale. Common shape: invest in a prototype whose purpose is to answer questions, then write new code once the questions are answered.

Seen in¶

sources/2019-figma-how-figmas-multiplayer-technology-works — three-client simulator playground as the research environment that sifted OT, CRDT variants, and the final design. Explicit framing as "important to be able to iterate quickly and experiment before committing to an approach" on foundational architectural choices.
sources/2026-04-07-mongodb-predictive-auto-scaling-an-experiment — MongoDB's 2023 predictive-auto-scaling prototype on 10,000 Atlas replica sets seeded a (different-code, different- algorithm) production auto-scaler that rolled out in November 2025. Canonical research-rewrite variant: the prototype's value was the learnings (forecast exogenous metrics, self-censor, two-forecaster architecture, asymmetric risk), not the code. Explicit "godparent, not parent" framing.

concepts/simplicity-vs-velocity — the meta-principle the prototype revealed (Figma's "primary goal was for it to be no more complex than necessary to get the job done" — a constraint you can only evaluate by trying alternatives).