Is per-company subdomain or single URL better for web app

Question

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.

Answer 1

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

Answer 2

Definitely use a per-company subdomain.

There are 2 different ways you can do this:

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

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

_{¹ 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}

Answer 3

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.

Answer 4

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.

Answer 5

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.

---

Summary

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.

Answer 6

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?