I'm writing a web application, the application is for small companies where each company will have multiple users.

What is better:

  1. giving each company a sub domain (so you access the app at my-company.example.com)

  2. everyone access the service at www.example.com (in this case you have to enter the company name in the login page).

I'm asking what is better from a usability perspective, both will have the same complete separation between companies and both require the exact same amount of work to implement.

Update: most (if not all) of the company's employees will use the app.

  • 4
    Whatever you do, avoid the problem 37signals had with Basecamp, where visiting Basecamphq.com didn't show a log in field for the first 5 years of the product's life cycle (they only just added a log in form in 2009). This was because users were expected to log in at the subdomain xxx.basecamphq.com. – Rahul Aug 22 '10 at 21:33

I think it depends who is supposed to use the app. If the customers or employees of my company are supposed to use the app, it would be easier and more comfortable to use a sub-domain (also this could allow personalization of the page with a logo etc...).

If the app is meant to be accessed by only a few admin level type people than it is probably easier to just login to the main app and set things up there.

For example it is simpler for a single user to use gmail but for an organization it is simpler to use Google apps. Although it takes a bit more work to set up it is then specialized for my company


Definitely use a per-company subdomain.

There are 2 different ways you can do this:

  1. company.yourcoolapp.com
  2. yourcoolapp.company.com 1

The difference between the two options is slight, but to me, it seems like with option number one, the software user sees that their company is being allowed to use your software on your domain (which is probably the case). They may or may not feel like they have ownership of the data they're entering (depending on what your app actually does).

With option number 2, the software user sees that your app is a part of their domain, almost like the data/application is hosted by their company. In this case, I think the user would feel more like the app is a part of their company, rather than an outside product they just happen to use.

You can even have both URLs set up, having one of the domains point to the the other. This is how Blackboard (an education software package) does it at my University:

  1. http://unco.blackboard.com
  2. http://blackboard.unco.edu

1 This may be an ugly-looking URL if your are writing an application that the well-known law firm Dewey, Cheatem and Howe might use: http://mycoolapp.DeweyCheatemAndHoweAttorneysAtLaw.com

  • I never considered the spelling of Dewey, Cheatem and Howe. Now I know. – JeromeR Dec 11 '10 at 18:56
  • 1
    There is a huge difference between 1 and 2, in that 2 is many many orders of magnitude more complex. What if a team at Google wanted to use your application? You're going to ask them to add a "yourcoolapp" subdomain to the google.com DNS? What about certs etc? Seems extremely impractical. – robomc Nov 21 '16 at 0:15

Having a sub domain gives a stronger sense of ownership (and perhaps privacy).
You can make the landing page of the sub domain customized, with the company's logo, news, etc.

On the other hand, if you use one central page, the only branding of your organization (the service provider) can be there.

If you do have just one page, make sure you support URLs that automatically fills the organization field, so your users can send direct links.

Come to think of it, maybe you can skip the organization altogether:
Might you have cross organization users?
This means that Beth works in Org A, which provides services for Org B, so Beth has to log into both organizations.

If that's NOT the case, then users can log in from one central page, and not have to fill any organization field since she'll be automatically associated to the right one.

Having said that, then it can make more sense to log in from a different sub-domain.


For our app, we decided to combine them, and we think it works pretty well:

  • Users can visit ourapp.com and click on "Sign in" to be redirected to the sign in screen
  • Users can visit the sign in screen directly
  • Once logging in, all users are placed within the "Logged in" environment at xxx.ourapp.com
  • When users create an entity in our app, they can give it a subdomain name at yyy.ourapp.com
  • yyy.ourapp.com is "client facing" and therefore shows no branding of ourapp, including any sign in links.

We decided not to do the "enter the company name at the homepage" part, as we realised that it would be better from a database and domain model point of view to just let everyone have their own "account" and sign in with that, and then write business logic to associate users with each other. Technical stuff, but sometimes you have to consider that when designing the user experience.


There are 2 things to consider before you choose one of them, which are:

  1. Site Security.
  2. Site SEO.

Personalized Subdomain

If you need a tight security, then you should go to personalized subdomain, there are several things that will tightened your site security when you choose personalized subdomain, which are:

  • No Google Indexing. You can avoid google indexing your private client site, and you can safely index all of your www site without worrying your system will be compromised.
  • Avoid site hacking from viewing your robots.txt. You can safely disallow google from indexing several of your pages or directory structure, but someone can easily peek into your robots.txt and find something precious there.

If you prefer security than search engine optimization, then you can choose personalized subdomain, but the implementation is a bit tricky, don't use dns to add a cname or an a record to your subdomain, simply add an a record for *.yourdomain.com, and you can safely manage your subdomain with vhost from your web server, so no one can enter the subdomain without knowing the exact name of it first.

Personalized Subfolder

If you need to optimized you site rank in search engines, you can use this method. You can prohibit some places to be indexed by search engine with robots.txt, and hopefully no one knows where it resides. Also you can have your site rank higher than the previous method, because all of your client visit your main site, rather than their own subdomain.


I personally choose the first option, since I cannot afford loosing some pages to be unintentionally indexed by search engine, or someone somehow found my robots.txt. If I need SEO more than ever, I can simply create a blog for the company and have it indexed, that would attract more people and have a higher unique visit, and increase rank, rather than risking my system easier to be compromised.

  • I don't understand this answer at all. Subdomains can be indexed (or not) just as easily as any top-level domain. How do you think this site is indexed in search engines? – Charles Boyung Dec 10 '10 at 15:16
  • Yes, you are correct, subdomain as well as top-level domain and all of it's content can be easily index (or not). But in my opinion, I focus on preventing site abuse such as peeking at the robots.txt where you can found precious path by removing the whole web app to it's own subdomain so that non-member cannot enter the web app without knowing the right url. If you were using robots.txt to restrict search engine to crawl certain path, someone can peek into your robots.txt. Once again, it depends on what you choose, would you choose SEO over security or otherwise. – Hendra Uzia Dec 11 '10 at 7:47
  • Your entire statement here is flawed. In fact, what you are saying makes absolutely no sense. If the app has its own top level domain, it isn't going to get indexed either, unless you start linking to it on the web/submitting it to search engines. There is nothing in a top level domain that magically gets it put into search engines. Also, if you're trying to use obscurity as security, you've got some serious flaws in your application. If you have a web app, it should be secured with some sort of login, which would prevent indexing anyways. – Charles Boyung Dec 13 '10 at 14:35
  • And also, what in the world does robots.txt have to do with anything? – Charles Boyung Dec 13 '10 at 14:36
  • Sure, it has to be secured with some sort of login, but let me show you my point of view. There are many ways to compromise a site, here I simply removing 2 possibilities which are, preventing non member to enter the private login, and preventing your important not-to-be-indexed path in the robots.txt to be seen by public. Of course this problem can be resolved in many ways, and I'm not forcing anyone to do it this way, I'm just showing this is how I've done it. – Hendra Uzia Dec 14 '10 at 5:36

With the caveat that with your second solution the user would have to enter their company name, the only good solution is the company subdomains. Think of it this way - with solution 1, here's what the user has to do:

  1. Go to the site URL
  2. Enter their username
  3. Enter their password
  4. Log in

With solution 2, here's what they have to do:

  1. Go to the site URL
  2. Enter their company name
  3. Enter their username
  4. Enter their password
  5. Log in

Why add the extra step if you don't need to? Also, making the user type in their company name is extra cognitive load because now they need to remember how to enter their company name correctly. What happens if they typically refer to the company via an acronym or a short name? What gets used for your login page? Why make the users remember that extra detail when they don't need to?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.