Under budget is a design decision, not luck
We closed a $3M platform rebuild roughly $40K under. None of that came from cutting corners — it came from three choices made in week one.
Every program I have brought in under budget looked, from the outside, like a program that got lucky. It never is. Under budget is designed in during the first two weeks, and after that you are just protecting the design.
The first choice is which unknowns you refuse to price. On a large platform rebuild there are always three or four things nobody can size honestly — a third-party integration, a content migration, a personalization ruleset. Pricing them as if you know is how you end up eating the difference. I carve them out, name them in the assumptions, and schedule the conversation that resolves them.
The second choice is who talks to whom. Most overruns I have watched were communication overruns wearing a scope costume. When a client department can reach an engineer directly, decisions get made twice, and the second one costs money.
The third is what the weekly report measures. If your status report only tracks completion, you will discover budget problems late. Mine tracks burn against scope completion in the same row, so the divergence shows up as a shape you cannot miss.
None of this is clever. It is just decided early, and then defended for nine months.