I don't think "future proof" has to be tongue-in-cheek. There's about a billion buzzwords that are misappropriated which'll make everything slower, but behind

I don't think "future proof" has to be tongue-in-cheek. There's about a billion buzzwords that are misappropriated which'll make everything slower, but behind the buzzword there's typically some insight that'll help with some problems when they're not just a catch-all buzzwords. Personally, I don't actually think the following is a terrible tactic for most of our CRUD apps. - Start with a fullstack monolith framework because it's probably going to be the fastest and simplest way to market. - Break up the monolith. Microservices everything! - Use some buzzword system that'll help facilitate this ( your testing an operations just got harder, it's a trade off, k8s now might make sense ). Stepping away from just following the fad, at some point, if you're successful, your company is going to be complicated enough where you have, for example, 5 ways of sending emails. None of them quite complete enough to handle blacklisting, delivery failure, debugging, or audit logging. Que the email gateway service. You now, if done right, hopefully have encapsulated the email problem into a single codebase, run from a single location, owned by a single team, that understands the issues and actually completes the implementation. If you go into this eyes-wide open, it doesn't need to be a massive problem when it happens. Of course, this doesn't always go well. The most common failure I see in big orgs is it gets political, gets stolen by architecture, they bootstrap an internal services team who refuses to release anything until it's done, dissapear into the void, whilst banning any other development org from working on the problem. This has less to do with the path being wrong, and more to do with the culture being wrong. Give the problem to someone who needs to release something, i.e. the onboarding team sends most emails, they can build the common email gateway, and they'll accept PRs as it's not the only problem. Of course YMMV. It depends. :)