I developed on enterprise PM application on the SharePoint platform (V2, WSS3.0). Over the past year, I have done 3.8% support, and the rest development. I'm quite happy with that.
I've recently been aquired by a larger company who develops a similar product, same windows stack but without the SharePoint flavour. They do an inordinate amount of support. But they do it to themselves - they give their clients the means to beat them up about support: multiple support channels, nd aaggressive SLA's. They have a team of 12 developers and they're always under pressure to maintain their support processes.
Sounds like you need some strategic architecting input: which products are important; what functionality can (needs to) be reeingineered; what's profitable and what isn't; what is a realistic support process, timeframe, etc?
Then once you've been through all this, you realise how important it is to design simple, reliable products.
I've recently been aquired by a larger company who develops a similar product, same windows stack but without the SharePoint flavour. They do an inordinate amount of support. But they do it to themselves - they give their clients the means to beat them up about support: multiple support channels, nd aaggressive SLA's. They have a team of 12 developers and they're always under pressure to maintain their support processes.
Sounds like you need some strategic architecting input: which products are important; what functionality can (needs to) be reeingineered; what's profitable and what isn't; what is a realistic support process, timeframe, etc? Then once you've been through all this, you realise how important it is to design simple, reliable products.