A startup once asked me why shipping a simple button took their team three days.
The answer wasn’t their developers. It was their architecture.
The problem no one puts on the invoice
Their product had grown the way most products do. One part was built years ago on a legacy stack. A newer part ran on a modern framework. A dashboard was bolted on later by a different team. Three technologies, three teams, one product that users expected to feel like a single thing.
The hidden cost surfaced everywhere but was named nowhere: nothing could be shared.
A single UI component — a button, a modal, a date picker — had to be built three times, once for each stack. Every design change meant three tickets. Every bug fix meant three places to break. Their velocity wasn’t slow because the team was weak. It was slow because the same work was being done three times, forever.
This is framework fragmentation, and it’s one of the most expensive problems in product engineering precisely because it never appears as a line item. It doesn’t show up on a budget. It shows up as a feeling: “Why does everything take so long?”
Why “hire more developers” doesn’t fix it
The instinct, when shipping feels slow, is to add people. But throwing developers at a fragmented codebase doesn’t remove the duplication — it multiplies it. Now you have more people rebuilding the same button in more places, and more surface area for the three versions to drift out of sync.
The bottleneck isn’t capacity. It’s structure. When your architecture forces teams to repeat themselves, more hands just means the same waste at a larger scale.
The fix: components that don’t care about your framework
The durable solution is to stop tying your building blocks to any single framework.
I rebuilt the shared UI as framework-agnostic web components — built on web standards (Custom Elements, Shadow DOM), not bound to React, Angular, or any legacy view layer. A web component is written once and renders identically anywhere the browser runs: inside the legacy app, inside the modern framework app, and inside whatever the team builds next.
The effect is structural:
- One source of truth per component. The button exists once. Fix it once, and it’s fixed everywhere.
- No rewrites when the framework changes. Frameworks come and go on a 3–5 year cycle. Web standards don’t. Components built on the platform outlive the framework churn.
- Teams share instead of duplicate. Three codebases that were each reinventing the same UI start drawing from one library.
In that startup’s case, the button that took three days went to one afternoon — because the work stopped being done three times.
What this actually means for a product
Most frontend problems founders believe are staffing problems are really architecture problems in disguise. “We need more developers” is often “our structure forces us to repeat ourselves.” The first is expensive and slow to fix. The second is fixable with better decisions.
If your team keeps rebuilding the same things across a fragmented codebase, or shipping feels slower than it should for reasons no one can quite name, the cause is usually architectural — and architecture can be changed.
I architect and ship product frontends for exactly this kind of problem — untangling fragmented codebases, building framework-agnostic component systems, and getting teams shipping fast again. If any of this sounds like your product, get in touch — I’ll tell you what I’d look at first.