Web apps
The expensive part is deciding what it should do
Most failed software projects did not fail in the code. They failed because nobody wrote down precisely what the thing was supposed to do, so it was discovered during the build, changed three times, and delivered late as something nobody quite wanted. Writing the specification first is unglamorous and it is where the money is saved.
So we start with the actual process — who does what, in what order, and where it currently goes wrong. That produces a written specification you approve before anything is built. It also frequently produces a smaller project than expected, because a good half of what people ask software to do turns out to be a workaround for something that could simply stop happening.


