Skip to content
← Back to Blog

Frontend Platform RFCs That Improved DX (Without Blocking Teams)

· 6 min read
platformdxprocesstypescriptfrontend

“We should standardize this.”

That sentence usually ends one of two ways:

  1. A doc nobody reads and no one follows.
  2. A mandate that slows teams down until they route around it.

The only version that worked for us was a third option:

RFCs as a tool to build a paved road.

Not “architecture theater.” Not endless consensus loops. Just enough structure to:

  • make decisions visible
  • compare alternatives honestly
  • ship a default path most teams want to use

This post shares the RFC patterns that actually improved developer experience: templates, pipelines, and TypeScript validation boundaries.

The problem: standards fail when they are either toothless or tyrannical

Frontend platform work is full of false choices:

  • “If we don’t enforce standards, everything becomes chaos.”
  • “If we enforce standards, teams can’t ship.”

The real move is to:

  • make the default path easy and good
  • allow exceptions, but make the cost explicit

RFCs were how we made that trade-off legible.

What an RFC is (and what it isn’t)

For us:

  • RFC = a proposal that includes a rollout plan and a measurement plan.
  • ADR (Decision Record) = the final “we decided X because Y” snapshot after discussion.

The RFC is for thinking. The ADR is for remembering.

The RFC template that got used

The best template is the one people will actually fill out. Ours fit on one screen and forced the critical thinking:

## Context

What’s happening today? What pain are we fixing?

## Goals / Non-goals

What must improve? What are we explicitly not trying to do?

## Proposal

What’s the change? What’s the “paved road”?

## Alternatives considered

At least 2. Why didn’t we choose them?

## Rollout plan

How do we ship this incrementally? What’s the rollback/escape hatch?

## Impact

Who is affected? What breaks? What migrates?

## Measurement

How do we know this improved DX or reliability?

If an RFC couldn’t answer “how do we roll this out?” it wasn’t ready.

The mechanics that made it work

  • Time-boxed review: 3–5 business days. Silence wasn’t consent; it was a signal to follow up with the right owners.
  • Decision owner: one accountable person (not “the group”) who writes the ADR.
  • Default to action: if the cost of being wrong is low, ship behind a flag and measure.
  • Docs as a byproduct: the RFC wasn’t “documentation.” It was a tool to ship a change safely.

RFC #1: the application template (the biggest DX win)

The fastest way to improve DX across many teams is to make “starting a new app” boring.

The RFC proposed:

  • a template repo / generator that included:
    • auth integration stub
    • routing skeleton
    • logging + error boundaries
    • i18n wiring (if needed)
    • a11y baseline
    • conventions baked into linting/formatting
  • a “golden path” for local dev (one command, predictable ports, consistent env)

What made it succeed

  • The template shipped with examples, not just scaffolding.
  • We treated it like a product: versioning, changelog, upgrades.
  • We didn’t block teams from diverging - we made divergence feel worse than staying on the paved road.

Measurement that mattered

  • time to first running app (new engineer onboarding)
  • number of “how do I set up X?” questions in Slack
  • PR review time for new projects

RFC #2: CI pipelines as a platform primitive

Before standardization, every team’s CI was a snowflake:

  • different cache strategies
  • different quality gates
  • different deployment safety

The RFC wasn’t “everyone must use this YAML.” It was:

  • a reusable pipeline template
  • default jobs (format/types/lint/test/build)
  • a consistent artifact + preview environment story

Key idea: “standards without hostage-taking”

We designed pipeline templates with:

  • sane defaults
  • optional steps
  • clear extension points

And we added a rule: if you bypass a gate, you must link the reason in the PR (temporary, explicit, visible).

Measurement that mattered

  • median PR cycle time
  • cache hit rate and CI minutes
  • change failure rate (deploy rollbacks, incidents)

RFC #3: TypeScript validation boundaries (runtime safety as a standard)

This RFC started from a harsh truth:

TypeScript does not validate your inputs.

Bugs kept slipping through because we were “typed” but not safe:

  • URL params treated as valid IDs
  • API responses assumed to match interfaces
  • localStorage values trusted blindly
  • feature flags treated as booleans even when they were strings

The RFC proposed a standard:

  • parse at the boundary
  • brand validated values
  • forbid ad-hoc as SomeType casts outside boundary modules

We paired it with a small library:

  • schema helpers (Zod/Valibot/etc.)
  • branded type utilities
  • an error taxonomy (parse vs network vs auth vs business rule)

The goal wasn’t perfect correctness. The goal was to make invalid states harder to represent.

Measurement that mattered

  • reduced “unexpected undefined” class of bugs
  • fewer production incidents caused by schema drift
  • faster debugging (errors became categorized and actionable)

Enforcing standards without blocking teams

Here’s what worked better than mandates:

  • Nudges in tooling: generators, linters, CI checks, codemods.
  • Escape hatches with friction: you can do the weird thing, but you must write down why.
  • Backwards-compatible rollouts: old patterns keep working during the migration window.
  • Visibility: dashboards showing adoption and exceptions (not to shame, to learn).

The question we asked before adding any new “rule”:

“Will this help teams ship faster next month?”

If the answer was “it improves long-term correctness,” we still shipped it - but only if the rollout plan didn’t create a short-term tax bigger than the benefit.

RFC anti-patterns (things we stopped doing)

  • “RFC as approval gate” (it becomes bureaucracy)
  • “RFC with no rollout plan” (it becomes a wish)
  • “RFC with no owner” (it becomes nobody’s problem)
  • “Standardization by PDF” (docs don’t change behavior; tooling does)

A lightweight process you can copy

If you’re doing frontend platform work across teams:

  • keep RFCs short
  • require rollout + measurement
  • write ADRs so decisions don’t vanish in Slack
  • build a paved road with templates and tooling
  • allow exceptions, but make them explicit

The best platform standards don’t feel like rules. They feel like a faster way to get things done.