Rapid application development, without the code you throw away

It is cutting scope, which is a different thing. Speed should come from building less and from using familiar tools, not from skipping tests and deployment automation — those are what make the second release fast rather than slower than the first.

Not if the foundations are sound. What forces rebuilds is a prototype promoted to production without anyone deciding to promote it. Where we take a deliberate shortcut, it is recorded so the decision to keep or repay it is made knowingly.

Agile is how the work is organised; rapid development is a stance on scope and tooling. You can run a textbook agile process slowly, and plenty of organisations do.

That is a success, not a failure — it means the feedback loop worked. Short cycles exist so that changing direction costs a couple of weeks rather than the project.

No. Work with fixed regulatory scope, hard integration constraints or a safety case benefits from more up-front design. Rapid development suits situations where the main risk is building the wrong thing.

You do not avoid it, you manage it. Some debt is a rational trade for speed; the failure is taking it unknowingly and discovering it two years later. Ours is written down.