FRONTEND FEBRUARY 17, 2024 · 8 MIN READ
Frontend Architecture for Long-Term Velocity
Speed at year three is decided by boundaries drawn in month one.
Velocity dies quietly. Not in one bad sprint but in a hundred small couplings nobody wrote down: the util that reaches into a feature, the feature that imports another feature’s store, the shared type that became a shared everything. The fix is structural, and it starts earlier than you think.
Boundaries, enforced by machine
Every codebase has an architecture diagram; few have one the compiler agrees with. The difference is enforcement. Module boundaries that live in a lint rule survive personnel changes; boundaries that live in a wiki do not.
The rules worth automating are few: features do not import from other features; shared code moves down (into a platform layer) rather than sideways; and anything imported from more than three places is officially an API, versioned in spirit even inside a monorepo. Three rules, machine-checked, beat thirty conventions in a document nobody reads twice.
The cost curve you are actually managing
Month one, everything is fast — there is nothing to couple to yet. The architecture decision is whether month thirty-six looks the same. Every shortcut is a loan against that future: usually worth taking, occasionally catastrophic, never free. The architect’s job is not to forbid loans; it is to make the interest rate visible at the moment of borrowing.
The test I trust: pick a feature and ask what it would cost to delete it. Clean deletion means real boundaries. If deleting it frightens people, the coupling already happened — you are just choosing when to pay.
Design for deletion, and change stays cheap. That is the entire velocity strategy, and it fits in a sentence.