Deciding to duplicate rather than share — and being disciplined about where the duplication stops. Two products sit on one backend, one database and one user table. The login form, the useUser hook, the account pages and the checkout are near-identical, and every instinct trained on DRY says extract them into a shared package.
What I did about it
That instinct is wrong here, and articulating why was the actual work. The two sites sell different things to overlapping audiences and are expected to diverge visually and commercially.
A shared component library would mean every restyle of one site risks changing the other, so every change needs regression-testing against a product it was never meant to touch — and a shared deployment cadence on top of that.
So the frontend is duplicated and the backend is not: one Flask API, one user table, per-site session isolation via an X-Client header. The duplication stops exactly at the network boundary.
Every one of the 16 pages is a server component, with zero 'use client' page files — for a product customers find through search, that is the whole growth mechanism.
What I rejected, and why
Zero tests, and no test script at all. For a 7,000-line frontend with no business logic of its own that is a defensible allocation of a solo maintainer's time — but it is a choice, not an oversight, and it is the first thing to fix if this site ever grows logic worth breaking.
Zero tests and no test script at all. For a 7,000-line frontend with no business logic of its own that is a defensible use of a solo maintainer's time, but it is a decision to revisit the moment this site grows logic worth breaking.