Ultimately, if you have special needs this post is not for you (and everyone thinks they have special needs 'til the market proves they're not worth a plug nickel). More important than special needs, you need productive needs -- needs which will keep you from having to engage in constant development of new software that does the same thing for you, on the latest flashy platform. In business you have needs to get a task done now; and to get a task done for a long time into the future. You need software that'll run for five, ten years without demanding you replace it.
Now, for generic software like office utility products -- word processors, spreadsheets -- you know how that works. Word processing is the same functional need for a massive part of the world. Everybody pays part of it. The software is produced for the masses. The seller determines upgrades based on their idea of keeping ahead of competitors. Although, there's precious little competition nowadays. There's due deference to backward compatibility, and it's enough to get by to the next upgrade.
But how do you achieve productive improvement for non-generic software?
1. You pay developers to make the entire thing. And pay 'em to maintain custom code, til you run out of money. Dang right, it's expensive. Every wheel has been reinvented. (And don't get me started about Struts, Spring, etc. -- when as much code is needed to use an architecture as it takes to develop the same wheel, you've not really gained anything.)
2. You buy a platform which gets you really good pieces of the application (components) -- you can see the pieces and know pretty-much what data you want to drop into those pieces. Then your developers assemble it into something you want. Remember the erector sets, or even Lego models you built as a kid? You can think of it much like a "kit-box" type of configuration. All the useful pieces exist in the box for you to assemble what you want: access control, data services, application components (multi-record handling, individual record handling, data field handling, API, etc.)
Normally you have to ask quite a bit more about a platform, to assure yourself you're not being handed too much custom work to do.
Also, something new and different in the kit-box: you decide you want something custom. The platform allows for custom additions.
Finally, it's gotta have a big footprint that's covered, solely by the system. Again, this is not a monolithic, takeover type of system. But the API for it has to be extensive.
It's normally reasonably possible to tell if you have a full-featured system. My rule of thumb is to ask about the access control API, for instance. If you have a nice, full-featured system, you can control accesses using programs calling the API, down to the record level, in about 20-50 lines of code. But that's my rule of thumb.
Oracle and most database products provide all this, pretty clearly. As long as you're willing to open your database server to the client you're talking to, you can get this set up. Still, it takes some work. Offering users the ability to specify their own access controls on Oracle records, that can be, ah, interesting. I'm not completely familiar with the frontends Oracle offers, either. Being Oracle, they're not going to want to play well with other data systems you might want to migrate to. There's also that disconcerting 4000-byte limit. Extensibility has never been Oracle's strong suit.
Microsoft does offer a lot of this stuff. I think the components are pretty slim pickings, so the cost of code development is still going to be pretty high. But it can be done. It has always seemed to me that Microsoft has made such small building blocks, that it takes a lot of coding glue to put 'em together.
IBM though, it has some pretty strong background here. Its JSF component model in Domino XPages offers a whole lot of component flexibility. Integration with data sources from the server or from a specialized client, both work. Scripting's available in so many different places that, where you need it, it's likely you can code it. But most significant -- many times you're just scripting around a few components.
So the cost of development drops dramatically. Because you're not writing code: you're assembling components.