Notes on building software that lasts.
Occasional notes on the decisions that turn out to matter, which are mostly the ones taken before anything is built.
Rewrite or keep patching
Every team that has lived with a system long enough eventually wants to throw it away. The wish is usually genuine and the reasoning is usually wrong, so it helps to know which signals actually distinguish the two cases.
Reading a software proposal
Three quotes arrive and the instinct is to line up the numbers. The numbers are the least informative thing on the page. What a proposal actually reveals is how the people who wrote it think — and that is what you are buying.
Choosing a stack that lasts
Technology choices are usually argued as though the question were which one is best. For anything meant to run for years, that is not the question — and the better one has almost nothing to do with the technology.
What software costs after launch
Every project has a number attached to it, and the number almost always describes the build. The build is the short part. Here is what the rest costs, and why knowing it early changes what you ask for.
Custom software or off the shelf
Most of the argument happens at the wrong altitude — features against features, price against price. Five questions settle it faster, and two of the answers should stop the conversation entirely.