We're building an ecommerce for 1 client who has 2 different brands/shop chains.
Since they will only be varying in terms of fonts, colors and which endpoint they fetch their data from, the plan is to just have a single Next.js application.
The question is now whether it's better to:

1. run both ecommerce sites from the same node instance, rewrite to different domains based on an brand/shop-chain route segment and load the configuration at runtime based on whether the url is branda.com or brandb.com?
2. a single build but deployed separately and using runtime configuration
3. build and deploy the websites separately and set the configuration at build time?

Those who are mostly concerned about economy likes version 1 and 2 the most, since there would not have to be that extra cost of initially setting up two pipelines and additional hosting costs.

But as the developer I feel like even if there's no difference in the codebase (only the tailwind theme/styling, fonts and api endpoints wil differ) creating seperation on the brand/shop-chain level seems like a good place to do it and also to be able to do build time configuration where possible.

I'm looking for some good arguments in deciding between the 3.

As both brands/shop-chains is high traffic and has multiple individual stores to them, scalability is of huge concern.

I see more things that can possibly go wrong with 1. Both during development (Next.js 14, RSC, server side caching), deployment memory/cpu usage/node being singlethreaded/throughput. It just seems like a stretch to go with 1.

With 2 we have the same build deployed by themselves and running on multiple instances. Compared to 3 we only really save a build step at the expense of being able to move som runtime config to build time. So is this really worth the build step cost?

Any good arguments I'm missing? How do people generally do this? Each brand/chain will have a massive amount of traffic and multiple physical + an online store to select from