Modern full-stack frameworks are capable enough now that a single codebase can genuinely carry an entire product: rendering, data access, and background work all in one place. For an early prototype or a single-developer product, that's often the right call, and adding a second service too early is one of the more common ways small teams slow themselves down.
The case for splitting into a separate frontend and API usually comes down to independent deployment. A marketing site, a user dashboard, and a background job runner have different scaling and release profiles. The rendering tier wants to sit close to a CDN and redeploy in seconds; a data-heavy API with migrations and scheduled jobs wants a more conservative release process. Bundling both together means every backend change risks a frontend redeploy, and vice versa. Splitting them lets each side scale and ship on its own schedule.
There's also a tooling argument, separate from architecture. Some backend frameworks come with a genuinely mature admin interface and ORM out of the box, which matters more than it sounds once a product has real operational data. Being able to hand a non-technical operator a working admin panel for routine fixes, instead of building a bespoke internal tool, is a meaningful time saver over a product's life.
None of this is free. A split architecture means CORS to configure, an explicit auth token flow instead of a framework's built-in sessions, and two codebases to keep in sync on API contracts. For a product that's genuinely a handful of screens over a simple data model (no background jobs, no complex permissions, a single developer maintaining it), that overhead usually isn't worth paying yet, and a single full-stack codebase is the better starting point. The right answer depends on the product's actual shape, not a default either way.
