Internal software rarely fails because the infrastructure gave out first. It usually fails earlier, when a messy workflow gets wrapped in a thin UI and mistaken for a stable product model.
By the time teams worry about scale, they are usually dealing with something more basic: the system is already hard to understand, hard to extend, and hard for operators to trust.
The useful question is not whether an internal tool can scale. It is whether the workflow underneath has been made coherent enough to deserve scaling.
What usually goes wrong
In practice, the same failure pattern appears repeatedly. Teams digitize an existing process quickly, preserve too many local exceptions, and postpone the harder work of clarifying ownership, state transitions, and decision boundaries. The tool becomes usable, then necessary, then increasingly fragile.
At that point, every new requirement is more expensive than it should be. Reporting becomes harder to trust. Operators develop workaround behavior. Product teams start debating symptoms at the interface layer when the deeper issue is that the workflow model itself was never made sufficiently clear.