> In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <

> In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search). We have extensive experience doing this over here, and this is key. Keep things even simpler than you think they could ever be, because "simple" times gazillions produces terrific economies of scale. During interviews I'm often asked if I have experience on a product "at scale", by which interviewers often suppose it can only mean some typically tiered load balancers/front-end code/backend code/data persistence and you spin up new dynos/AWS of what is really (taken as a whole) a single cohesive application to face demand, and ultimately get dismissive when I tell them I'm not working on a 1Mreq/min product... but there's a whole other orthogonal dimension to "scale" which most products have firmly locked to 1, and believe me, everything suddenly follows a square law when your code and architecture can have an impact on each dimension, especially the one that involves humans that don't have the level of intimacy with neither your product, team, or methods.