How should I structure a reusable Next.js app without over-engineering it?

Don’t design around a hypothetical mobile app. Keep the business rules in shared service modules, and make server actions or route handlers thin adapters around those services. If a mobile client or another integration becomes real, add an API at that point instead of maintaining two interfaces from day one.

Next.js is convenient for applications where the UI and backend are closely integrated, but complex API-heavy systems may be clearer as a dedicated backend plus a separate client. Server actions are useful for operations initiated directly by the Next.js UI; route handlers or a standalone API make more sense when the same capabilities must serve mobile apps, third parties, or several frontends.

A layered structure like API → service → repository → database isn’t automatically over-engineering. Keeping persistence behind a repository can make testing and future database changes easier. The important part is to avoid adding layers that don’t provide a clear boundary or benefit in your current application.

For a larger product, a monorepo can work well: separate the web and server apps, then share packages for validation, database access, authentication, API clients, UI components, and utilities. A typed validation layer and a shared API contract are especially useful when multiple clients are expected. I’d still start with only the packages and boundaries you actually need.