Tell me more ×
Answers OnStartups is a question and answer site for entrepreneurs looking to start or run a new business. It's 100% free, no registration required.
up vote 5 down vote favorite
2

I have recently been tasked with developing an online portal for the real estate agents. I am planning to make the code as generic as I can so that I can use it as a product for the other industry shareholders such as mortgage lenders, small local bankers, closing attorneys, etc..

Each agent will have his or her own content pages (like about the agent, available properties, recently sold, call now, contact, etc.) with specific individual information. As a result, each agent will have a dedicated PURL.

What is the most user-friendly way of creating these types of PURLs?

I know that there are 2 main ways with different approaches:

accountname.site.com

Account name can be FirstNameLastName (as long as it is unique), dynamically generated by the server or let the agent decide what it would be with some limitations. I guess this is more like creating a subdomain.

There are great examples to this way:

http://123.wordpress.com

http://123.weebly.com

http://123.blogspot.com

http://123.netlibrary.com

site.com/accountname

Similar approaches that I gave above apply here too. Account name can be firstname.lastname (as long as it is unique), dynamically generated by the server or let the agent decide what it would be.

There are great examples to this way too:

http://linkedin.com/456

http://twitter.com/456

http://cvonthe.net/456

http://flavors.me/456

http://ted.com/456

Some are even combining both ways:

http://DealerName.audi.com/SalesmanAccountName

Technically speaking, I will be employing URL Rewrite method (unfortunately on IIS 6) therefore both ways are doable and will probably take same amount of time on my end.

Looking forward to your suggestions.

Thank you!

This question is actually an extension of the following question:

Offering Different Authentication Ways to Non-Technical Users

share|improve this question

4 Answers

up vote 6 down vote accepted

"accountname.site.com" will get a little unwieldy if you grow to several thousand accounts and need multiple frontend hostnames (say multiple load balancers) at the same time. It is possible to handle this with both "site.com/accountname" and with "accountname.site.com", but it's simpler in the former case.

With "login.site.com" or "www.site.com/login/" you have a single DNS record that needs a 'fancy' configuration ("login" or "www" in my example). You can assign multiple IP addresses, or use split horizon DNS for this specific record, or even offload the DNS subzone completely to a 3rd party geo-aware DNS provider.

With "accountname.site.com" each "accountname" could/should be a separate DNS record. Actually this gives you have far more flexibility, but to use that flexibility would require a more complex application, where the account provisioning logic is connected to your public DNS.

But while the above future growth consideration is valid, it may also be premature to worry about it now. You don't have several thousand accounts yet. :-)

Personally, I like a single place to log in, with a single form (email address and password) as the simplest option and most common option. The place to log in could be "login.site.com", or just a login form in the top right of your main website (www.site.com).

There is another thing I think you should consider. Perhaps your real estate agents would really really want "vanity domains", i.e. "shop.estate-agent-domain.com"? It's common among small business owners to want to 'own' the branding and external marketing. Vanity domains can be accomplished in many ways, the easiest is generally:

  • Have a 'gateway' server, a specific front-end application server with the right software in place to handle many virtual hostnames.
  • Having a single DNS hostname for your gateway server, i.e. "gateway.site.com"
  • The real estate agents map an hostname of their own choosing as a CNAME to "gateway.site.com", i.e. "shop.estage-agent.com" points to "gateway.site.com".
  • Real estate agents configure their domain info inside your application.
  • The application server code on "gateway.site.com" looks in the HTTP 1.1 header for the domain name, and returns the appropriate customer-specific content.

HTH,

share|improve this answer
Great point about vanity domains. If you go with the subdomain option, vanity domains will be easy to implement later with CNAME records, as Jesper mentioned. There are some limitations with CNAME RRs: serverfault.com/questions/65712/… – Clint Dec 22 '10 at 9:54
Great input, Jesper. Looks like "accountname.site.com" would be providing more options such as vanity domains. And, you are right that most SMBs want to maintain their own brands. Thank you! – ncakmak Dec 22 '10 at 14:31
@clint @ncakmak : "accountname.site.com" does not make vanity domains easier. In all cases, your application server needs to inspect the HTTP header in order to know which account to answer for. See en.wikipedia.org/wiki/Virtual_hosting about the HTTP headers and en.wikipedia.org/wiki/Wildcard_DNS_record about some possible gotcha's with "accountname.site.com" DNS. Just to be clear, it's a fully viable way to go, but "accountname.site.com" is not easier than what I describe, it's just different. – Jesper Mortensen♦ Dec 22 '10 at 16:41
up vote 6 down vote

client.sitename.com.

Here are the reasons: Each subdomain is treated by search engines as a different site. Users of your site can add a domain instead of their subdomain by using a CNAME. This is a lot cleaner than the approach of redirecting .

The challenge you run into with that structure is: 1. You need a static IP so you can do wildcard hostnames. 2. If you end up offering your own real domain service then make sure you manage your own dns via api, this is important in case your server IP changes or if you need to split up the sites among servers. Zerigo is good for this.

Also with the subdomain strucutre you could do some really neat things: frank.example.com/photos/ or frank.example.com/resume/ versus example.com/frank/resume

Also, you could redirect www.site.com/username to username.site.com with url rewrite redirects.

share|improve this answer
Thanks, Frank! I am going to take a look at Zerigo. – ncakmak Dec 22 '10 at 14:29
Well, SEO does not matter if the URLs are private (like this case it seems). Of course, they're treated like different websites, but what are search engines going to crawl? A login screen? – Dario Solera Dec 22 '10 at 17:31
Search engines can always crawl based on a Sitemap.xml file. – Frank Jan 19 '11 at 3:36
up vote 0 down vote

My doubt is that when using client.zzz.com competition will be more easily to revel the names of you clients. For security reasons it will be better to use zzz.com/client

share|improve this answer
1  
Except he is developing a portal where his clients have their own areas. As such, the exposure is there by default because it is wanted. – NetTecture Dec 21 '10 at 17:30
It seems I misinterpreted his question. In this case this site works like a portal for businesses. – Ross Dec 21 '10 at 18:00
up vote 0 down vote

Thank you for all of the responses.

I printed all these comments and answers, and showed them to the customer when we met face to face.

We finally ended up with the "accountname.site.com" option because of its future flexibility.

I wish all of you and OnStartups.com members a happy new year!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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