Writing
Notes on platform-scale frontend. What worked, what surprised me, and what I'd do differently.
Monorepo is Not the Problem
The monorepo vs polyrepo debate resurfaces every few months, and it is almost never about repo structure. Slow CI, unclear ownership, and under-funded tooling wear the repo as a costume.
Performance is a Culture Problem
You can have the best performance tooling in the world and still ship a slow product. Fast teams do not have better tools. They have different defaults.
The Rewrite You Will Regret
Rewrites get underestimated by 3x because the old system refuses to stand still while you rebuild it. When rewriting is genuinely right, when it is not, and how to make the call honestly.
TypeScript Won't Save You From Your API
Your types at the API boundary are a description of last week's schema, not a guarantee about today's. Most teams have end-to-end type theater, and the gap only shows up at runtime.
Your GraphQL Schema is a Team Contract, Not a Type File
Every field you add to a GraphQL schema is a promise to every consumer. The teams that do GraphQL well treat the schema like a roadmap, not a database migration.
The Shared Component Library Nobody Uses
Most shared component libraries are graveyards within 18 months. Not because engineers built them wrong, but because adoption was never the actual goal.
Feature Flags Are a Code Smell (Eventually)
Feature flags solve real problems early, but become technical debt unless managed rigorously. A pragmatic look at when they make sense and how to keep them from consuming your codebase.
Microfrontend Boundaries: How to Decide Where to Split
A working framework for deciding which workflows become independent microfrontend surfaces and which stay in the monolith. Drawn from modernizing BILL's AR platform.
The Headless/UI Split: Building an SDK That Two Audiences Can Both Use
How splitting a fintech SDK into a headless layer and a UI layer let the platform work for both fast-moving and design-strict client teams, without forcing either to compromise.
The Code Review That Ships Nothing
Three days, forty comments about naming and imports, and nothing about whether the change should exist. Most code review is theater. The best reviewers are doing a different job entirely.