Keeping the front end and the API on separate release cycles

The decision

A single-page front end deployed independently of a NestJS API. The two release cycles stay apart, so a front-end fix does not require a backend deploy, and the API can serve a second client later without a rewrite.

The product serves restaurants, and it has separate entry points for restaurants, riders and consumers. Splitting the API out early is what makes serving three different clients from one backend reasonable rather than a tangle of conditionals.

What I would change

Same note as DealsBuilder, and more sharply: the app ships no crawlable content at all, so search engines and link previews see nothing. For a consumer product that wants to be shared, that is a real cost, and server rendering the public routes would remove it.