I hate to say it, but that sounds a lot like agile! I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-he

I hate to say it, but that sounds a lot like agile! I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-heavy platform where they could manage their fleet of locomotives and wagons, with a lot of computer assistance. The product owner was a gem. Once he warmed up to the process, we'd get him in a room and he'd talk and talk and talk about everything he found difficult. I mainly worked on the project alone, and bit by bit we addressed his issues. The issues grew more and more specific, until about 3 months post-release, where he came in and had nothing left to add. There wasn't even a wish list left. It was done. This was where I came to agree with the agile 'small batch size' approach. Mistakes come cheap and fast. Most mistakes are usually communication issues, rather than technical. That's not to say that requirements were changing while writing code - it's just that we had good feedback loops, and a short phase had us fixing the real problems faster.