Good if you can design them probably slightly worrying for the user as many off the shelf systems just don't seem to be able to cut it and requesting someone else to construct something for you is a real minefield.
Many off the shelf systems are very clunky for many reasons.
It is rare for a person to be highly competent in the field they are designing the application for, systems analysis, programming and business management. Without all these aspects in the project leader at least, the design is generally compromised.
Without fully understanding the processes involved in the use of the software the user interface can often be very klunky.
Without sufficient systems analysis skills the underlying architecture often hits brick walls when trying to get features to the next level. This crucial aspect of the design is often underinvested in the attempt to get something running as early as possible. The client's impatience can often be the worst influence.
Without good programming skills and an understanding how structure the program with flexible, reusable functions, code bloat is inevitable. The maintenace and costs of adding new functionality quickly ballons.
The manager of the application writing company often is less competent in any of the other skills than most of the team but carries excessive sway in the design decisions. Often under time pressure they fail to fully understand the implications of the decision they make.
In other cases the manager comes from an application user who saw it could be done better. In frustration they did learn how to program a bit and either saw the opportunity to go into business. Often their original application reflected their limited early knowledge but can be very hard to get away from the implications of those early design decisions, particulary when trying to maintain backwards compatibility.
Software design generally seems outrageously hit and miss and possibly why clients are so unwilling to undertake it despite the fact that they often really need it.
Most clients have their hands full doing their main activity. Those most capable of visualizing the specification or even recognising the need are usually stretched to the limit. Often they spend a lot of time dealing with problems created by the fools they have to work with, both above and below.
Programming requires a different state of mind from many other tasks. The ability to hold the entire project in perspective while intently focussing on details is crucial and quite rare.
I think continual change in procedures for things really frustrates users who then become suspicious of software companies that promise spectcular efficiency gains.
In my experience most users simply want a procedure and have no interest at all in understanding the principles of what they are doing. I have worked with purchasing officers who don't even think they need to understand anything about accounting. The mistakes they make couold only be the product of complete ignorance.
Ultimately there is a growing base of super users who are starting to bridge the gap between hard core programmers and users. I think to make databases truly ubiquitous you need to be encouraging as many as possible into this category. These people are the type of people that will be best placed to manage new system developments even if they are not talented enough to design their own.
Unfortunately many geeks are not very good at interacting with the super users and translating the abstract notions they present into program structure. They often start thinking code instead of structure way too early.
A lot of geeks are also stuck in ruts they fell into early in their career and simply repeat same design inefficiencies that although don't cause immediate problems can limit the versatility of the application for future development.