Scaling a large Next.js SaaS frontend: architecture before introducing tests?
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 thought is that before investing heavily in testing, we should improve the frontend architecture and establish clearer boundaries for business logic. Otherwise, I'm concerned we'll end up writing tests around a structure that is already difficult to maintain.
A few questions for teams that have gone through this stage:
- Would you prioritize architectural improvements before introducing tests, or start adding tests immediately and refactor incrementally? - What frontend architecture patterns have worked well for large-scale Next.js applications with complex domain logic? - How do you typically separate UI, state management, API interactions, and business/domain logic? - Are there any proven approaches such as Feature-Sliced Design, Clean Architecture, DDD-inspired frontend architecture, vertical slices, etc., that have scaled well for you? - What testing strategy would you recommend for a codebase that currently has zero test coverage? - Are there any open-source Next.js repositories or large-scale frontend projects that demonstrate good architecture and testing practices?
Tech stack: Next.js, GraphQL, multi-tenant / multiple business configurations, no existing unit or E2E tests.
I'd really appreciate hearing from engineers who have scaled similar applications and what they would do if starting from this situation today.
Adopt an incremental layered architecture with a rich domain/application boundary, and start tests immediately around the highest-risk tenant and business-rule flows.
Your regressions are coming from scattered domain logic, so you should first stop business rules from leaking into pages and GraphQL glue while adding a small, focused test suite that protects the riskiest paths.
It reduces coupling now and protects the most fragile flows without freezing delivery for a large redesign.
It delays safety while the existing code keeps changing, and the knowledge base warns against over-layering or ceremonial redesigns.
It gives fast risk reduction, but tests will be harder to maintain if business rules keep living in pages and integration glue.
Useful as an organization scheme for separating features, but it should sit on top of clear domain/application boundaries rather than replace them.
The main pain is scattered domain rules causing regressions, so comparing where to centralize behavior directly informs whether logic should move out of page components and GraphQL glue.
The frontend mixes presentation, data access, and tenant-specific business rules, so explicit layers fit the separation the team is missing.
The app’s tenant and business-configuration variants suggest the domain is rich enough that a stronger model could reduce duplicated rule handling and accidental coupling.
This is less a UI tweak than a complex business domain living in the frontend, which makes DDD a useful framing for boundaries and shared language.
With no tests in place and regressions already frequent, a layered mix of fast unit tests and a smaller number of higher-level tests scales better than relying on E2E alone.