Building custom software is nothing like building a cookie-cutter tract house - completely agreed. In that case you're getting the same house as someone else, the builder has done it all before, and there are only a few options that you get to pick with the costs for those options known.

Building custom software is a lot like building a custom house, though - while there's an estimate going in, it tends to change a lot, and the final price varies widely depending on the buyer's choices during the project. Try being the general contractor on your own house construction project and you'll quickly discover costs are very variable regardless of the estimates up front.

There are a lot of stereotypes about how construction projects are "fixed bid" and "everything runs off of well-defined blueprints"; my Dad is an architect working on large healthcare projects, and I can tell you that those stereotypes are largely wrong. The projects do not go according to plan and even things "in the blueprint" change regularly mid-project.

I’ve been given some of those BDUF software projects in the past and they’re definitely painful - if not impossible to deliver. The only reasons they were successful were that the clients were enormous and ultimately paid for us to keep modifying spec documents as we went along.

We planned for that going in and the fixed price agreement was loaded up with all kinds of contingency (read, lots of extra cost to the client). In the end, it cost them more and delivered less. Sure, they got a great “as-built” plan showing exactly where things were different from the original blueprint - but having a great looking plan wasn’t the real goal. The sad part was that we could have done so much more feature development with that extra money.

Early stage entrepreneurs (which is who the post is about) are different. They don’t have the time or the money for that kind of inefficiency. They need an app that works. Now.

We do some up front work with them to lay out the flow of the major features. Then the client prioritizes them and we start with the most important thing first. We push new code very regularly and they tell us when they think it is working well enough for us to go to the next feature. Not sure that would be realistic in a fixed price model.

I like your final point in the BDUF post - that the development of the software is organic and ultimately determined by the process. Sounds like a great rationale for T&M vs. fixed price!