Should I Build my application in SharePoint vs. ASP.net

Many times, I get question from my customers if they should build a new application in SharePoint or ASP.net. 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 ASP.net 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 ASP.net 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 (https://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx)
  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 ASP.net, 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.