[alphabetatheta]

The hardest part here is the tradeoff between architectural complexity as you build systems and speed of shipping product. Earlier stage companies will ship ship ship and ignore good architecture practice. At some point, it will come back to bite you if your company lives to see another day.

[manv1]

This is why you need good people when you start: because good architecture is the difference between fast iteration and slow iteration.

A good architecture will allow you to make changes easily. A bad one doesn't. It's actually pretty simple, conceptually speaking.

If you believe that "late stage" companies make correct architecture choices you're probably incorrect. It's not about late stage or early stage, it's about knowing how to build software from scratch in a way that you don't hamstring yourself (and others) down the road.

[teacpde]

I would say it goes beyond early stage companies and extends to later stage product-driven companies, especially those that value time-to-market than anything else.

[duxup]

I would argue it's the later stage company who doesn't take the time to fix it / pay off that tech debt who fails.

I'm not against picking up some tech debt here or there if you pay it off.

[jasondigitized]

Always a tradeoff. You can build a Ferrari but may end up caught in the garage while a competitor has paying customers doing laps around the feature track collecting $200 at every turn.