Very astute. I incorrectly assumed the planning and design analysis was a known entity since there was a prototype written several years ago. I have updated my initial response with a link to SDLC and planned to add a more in depth response later if someone hadn't already. Then I saw your response. In reading it, I think there is still additional information that may be valuable to pileofrogs. For large projects needing hardware, COTS licenses, architecture decisions before software development can begin, testing as you have described may not be option. Acquisitions is the part you need to get right the first time because of the cost (time and money) of being wrong. How then can you determine what to buy if it costs money to test which is best?

I know that this is probably very much not the case here as pileofrogs will find that disk I/O is the largest bottleneck and the best way to resolve the issue is to be smart with his database design, caching, and SQL. Assuming a free database and no solid state disks in the budget to eliminate IO, this all falls back to software and your points are spot on. I just think that, by their own admission, being unware of standard process for design decisions should mean doing more research. For instance, learning how to find and interpret independent market research instead of believing what a sales rep tells you about their product being perfect. I don't currently have the time to do this myself but since you seem to have far more experience than myself, if you have links handy that would be great :-)