[varunjuice]

IMO This is all you need to know about "technical debt"

1/ Poor code =/= technical debt. Far too often, poor code masquerades as "technical debt"

2/ Good engineers do the right thing which is always a judgment call based on circumstance & culture.

3/ Take guidance from your best engineers, and find a way for the business to adapt. Much easier to change the sales deck or pricing today, much harder to overcome bad technical decisions. No one ever said "I never knew that sales deck or pricing would last this long" but many say this about software. Be super careful & deliberate.

4/ Build things that are simple (not easy), and respond to demand. Focus on movability & robustness, not "perfect" design.

[moron4hire]

Your #1 is spot on. Every "grind-to-a-halt" scenario I've been in has been because we expected X number of users or Y amount of data and once we released it turned out to be 100 times those numbers. The system you build for 10 internal users is going to look a lot different than the system you build for 1,000 users on the internet, and that's going to be completely different than what you build for 1,000,000 users. That doesn't make the small system poorly designed, it just makes it inappropriate.

[varunjuice]

Interesting. Not my experience. Every grid to halt scenario I see or hear of is just bad software decisions made under haste without deliberation, or foresight beyond initial launch (no attention paid to supporting it, let alone scaling)

Ergo, in your scenario even with 10 users, the application basically died under its own weight under nominal use.

[_asummers]

> Build things that are simple

With, of course, the realization that simple is hard and that it is almost always orthogonal to easy.