When the individual customer needs are so wildly different that shared functionality represents less than 50% of the features for a given customers needs, then there are really only two major ways to handle this:
Writing a custom page for each individual client
This tends to sometimes be an unsavory option for both technical folk as well as business and sales folk. It can also be unsavory if the client realizes that you are performing a lot of custom development to meet their needs.
As a developer, high maintainability is one of the central goals that we should strive to accomplish, so writing custom pages for individual customers is counter to this goal. Assume that a common feature must be added that should affect all customers, now this change must be manually implemented for all clients and tested for each client that has a seperate implementation for that page. If you have a number of clients then this can simply be untenable over time.
From the business perspective as an ISV, we like to build a product, which is typically more involved than just the software itself. Selling a software product implies that as a vendor, we have a single package that can fulfill all of the customers needs with minimal to no customization to the core of the product itself.
When product customizations need to occur to accomodate a client, then the product may be a poor fit, or may have just been poorly planned. It may be that the solution that is being sold cannot actually be considered a product at all, but is simply being marketed that way. The software business can be tricky like this and is why product owners and sales people make the big bucks because this winning formula for success in selling software can be extraordinarily tricky. If you don't market it right, or form a product idea correctly then you may not sell or you may sell and be unable to deliver on promises.
All clients like to feel that they are getting a good deal, and when they buy a software product they want to believe that all of their needs are being met out of box. This is why software products sell more readily and easily than just custom software development, even when the client needs are so inherently specific that no such product could ever exist off the shelf.
If the client finds that you are performing a good deal of custom software development for their needs alone then they lose faith that your product ever had the ability to deliver and that they will end up paying dearly for it in the long run to cover those custom development costs.
When is this a good idea
If the software is in a niche market with a small amount of customers and limited opportunity for growth, then custom web page development for specific features is probably the best choice.
XML based layout and rules engine
Basically you would identify core functionality to be built into pages, and anything customer specific should be defined through a custom layout and rules engine that allows client needs to be customized outside of the code base.
The technical design considerations for this are that
The client needs at this point become a schema change through XML rather than en expensive maintainability nightmare of a code change. Controlling layouts through XML to define your view, XML to tie in your model, and rules to define your controller will allow for a solid architecture that will scale as your business grows and also maintain loose coupling, high cohesion, and high maintainability. These XML documents can be easily maintained through a NoSQL or even traditional RDBMS systems.
Limiting targeted releases to accomodate customers bolsters the strength and scalability of the product as a whole, and leaves the business confident that they have the ability to grow rapidly in a wild and volatile market. Some disadvantages are the increased complexity of the application and product itself, and the considerations towards increased initial development time and the higher costs associated with this.
Clients can feel confident that their needs are being met through the product without significant cutomization and that their requests and changes can be rapidly accomodated.