Are tenant-specific subdomains a good idea?

It depends on what the subdomain is for, if it's for hosting their own "thing" like a website, API or similar then it makes a lot of sense to have it early on since it's not very hard to implement (easy SSL with a wildcard certificate) and it can offer a sense of ownership to the user.

Just make sure you use a different root domain than your main website, for example for my project https://bluegenie.co, I use the http://bluegenie.dev to host my users' content. This is because I might need some of the subdomains later, like api. or whatever.

I have been using it in a project and I just love it. We have over 200 customers and the we let the customers choose there own subdomains. Besides the subdomains they are also alloweds to have an alias as well. We need this in some cases when they change there company name for example.

Beside the domain name we also use the tenant separation in the database. So each of our customers have there own SQL database. So in this way we could easily move bigger customers to there own machines.

It's hard to say for sure without knowing more about your product. From a purely technical point of view, managing tenant-specific subdomains is a PITA that rarely becomes worth it in the long-run. Consider the overhead of testing this both in development and in production.

As others have said below, hosting user generated content would be the obvious use case. But even then, tenant-specific subdomains are not always required.

I'm facing this exact design decision right now myself so interested to see the different opinions here. I am primarily for it, my main concern is whether it's going to cause any problems in future app integrations with third-party tools/APIs which rely on Oauth ' apps to be defined along with callback/redirect URLs.
I'm thinking of things like Zoom, Dropbox, Drive, Quickbooks, etc. In some cases, you can provide redirect URLs when initiating the OAuth process, other times you have to predefine them and in the worst case, there might only be one allowed.

I'd love to know if anyone else has faced similar dilemmas.

I’ve done this on my last 2 projects, and I think it works very well. Of course it comes down to your intention and business purpose behind it, as some of the other comments have mentioned. But implementing it wasn’t too challenging and I believe the clients appreciate it.

Depending on your DNS and hosting situation it could be more or less difficult to implement. I’m using Vercel and it was quite easy to setup, and they handle the auto SSL for all subdomains.

The only other problem I see is the Slack issue of later trying to connect different orgs. So you log into one org at one subdomain but really want to see several orgs on one page.

It makes it feel a bit more premium having that I feel. If it's a multi tenant platform the alternative is to have them enter that on login screen which some then might forget.

From doing similar on another project it makes sense. Any document download links are subdomain.product.com so users that exist in many places then need to log in to the correct tenant.

Just factor in the wild card ssl costs to out way the benefits.

I think if you have a B2B and your customer have mulitple users, then it is even expected. something like *.app.domain.com record with a wildcard certificate: *.app.domain.com which you can get from letsencrypt via a command line and a TXT record.
Now, you just raised 1 criteria. What about SSO for these domains, Schema separation of data, etc...
You can get drowned with details pretty fast. My suggestion: just start with what you know, less to maintain, just get it out there. When you feel your customers needs it, it would be an easy move and perhaps they will be happy with their new present. I am very disappointed with SAAS sites which takes big money for SSO which actually says, you want security? pay. What?
Good luck!

Unless you're building (or will transition to) a "proper" multi-tenant app (i.e. each customer is on their own server and/or database), the additional complexity (e.g. wildcard SSL) with each customer having their own subdomain might not be worth it.

If you're curious, reasons for choosing to go "proper" multi-tenant include:

1. Scaling server capacity. It is much easier to scale a database horizontally than it is vertically.
2. Scaling work capacity. If you are using queues to do processing, having each tenant having their own set of workers means that a single tenant cannot starve others by saturating the system. This a tag-along benefit from (1) since this comes somewhat free if you use the proper tooling.
3. Latency. You can deploy infrastructure closer to the tenant to improve responsiveness.
4. Compliance. You can ensure that the data stays within a certain region at-rest. This is important if you're touching any kind of regulated data (e.g. health, banking).