Why our marketing site and our app live on different stacks

Here’s a rule that trips up more startups than it should: DNS routes by hostname, not by URL path. A single hostname points at exactly one place, and everything under it — /, /app, /api — goes there. DNS has no concept of paths; that decision happens later, at the HTTP layer.

That one fact decides your whole domain architecture.

The trap

If you point yourdomain.com at a hosted site builder, that builder serves every request to that hostname — and most builders are terminal hosts: they only serve the pages you built in them and 404 everything else. Your API has nowhere to live on that hostname. Try to bolt the app onto the apex later and you’re migrating hostnames — breaking bookmarks, integrations, and OAuth redirect URLs that customers have hardcoded.

What we do instead

Give every surface its own hostname from day one:

ecphoric.com        →  marketing + blog   (this site)
app.ecphoric.com    →  the product
api.ecphoric.com    →  the API, versioned by path: /v1/…

Different hostnames are different destinations, so they can run on completely different stacks with zero conflict. Our marketing site is static and optimized for reach; our app and API run on our own infrastructure. The apex belongs to marketing — the app never squats the root.

The api. subdomain is the important one. Even large platforms rebrand their product while leaving their API hostname untouched, precisely because it’s hardcoded in thousands of codebases. Decide it once, version by path, and never move it.

It’s a small amount of foresight that saves a painful migration later.