Freemium SaaS creates a small routing problem very quickly.
One user signs up. Then another. Then a team creates a workspace. Then a customer asks for a branded URL. Suddenly your app needs to decide how every tenant should be reached.
Should you use path slugs?
app.example.com/acmeShould you use subdomains?
acme.example.comShould you support customer-owned domains?
portal.acme.comThe right answer depends on stage, branding needs, routing complexity, and how much operational work you want to own.
Quick Answer
Early freemium SaaS products should usually start with slugs unless tenant identity, branding, cookie boundaries, or future custom domains are central to the product. The important engineering choice is not slug versus subdomain on day one. It is centralizing tenant resolution so you can support slugs first, subdomains later, and custom domains when customers are ready.
The Decision Table
| Model | Example | Best for | Main tradeoff |
|---|---|---|---|
| Path slug | app.example.com/acme | Early products, simple onboarding | Less branded |
| Subdomain | acme.example.com | Tenant identity and cleaner sharing | Needs wildcard DNS and hostname routing |
| Custom domain | portal.acme.com | B2B customers and branded portals | Needs verification, SSL, lifecycle management |
Why Slugs Are Often The Right Start
Slugs are simple.
They are easier to:
- build
- test locally
- deploy
- debug
- route through one app
- support with one TLS setup
- explain to early users
For many early-stage SaaS products, this is enough.
If you are still validating whether customers want the product, do not let tenant URL architecture become the project.
When Subdomains Become Worth It
Subdomains become attractive when the tenant identity matters at the hostname level.
For example:
- customers share the URL publicly
- each workspace needs a cleaner branded entry
- tenant routing should happen before the app path
- cookies or sessions should be separated by tenant
- you expect customer-owned domains later
- you want a clearer upgrade path to
customer.yourapp.com
Microsoft’s Azure Architecture Center notes that multitenant applications can use domain names to distinguish tenants, route requests to the right infrastructure, and provide a branded experience. That is the core reason subdomains and custom domains matter.
The Mistake: Scattering Tenant Logic Everywhere
The worst version is not choosing slugs.
The worst version is parsing tenant identity in random places:
- one helper parses the path
- one API route parses the hostname
- one middleware checks the database
- one background job assumes tenant IDs
- one marketing page hardcodes tenant URLs
That creates migration pain later.
Instead, centralize tenant resolution:
resolveTenant(request)That function can start simple:
- Read tenant from path slug.
- Later read tenant from subdomain.
- Later read tenant from custom domain mapping.
The rest of the app should not care which pattern was used.
What A Tenant Entry Table Should Include
Once you support subdomains or custom domains, a tenant entry becomes an operational object.
Store:
- tenant ID
- hostname
- target app route
- status
- owner
- verification status
- SSL status
- last seen
- created by
- updated by
- change history
- retirement state
This is where teams often underestimate the work. Creating the first subdomain is easy. Managing thousands of tenant entries over time is the real job.
A Practical Rollout Plan
Stage 1: Path slug
Use:
app.example.com/acmeThis is enough for product validation.
Stage 2: Managed subdomain
Add:
acme.example.comKeep it mapped to the same tenant ID. Do not fork your app logic.
Stage 3: Custom domain
Add:
portal.acme.comRequire verification and make ownership clear.
Stage 4: Lifecycle management
Track:
- active tenants
- paused tenants
- deleted workspaces
- old domains
- domains still receiving traffic
- entries safe to retire
This stage is where a simple routing decision becomes operations.
FAQ
Are subdomains better for SEO?
Not automatically. SEO depends on content strategy, crawlability, canonicalization, and internal linking. Tenant subdomains can make sense for public tenant pages, but they also create more surfaces to manage.
Are subdomains better for security?
They can help with isolation patterns such as cookie boundaries, but they also add operational complexity. Treat them as an architecture choice, not a magic security feature.
Should every freemium user get a subdomain?
Only if it supports your product promise. If most free users never share their workspace publicly, slugs may be better until they upgrade.
What should I design first?
Design tenant resolution and lifecycle states first. The visible URL pattern can evolve if the underlying model is clean.
