Alright, let me shine some light on the ambiguous question. We have an analytics application written in Angular 2 and Scala that's used by quite a number of businesses. Some time last year there was an idea to use the apps' charts and features to display different type of data for a very limited number of customers for a higher price. Since time was of the essence we optimised the front-end code, abstracted the bunch of visualisations and it worked like a charm. One Angular 2 codebase powers two solutions.
Few months later the problems started. Since the business customers of the 2nd solution pay a lot of money and the solution needs to be slightly tailored to almost every one of them, they started asking for different features, custom add-ons etc. The app starts turning into a weird behemoth where 80% of the code is old analytics and 20% is custom if-checks to determine which of the 2nd solution's users it is and how we should change the behaviour of the component for him.
The 2nd solution was developed very quickly as a proof of concept/hack. I offered to split the codebase, because the current one is slowing the development of the core analytics platform and is a source of bugs occasionally. The argument against it is that the company wants to keep adding features to the later solution, so they want to keep in in one codebase.
Other option is to split the codebase and abstract all the common components into a module that is then injected into two apps, but it's a lot of work and the work on the analytics platform will suffer because of that. Also, since the product features tend to change a lot due to new ground we're breaking into, we would have to keep changing the abstracted modules every now and then which would then require making sure they still work in both applications, so the devs working on analytics would be still slowed down by requirement to maintain compatibility with the 2nd solution.
The front-end of both solutions looks very much alike but they serve similar, although different purpose. It doesn't feel right to have them in 1 polluted codebase.
What are your thoughts on that? What other solutions can we implement?