Next.js at the edge, Go at the service boundary
The Next.js application supplies public, account, transaction, and operations interfaces. Protected business operations are handled by the Go API. Browser traffic uses a same-origin application boundary rather than exposing server-only credentials or provider decisions.
This split supports independent delivery and clear ownership, but it is still one product. It should not be divided into services merely to imitate a larger organization.
Modular monolith first
Identity, tenancy, authorization, commerce, billing, content, and administration remain explicit domains inside a maintainable application foundation. Dependency direction and API contracts matter more than the number of deployable units.
Extraction becomes justified when load, release isolation, ownership, or compliance evidence requires it. Until then, a modular monolith keeps operational complexity proportional to the team.
PostgreSQL is the durable boundary
Tenant-aware repositories and transactions keep data access aligned with authenticated request context. PostgreSQL row-level security can provide defense in depth for appropriate tables when roles and session context are configured correctly.
Caches, files, queues, and derived reporting data must carry the same scope; a safe database query does not compensate for an unscoped export or background job.
Buyer-owned deployment
Platform source can be adapted to the buyer’s infrastructure. The current reference separates edge-delivered Next.js surfaces from a stateful Go and PostgreSQL environment, but the buyer owns production topology, credentials, backups, monitoring, scaling, and rollback.
Deployment examples are starting points rather than a managed hosting promise or universal infrastructure requirement.