TL;DR YAGNI + do an actual "build vs buy (including FOSS)" in good spirit on absolutely everything.

The biggest mistake I see other engineers making is opting to build vs buy when it's commodity stuff that we could easily and cheaply buy (or even use FOSS for), e.g. log shipping software, monitoring agents, etc. I see folks building "frameworks" for agents they'd like to run, and dreaming up entire ecosystems, of course with complex message busses and cert strategies...

Please don't re-invent Fluentd / Logstash / Prometheus etc unless you have a very compelling reason to do so. Also, your UI will suck, and if you make support staff use it, they'll hate you and you'll lose trust. There are so many great free dashboard tools out there, just pick one and learn it / use it. For stuff like reporting, there are a dozen ways to do that with stuff like Jupyter notebooks running on schedulers (and please please please don't try to write your own enterprise scheduler, again there are many out there that have been hardened over years of battle).

Don't run your own mail server. Just do not. If you've never dealt with IP + domain + ASN reputation and deliverability issues before, please just trust folks when they tell you that you don't want problems like that. Just use SES / Mailgun / SendGrid / whatever.

Don't re-invent JIRA. JIRA can do what you want if you take the time to learn it, and maybe add a few plugins or integrations.

Don't re-invent Jenkins. Jenkins can do almost anything. That doesn't mean it's the right tool for the job, but in many cases it's probably good enough to get you by, and easily adds visibility + access control + logging + who + what + when + kinda why + where and SCM integration to any ad-hoc task-execution or [see above] task scheduling needs. Jenkins is probably one of the most heavily battle-tested pieces of software in the FOSS enterprise software world, along with Apache and MySQL. I run Jenkins at home.

Don't use Java when you could do it with Bash, or even systemd / built-in OS functionality. Learn how linux works and what facilities are available on your given OS. You will likely find that many common problems have already been well-solved in depth.

If you can just pay AWS to run the service, it's probably worth it. Their stuff is also quite well battle-tested (at least non-early-access products), and stuff like RDS, CloudWatch, SQS, etc work pretty darn well these days. If you're already in AWS, don't just run everything yourself and treat it like a virtual datacenter -- to do so is to miss the whole point of "the cloud". You'll save OpEx in the end until you're operating at huge huge scale, and even then, when your finance team negotiates with your AWS TAM, they'll work out a decent-enough deal.

Edit: and please please please do not try to write your own etcd / zookeeper / Consul / Vault / Cassandra / Kafka. There's a good reason almost everyone uses this stuff: they works well, the ways they fail are well-understood, and they get updated regularly. You won't do a better job. Even if you work at a 10k person company and can dedicate a team to building it, you won't do better. Your implementation will be buggy and suck for years. Just buy it (for free). When I interview folks with stuff like this on their resume that they've built, I usually see that as poor judgement (unless they actually worked on one that ended up actually getting used outside of where it was invented).

Don't even try to touch building your own SSO. Buy Okta, Ping Identity, or Google SSO (Google Apps).

I'm not saying don't invent anything ever, just that I see so much damn waste when it comes to over-eager engineers wanting to build stuff that already exists as their own career builder vs solving the actual business problems in the most efficient way possible, which I've found to more likely than not be just figuring out the process / workflows and gluing a few pieces of existing software together. Not every problem needs to be solved with 18 dozen microservices and GRPC.