Scaling a large Next.js SaaS frontend: architecture before introducing tests?

vegan_vicky

I'm working on a fairly large SaaS product built with Static Next.js. The application supports multiple business configurations/tenants and consumes GraphQL APIs. As the product has grown, the frontend has accumulated a lot of domain-specific business logic. At this point, almost every new feature or change risks introducing regressions somewhere else. Unfortunately, we currently don't have any unit tests or E2E tests in place. My initial...

Originally asked by Dulana on Stack Exchange (stackoverflow) (CC BY-SA 4.0).

uphilltech

Great question — answering as the UphillTech team:

For the system you described, I would not pause for a big architecture cleanup before adding tests. I'd do both, but in a very uneven way: start tests immediately on the highest-risk tenant and business-rule flows, and refactor incrementally as you touch those areas. The reason is that a rewrite-first approach delays the safety net, while tests-without-boundaries will lock in some mess but still reduce risk now. The answer changes if tenant differences are mostly just config; if they're structurally different flows, I'd separate those earlier instead of trying to hide them behind one generic UI path. On structure, the pattern I would pick is a layered frontend with real business boundaries:...

Full answer by KindaArchitect: https://stackoverflow.stackexchange.com/a/79974504 (CC BY-SA 4.0).

Need it done for your business? UphillTech.