It's a Very Big General Problem
It really depends on just how much flexibility you want. I would normally spit on Sharepoint as a viable option but if you really are highly Microsoft-centric, I would at least look into it as it may save you a lot of the web stuff you would need to learn the years worth of self-training to be able to do really anything you could possibly want to do.
OOP and MVC
If you're not familiar with Object Oriented Programming, you should get a decent handle on that. And then get a decent handle on MVC (Model, View, Controller) and similar design patterns as it sounds to me like what you have is a big giant generic M-ish type resource and you want to start applying different Vs and Cs to it.
In principle M should really be tailored to a specific organization as it's meant to be all about business logic but people tend to think of it more generally as the pan-data-layer and this still works out from a somewhat helpful pattern perspective.
The idea is this, you have a bunch of specific rules for how to deal with transactions of a specific nature. That's your business logic plain and simple and IMO, all that M should represent.
Then you have your View which is the link between the user and your app. That's where all the input/output happens and your various UI widgets would be built.
C is the controller or app-logic. Many believe this should be a very thin layer that really just sort of passes stuff between M and V. I disagree. This is the app-logic layer. That's where database-related stuff like authentication and user data should really be represented IMO. M isn't about users. It's about transactions and how universal aspects of the business work or in this case the business of handling data for this commodity you've built something around.
The point of separating these things properly is that you can re-use them as assets in different contexts. Where it gets tricky is that MVC predates the web and the web is a little weird because there's this giant HTTP wall to send requests from the brower and receive responses from the server over.
IMO it's better to think of View role on the server side as the component that builds responses that you send to the browser. For actual loading of hyperlinks this might involve building HTML templates but it can also be stuff as basic as sending data to the right ajax request (Ajax put simply is merely an http request that doesn't reload the page automatically). Don't even think about the UI on the server. It doesn't need to control that. Just think in terms of requests and what hand off in terms of data so UI behavior can be established by code that runs in the browser (the JavaScript).
Service Oriented
And that brings us to what's called a heavily service-oriented thick-client architecture. The popular idea back when nobody realized JavaScript is awesome and the 2nd coming and all that and a bag of donuts was to abstract all that messy JS stuff away and do a thin-client approach by which I mean you had all your UI stuff sorted out for you with massive, clumsy, hamfisted, inflexible libraries that built the UI for you, but heaven forbid you wanted to modify anything. In .NET webforms they took it so far as to build and serve files straight out of compiled binary resources so you couldn't even really look at the JavaScript without a browser and then only a minified/difficult-to-read version.
This was messy, inflexible and generally awful. The general gist of modern frameworks is to let the UI stuff get handled on the front end (the browser) and not try to hide how the web works from the developer. In a service-oriented architecture, the client-side asks for data as-needed and decides what to do with it. This makes it a lot easier to modify the UI widget stuff because it doesn't have any dependencies other than the right JS file getting loaded on the page.
The Ideal Approach
So... what am I telling you here? I'm thinking that if you could learn everything you could possibly want to know via a vulcan mind meld, the ideal architecture setup you'd want for this is:
Something MVC-ish that makes it easy to re-use your big giant M in its totality and a lot of components you'll likely want to reuse from your Cs, plus a decent templating system to custom-tailor pages.
A service-oriented architecture for the server-to-client-side of things where any of your apps can make calls for data operations to happen and for client-side actionable data to get returned or updated in your DBs. Then you can do any widget your client-side skills allow. I imagine it's your re-usable C-bits that actually handle the requests consistently so that would be a big chunk of the re-usable C portion of the app.
Tool Choices
As far as tools, I would personally tend to use the following criteria for stacks/frameworks. The goals in my mind are always security, maintainability, ease-of-modification, and rapid turnaround (but not at expense of flexibility - which always costs more long-term).
Am I committing one way of doing things or bust or can I ignore/tell the tool to get out of my when I just want to DIY a portion of something. The latter is preferable.
Is it about having something that solved all my problems for me, library style, or is it about solving my own problems fast without sacrificing flexibility tool-set style? jQuery for instance is an awesome. jQuery-UI is a library full of stuff I can usually write better versions of in less time than it takes me to sort out why the pre-fab widget won't let me do something and come up with a workaround. Libraries can be okay, just not the ones that want to get their fingers in every cookie jar like EXTJS on the front end or .NET webforms (which is now generally considered defunct).
Is it popular with a fairly active community of people who actually write code well? Do-it-all-for-me solutions tend to always fail on that last criterion which is why I tend to dislike stuff like Sharepoint. Although really it's the CMSes that tend to be a security and maintainability nightmare whereas Sharepoint is probably secure at least.
Is it open source? There's nothing wrong with paying for stuff but the problem in software development tools is frequently that you never stop paying and the goals of the software dev tools inevitably get muddled by bad capitalism that wants to do things like lock you into a limited number of technology sets all from the same provider or punish you for trying to not use something they're offering. Open source tends to be lighter-weight, more flexible and written by people who take pride in their work because it's getting peer reviewed by highly opinionated programmers they want to impress rather than pooped out on a deadline with a bunch of crap design decisions that often have more to do with impressing the misguided user's boss than the user. That said, if .NET has appeal to you, .net MVC is perfectly reasonable. There's just better for free that you can develop from any OS, IMO.
But Realistically...
You're either going to need help or you're going to have to sacrifice some of the mad-modifiable designs I get the sense you want here unless you're able to work really hard at it (i.e. you don't have a spouse or dog to piss off). All the details of CSS, HTML, JavaScript and how to make them play together well for instance is something I've been at for over 5 years and am still learning new stuff about in spite of spending a great deal of extracurricular time reading up and geeking out on it. I'm moving towards becoming more of a generalist on the middle-tier but I've barely touched on SQL or establishing database schema in those 5 years.
