[taeric]

The big risk of letting the high touch areas be what get migrated to the modern stack, is that for many companies this is largely driven by the fashion of new hires. And letting new hires drive the technical choices isn't necessarily bad, but you do have a major risk of them not understanding why things were there.

I'd say, historically, you were also lucky in the timing. The last 4 years have been absolutely rock solid for frontend development, compared to the time before. Still way more fluid than I personally think it should be, but I'm willing to ack that things have gotten a lot more stable.

Oddly, the backend has gotten worse in these years. The amount of service related churn that has happened in the past decade has been impressive. And mostly not in a good way. I can hope that we are going to be a bit more stable now.

[ojame]

High touch in the sense of being driven by product development. We let everyone make technical choices, sometimes autonomously but sometimes as a pitch. A part of technical leadership in smaller organisations is mitigating a lot of that “new hire/shiny thing” risk.

We used react a lot externally to the main product as early as 2014, but didn’t introduce it into the main product until we were comfortable.

[taeric]

Apologies if it felt like I was questioning your choice. I meant my post as an addition.

Using things outside the critical path is definitely the right choice. Making things to throw away is also great.

I do get worried, sometimes, that it is also correct to let the new coders pick the styles and frameworks. Letting them choose is a huge boon to their productivity. And letting them advance on a bet like this can payoff really well. Just expect losses along the way.