My experience is that application tuning does not have to be expensive, and is usually far more cost effective and faster than upgrading hardware.

I have a methodology that I use for tuning applications that use stored procedures. I run a trace for an hour or so for all activity during peak loads, load the trace into a table and then run queries to identify the stored procedures that are the biggest aggregate users of CPU, reads, or writes. My usual experience is that by tuning the top 10 stored procedures you can increase application performance dramatically.

I originally developed this technique one day when our CIO decided to initiate an emergency effort to split a poor performing application to run across multiple SQL Servers. This would have never worked, and I realized we needed to do something quickly. Using traces, I was able to identify four stored procedures that used 97% of the total CPU usage, and with about 3 hours of tuning effort with 2 DBAs working on each procedure, reduced the average CPU usage from a steady 100% down to about 10%. Further tuning of additional procedures reduced it to about 7%. Problem solved in a way that additional hardware could never have done, and the effort was completed in less than 2 days.

Now I do this proactively for critical applications to identify stored procedures that could benefit from tuning. I run a trace, look at the top resource usage by stored procedure, and tune the ones that could benefit. It is important to continue tuning on a regular basis, since new or changed procedures may become performance problems.