Salesforce.com was originally built as a CRM tool. It's been amazing to see it evolve. I've even begun to see it used to model non-business processes. A co-worker recently used it to manage her wedding's guest list. Everything was stored in our product -Who will be able to attend? Would they prefer Beef, Chicken or Fish? What gift did they give? Has a Thank You card been written yet? The application didn't take very long to build and because of the wonders of SaaS multi-tenancy, my friend got to leverage our reporting module without any extra work!
One thing salesforce.com can't do yet is build custom user interfaces. The building blocks have been exposed, but they're the equivalent of 2x4s, nails, plywood and copper pipe. It still requires traditional software development skills and processes to build a sophisticated custom UI. I've heard that there's a solution coming and I'm excited to hear more about it.
Until then, I'll keep working with JavaScript and ASP.Net 2.0. I just finished up a paper usability study with my current customer for a web-based replacement for their exsiting Excel application. Jakob Nielsen's not surprised, butI'm always amazed by how effective paper prototyping is. I was pretty proud of my hand-sketched design, but after spending an hour with the future user of the system, I discovered a number of workflow flaws. According to Steve McConnell, a requirement that goes undetected during the requirements phase "will cost 10 to 100 times to fix during testing."
It's going to be tough for our ASP.Net 2.0 application to beat Excel for flexibility, but on the upside, our web app is going to perform validation, will use dynamic data sources to populate picklists and will store all user-entered data in a cental location, so our customer will never have to worry about data synchronization issues.