Discuss Home · Bootstrapped Podcast · Scribbleton Personal Wiki · HelpSpot Customer Service Software · Thermostat NPS

SaaS Company Specific Subdomains


#1

Do you find company specific subdomains add value or are annoying? Do SaaS customers like subdomains - does it make their subscription feel unique? Groove does this and I’m not sure how I feel. But I always forget the login URL.

For example, http://awesomecustomer.mysaas.com


#2

In my opinion organization specific subdomains are more annoying than valuable.

I would not implement it in my SaaS.


#3

I’m neutral on them as a customer, and wouldn’t add that kind of complexity to my SaaS unless there was a REALLY compelling reason to do so.

As a semi-exception, I really DO like having something personally branded if I’m sharing an URL around all the time (e.g., my join.me link for screen sharing demos with potential customers). It adds a nice touch, I think. But it doesn’t need to be a subdomain – http://blah.blah/CoreyIsCool works just as well, IMO.


#4

For a long time it seemed that using subdomains was almost a requirement if one wanted a professional-looking app (particularly in the Rails community), but my general impression over the past few years has been that not using them has become more commonplace for SaaS apps.

If so, I think it’s a distraction we’re well rid of!


#5

For my SaaS I don’t use them. We have company specific business code used when logging in and never had a problem. If anything I think the business code is easier to remember than the subdomain, it is just a 4 digit number like 7553.


#6

I think it’s more of a hassle than its worth unless you need to do things like segment out some customers from others in your infrastructure. Frankly though that’s such a long shot that I’d say in most cases it’s not worth doing.

On the other hand, if you have user-provided content then you definitely want that content under a different domain entirely to avoid potential XSS and cookie exposure.


#7

“unless you need to do things like segment out some customers from others in your infrastructure.”

Good point. Which brings to mind that other potential SaaS time trap: the multitenancy question (which is probably worth its own thread).


#8

Another reason one may want to have a separate sub-domain is to place a customer-specifc SSL certificate onto it.

That is, until that new HTTPS feature is widely implemented, where the hostname is passed in the beginning of the handshake, so the server may decide which certificate to show.


#9

shudders

Yeah, it’s a rails app. It has not been a request from a single user, so I’ll put this brain-fart to rest : )

Thanks for the valuable feedback, everyone!


#10

FWIW, we use subdomains and the feedback from our customers is that this is very important to them. These customers are financial or large businesses, and we’re storing HR data, so security and data protection issues always come up. It’s not that they want their own URL or subdomain, but showing them theircompany.product.com instantly makes them feel like this is their server. Nevermind that we know that it’s a single Rails app running on a single server from a single (albeit, partitioned) database. We also use this scheme because there will probably be a requirement to actually run it off different servers / databases in the future. I think there are also added security benefits around domain-specific cookies etc and I like not having to remember to scope each SQL query by the company.

However, this scheme can be hard to manage, implementation adds complexity to the code / UX, makes overall metrics/analytics reporting difficult and a few other issues. I’d only do it for higher-price B2B products where the customers are only just getting familiar with SaaS models instead of on-premise installs. As a user though, if there’s any chance that they can be part of two companies, using a multi-tenant approach makes that switching much harder


#11

As someone that contracts to pay the bills, I find it somewhat nice that I can start typing a client name and get the appropriate things in my autocomplete.

That said, that’s a tiny fringe benefit and (also being a programmer) I wouldn’t take on the programming burden for something so small.


#12

Opposite to dgrace opinion is that I personally find subdomains a bit of a pain to use.

If I want to log onto my companies highrise/harvest/whatever account I’ll type in the first few words of “high” and expect Chrome to auto-complete - but that doesn’t work if using subdomains.


#13

I use subdomains in 2 of my web apps.
There are annoyances and benefits.

Annoyances:

  • users often forget what subdomain their account is on
  • different concept from the norm (ie. Facebook, Twitter)

Benefits:

  • Say you work for multiple companies/departments/etc., each can have their own subdomain and you can be logged on to all simultaneously
  • in the future, it’ll be easier to load balance (at least it seems like it on 1st glance)
  • if a customer wants a custom domain (not a subdomain), the infrastructure is already set up to do that

It depends on the use case of what you’re doing. Depending on that, the decision can lean in favour of one over the other. Other than for appearance/personalization, you can probably achieve the benefits of onw or the other with a little technical magic.


#14

It’s OT but @Rhino and @dgrace, have you compared Chrome’s auto-complete to Firefox’s?

For me it seems like Chrome is dumb as a rock when it comes to that, while Firefox shines when entering any part of a URL or title, a query string parameter, etc. I use both but am frequently disappointed by how unhelpful Chrome is in that regard (unless I’m missing something).


#15

Not really. I use Firefox at my current job and Chrome at home. The differences have never been striking to me, but my Chrome is pretty well trained having used it for roughly a billion years.