Ask an engineer to size a new unmanned aircraft and the first thing they reach for is a spreadsheet. Ask them a fortnight later whether the design closed, and the answer is often a qualified yes that turns out, months on, to have been a no.
The reason is structural rather than careless. Conceptual sizing is a circular problem, and circular problems do not yield to a single pass down a column of cells.
The circle
Wing area is chosen to carry the aircraft's weight at an acceptable wing loading. Weight depends on structure, which scales with wing area. It also depends on the energy carried, which depends on the power required, which depends on drag, which depends on wing area again. Propulsion is sized to the power required, and propulsion has mass. That mass raises the weight the wing must carry.
Every one of those relationships is defensible on its own. Together they form a loop with no natural starting point. In transport aircraft the loop is classically closed on fuel fraction, because fuel is burned in flight and the aircraft gets lighter. In battery-electric aircraft it closes on mass instead, and the loop is tighter: the energy you carry does not get lighter as you use it.
Where the stall happens
What we see repeatedly is not that teams fail to notice the circularity. It is that they iterate two or three times by hand, watch the numbers move less on each pass, and conclude that it has converged.
Slowing is not converging. A loop can approach a value slowly and still be heading somewhere unacceptable, and the difference between the third iterate and the converged answer is frequently larger than the margin the programme is carrying. The design that looked feasible at 24 kg settles at 31 kg, and by the time anyone notices, the airframe is tooled.
Sensitivity matters more than the answer
A converged sizing point is a single number and tells you very little. What tells you something is how hard that point is holding.
If a five per cent error in your structural mass fraction moves endurance by two per cent, the design is robust and the assumption does not need defending. If the same error moves endurance by forty per cent, that assumption is now the programme's central technical risk and deserves to be treated as one.
Most spreadsheets cannot answer that question, because answering it means re-running the whole loop against a perturbed input, dozens of times. That is a trivial computation and an intolerable amount of manual work, which is precisely the sort of thing worth automating.
Why revision history matters here
The other failure is quieter. A sizing model is built in week one, and by month four it has been edited by four people, none of whom recorded why. Somebody increased the payload allowance. Somebody relaxed the wing loading. The model still converges, and it now describes a different aircraft to the one anybody agreed to.
Treating sizing runs as versioned artefacts, so they are diffable, attributable and reproducible, sounds like software hygiene applied where it is not needed. In practice it is the only way to answer the question every programme eventually asks, which is: when did this number change, and who changed it?
What good looks like
A conceptual design process that works has three properties. It converges to a tolerance you have chosen rather than to the point where you got bored. It reports sensitivity, so the team knows which assumptions are load-bearing. And it keeps its history, so a number can be traced to the decision that produced it.
None of that requires expensive tooling. It does require treating the loop as a loop rather than as a column of cells.