3 weeks later we launched an I18N release. Our customers stuck through the whole thing and worked closely with us to make LineBuzz work in their languages and charsets. Here's the story if you're interested:
Many of the I18N issues we solved we only discovered because we had a large group of international users working with us. Things like the shift_jis character set not round-trip mapping to unicode. Not the sort of thing you can anticipate on paper.
If I had to do it again, I'd do it exactly the same way. Next time we may discover that the app is only used by english users and the urgent need is to fix some privacy issues.
Most companies that plan everything out on paper tend to have a large number of non-technical folks. MBA's and the like. When you're building a consumer web business, your business plan is expressed as a piece of technology. So why not just create the technology instead of talking about it. And instead of using english to describe your business, use Ruby or Perl or PHP or Java.
ps: Sorry you feel you're getting trolled.
It's true that his advice does tend towards shrink-wrapped software, where it's not so easy to just go in and fix something after you've had real users testing it. But what you describe is closer to what he'd call "hallway usability testing." That doesn't rule out a spec as a valuable component of the development process.
Anyway, the test for the value of a spec really shouldn't be taken after just 4 months.