> using spreadsheets as a prototyping tool and letting those who understand the business hammer out the logic, before handing off to developers, is a great approach. A working spreadsheet is definitely the best requirements doc in the world
Just FYI, that approach definitely hasn't been my experience. A spreadsheet at a moment in time doesn't encapsulate users' true requirements (and they won't tell you what their real requirements are when you ask).
My story: I built a more "robust" version of the spreadsheet, with a normalized database schema, the very hottest UI framework, etc., and exactly the same logic. Some of this got pretty complex, of course: copying and pasting a bunch of cells is easy on a spreadsheet, but a hassle to build in a custom app. So it took some time.
I came back and showed the app to the users and found that the spreadsheet had actually changed quite a bit. Columns had been added for a new team, the widget approval process had sprouted some manual overrides, and more (the lack of an effective spreadsheet diff tool or change management prevented me from knowing the complete story).
I went off again, updated the app for the new process, came back to a changed spreadsheet, etc. We iterated for quite a while before the developers and the business gave up in frustration. The breaking point was when we were asked to add a calculation engine to the app so that users could add columns of cells with new formulas. (That's when I decided to leave that job and go help build a better spreadsheet).
Spreadsheets don't feel robust to developers, but business people do not feel that pain. If robustness is the main selling point of the replacement, I'd make sure that business users are screaming for robustness. I'd want dollar-signed disasters that were the result of too much flexibility.