Should I Build my application in SharePoint vs.

Many times, I get question from my customers if they should build a new application in SharePoint or For certain kind of applications such as Collaboration or KM Portal, Internet facing web site, intranet social networking site, applications requiring browser enabled forms or Enterprise Search, SharePoint is THE option to go for.

However, it’s not a straight forward answer for all types of applications. You need to look at different aspects before deciding. I’ve put a high level list of questions that I use to make such decisions. Hopefully, the questions should help you also.

  1. What are the features that you are going to use out-of-the-box (OOB) from SharePoint (site provisioning, search, version control, roles/groups, easy forms (list edit, new, view pages), collaboration, workflows, content deployment, alerts ) )
    1. The list of feature is huge, have a look at evaluation guides for complete list: WSS, SharePoint and Search
    2. If you are not using any of these features what’s it that you’d gain from SharePoint?
    3. If you need these features, why are you thinking of not going with SharePoint? What’s the effort if you custom build those features?
  2. What are the features that I’m going to build custom (for example, reports for some applications would be custom and need relational tables with transactional support)
    1. How much effort is required for custom development in vs. in SharePoint? Is the difference huge?
  3. What kind of application it is? Is it one off application, or this is going to replicated across many teams. SharePoint is an excellent platform where you need to replicate one type of site to many teams.
  4. What are the required Scale and Performance objectives of your application
    1. SharePoint has some boundaries, most of these can be avoided with adjusted design or workaround. Would the adjusted design or workaround be acceptable to your users? Examples:
      1. 2000 list items at a single level – a well know limitation
      2. 2000 security principles for a securable object – a lesser known limitation, but this can create problems when users in a site collection grows more than 2000 – there are workarounds for this (such as using AD security groups) – are those acceptable?
    2. SharePoint may not be able to match the performance of a plain application as it does a lot more work (security trimming, getting files from database etc.) Can your performance targets be met using SharePoint?
      1. You can check benchmarks published by Microsoft or other vendors (such as HP, Intel) to see if SharePoint can meet your requirements. Links to most of the benchmarks are available in this blog post: SharePoint (Performance, Stress ) Load Testing 
  5. How many employees would be using these application? How many requests you can expect for customization from different teams. Remember, SharePoint provides a pretty good platform for customization and personalization.
  6. How much time do you have to build such apps? Can you use some off-the-shelf solutions? For examples, there are many custom applications which be deployed in no time by using WSS Application Templates (
  7. What’s the cost you can afford. Remember, you need not buy any separate license, if you are only using Windows SharePoint Services. Have a look at difference of features between WSS and MOSS in the comparison Excel spreadsheet.
  8. What skills your developers have? Though SharePoint is based on, but you need have additional knowledge to develop SharePoint applications. Also, development is SharePoint is not like normal .NET development (for example, you don’t get WYSWYG designer to develop web parts for SharePoint). You also need to take extra care to follow same build and source control process that you do for .Net code. Have a look at Application Lifecycle Management Resource Center for SharePoint Server for more details.
Comments (9)
  1. Toni says:

    Nice article Sanjay, can you explain or point me to documenations about "2000 security principles for a securable object" limitation. Thanks.

  2. Hi Toni,

    If you look at referred article Plan For Software Boundaries ( – you’ll find more details on this. From that article:

    "The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope.  If this limit is reached, indexing of items in that scope, and all items below that scope, to fail. "

  3. Toni says:

    Sanjay, I am bit confused about "scope" here. It is not clear what is a scope… does this mean that I cannot have more than 2000 items with unique permissions or I cannot have more than 2000 custom permissions (e.g. users/groups) per item?

  4. Pervesh Dhingra says:

    Article is very helpful if someone is new to the sharepoint and wants to develop application on MOSS 2007 Gr8 Snajay.

  5. Toni – scope is any securable object. In SharePoint, it could be an item, a folder, a web or a site collection (this is the biggest scope that you can have). Sum total of all security principals (users/group) should not be more than 2000. Generally, you wont hit this limit for an item. But consider, you have item level permissions in a large site collection. Every user you add to a list item, also get added to site collection also (with limited access permission set). You need to ensure, unique users/groups across all items should not go beyond 2000. Hope this clarifies.

  6. jaskis says:


    Few things which (were missing in abovetable ) will matter for decision making would be:

    1) Are they willing to invest more time in developing application  . If no then Sharepoint is the answer .For example we can get the survey application up within mins(using Sharepoint) rather than days ( coding)

    2) Secondly Sharepoint has inbuilt search functionality . If one goes ahead and write in own code (1000’s of line) . It will take months for that + testing cost?

    3) Also things like whether it is intranet site / internet site . How much functionality is dynamic . Say if they only have 1 page/section which would be dynamic . Then getting this on Sharepoint would be discouraged.

    List goes on….

    In simple words if Customer has “budget to invest” + “Time constraint” + “VAST Dynamic Functionality”  == Sharepoint



  7. Em says:


    This article addresses build in Sharepoint vs build traditional apps. What are the considerations, and how would one approach the build in Sharepoint vs buy enterprise .net solution scenario. if an off the shelf package meets the business need (a .net + SQL db app), what is the motivation for building in Sharepoint?



  8. The Mosh says:

    Shrepoint is a document management system and a middle of the road one at best.  There are some advantages to build in sharepoint but not many AFAIC.  Share point is expensive, bloated and poorly performing.  I would never use it to build my corporate brain trust apps ever.  I think share point has lot of the "kool-aid" factor and far too many people have drunk up!.  Give, MVC, WCF, etc for al enterpise cash cow applications any day.

Comments are closed.

Skip to main content