Make the backend boundary real before splitting deployments

Colocating a UI and API in one framework is not itself the decisive scaling constraint. Before splitting deployments, create one versioned, runtime-validated API boundary; centralize authentication and organization authorization there; make frontend server rendering consume the same API as browser clients; and use generated clients with compatibility tests. Extracting processes before those contracts exist tends to create a distributed monolith with duplicated authorization policy.

A backend-for-frontend may remain with the UI for session-cookie handling and aggregation, but domain authorization must stay authoritative in the backend. This sequence does not require immediate microservices: a modular monolith behind a stable API is a safer first step. Move heavy uploads to short-lived upload intents and direct object storage, and move long provider work to durable jobs only after transactional outbox and idempotency semantics exist.