The software industry has a famous failure mode. You scope a project at three months. You deliver at nine. The client is frustrated, you are over-committed, and the result is a codebase that is bigger, messier, and less valuable than what you both imagined at the start.
This is not inevitable. It happens because most software projects are scoped wrong at the beginning. Specifically, they are scoped by asking the client what they want, writing it down, and estimating the document. That method always produces underestimates, because the client names the features they can think of, and you estimate the features as if they are independent. Neither of those assumptions is true.
Our scope method is different. We do not estimate the feature list. We estimate the shortest path to the first version that is useful. Then we ship that, and we see what the client actually does with it. Most of the time, once they are using something real, the feature list they thought they needed contracts by half.
The specific mechanism is a four-week first milestone. The first four weeks ship something that solves the single most important problem. Not "a beta version of the whole system." A complete, production-grade solution to one narrow thing. The rest of the project is built on top of that, with weekly decisions about what is next.
This works for two reasons. First, the smallest useful version is always smaller than the client thinks, and delivering it early proves that the rest can be built. Second, the client's priorities change the moment they have working software. Features that seemed critical in a planning doc turn out to matter less than they thought. Features nobody imagined turn out to matter more. If you have not shipped anything yet, you will build the wrong thing.
We have built systems that were originally scoped as 12-month projects in 10 weeks, because the actual need was narrower than the original brief. We have also taken projects that were scoped as 8 weeks and explicitly told the client it is a 6-month project, because the brief underestimated the complexity. In both cases, the key was getting the first version in front of real users quickly so the scope could be corrected.
If someone is selling you a fixed-price, fixed-scope, 12-month custom build, be careful. Either they are padding the estimate heavily or they are going to fail to deliver. The honest version of the contract is a short first milestone, a small committed team, and a weekly decision about what to build next.