Skip to content

PATTERN Cited by 1 source

Shaping vs building

Separate the shaping phase — cheap exploration of possible solutions — from the building phase — polishing and deploying the chosen solution to production. Canva's Product Development Process (PDP) names the two phases explicitly and gives them different tools and review expectations (Source: sources/2024-12-16-canva-faster-ci-builds).

Intent

Most engineering failures at the architecture level come from mixing these two phases:

  • Treating building as shaping. Writing design docs and PRs before you have confidence the problem/solution fit is right. Fragile proposals, wasted review cycles, walls of text, deep sunk-cost attachment to a not-yet-validated direction.
  • Treating shaping as building. Shipping half-baked prototypes to production. Temporary scaffolding ossifies, becomes buggy and hard to maintain.

Shaping-vs-building as an explicit separation gives each phase a licence to do what it does best: shaping = maximum information gained per hour with no commitment tax; building = enough polish for production.

The shaping phase

Goal: explore breadth before committing to depth.

  • Broad sampling of possible solutions, deliberately.
  • Peer brainstorms without approval overhead.
  • No PRs. Mac, DevBox, or burner accounts; local containers; mocks in place of fancy infra.
  • Intentionally discard prototypes that don't pan out.
  • Avoid perfecting code that doesn't solve the problem.

Canva's CI team ran a 448-CPU / 6 TB RAM instance experiment during shaping — no PR, no infra — to bound the theoretical limit (concepts/first-principles-theoretical-limit). That would have been comically overbuilt as a production step; it was ideal as shaping.

The building phase

Goal: deliver the validated solution at production quality.

  • Proposals, design reviews, approvals — the appropriate commitment tax.
  • PRs, tests, observability, rollout plans.
  • Monitoring, alerts, runbooks.
  • Production-grade infra.

The gate between phases: evidence the solution works. Not "convinced it will", but something measured.

Why it compounds

  • Cheap shaping surfaces more options. Five prototypes in a week beats one production-quality proposal in a month.
  • Discarded shaping work is a feature. The sunk-cost-fallacy protection is the whole point — you can't get talked into something just because you already spent time on it.
  • Building work hits production, not half-finished. Reviewers can engage with a validated direction, not a brainstorm.

Anti-patterns

  • PR-driven exploration. Reviewers are roped into reviewing code that may be thrown away; you're emotionally committed by the time feedback comes in.
  • "Quick hack to test it" becoming the permanent implementation. The prototype's rough edges migrate to prod and never get cleaned up.
  • Infrastructure-first prototyping. Blocking on a new service, a new IAM setup, or a managed-service onboarding before you know whether the idea works.

Seen in

Last updated · 200 distilled / 1,178 read