Personally, I'd stick to kubernetes - especially as you can even pack it into VM for on-site classic deployment - avoiding too much cloud-provider-specific bits, and optionally work on optimising away the time necessary to handle it.
I assume that for whatever reasons going very close with one PaaS from any of the cloud vendors is out (I am not a fan of them, but that's specific to me being in Poland and not Silicon Valley, and I can't pay Silicon Valley prices)
You have ~25 employees, so you need to reduce toil - you can't just throw a person full time to massage and understand each custom thing.
1) Take care to run your components <https://12factor.net/> style. Even if you run them 'classic way' started from a shell script, it will make things easier to move around if necessary.
2) Don't use raw manifests - this gets tiring over time, and is prime example of "toil". Your time will be better served writing anything (whether fancy or not) that can manipulate some basic data structures and spit kubernetes resources in json format.
Once you have that, you can template your resources easily and enforce common standards and behaviours. This helps a lot especially when you don't have many employees - I'm not advocating for "employees as cogs", but if you all your applications follow a standard scheme for labelling, where credentials and data is stored, etc. - each of those small improvements reduce a bit of toil - and critical to maintaining that is removing the toil of manually keeping those standards implemented. In one job I might have spent a week tailoring a templated deployment for an application, but the next person (who was dealing with the setup for the first time ever!) configured another, similar application in one day.
It's a huge difference when all you need to start a new app is to fill in few blanks like names, maybe some credential, and maybe declare "ok, it needs a >25G temporary storage, and 5G persistent shared storage, plus should be available under this URL" and have the templates fill in the rest.
3) Implement some standards on observability and administration. It doesn't really matter whether you set up your own EFK stack/Grafana/Prometheus/Loki/Victoria Metrics/whatever or go with Datadog (ow, my wallet) or another vendor. K8s generally makes it (comparatively) easy to hook together.
Apply templating and standardisation from (2) here. Whether you're a developer or sysadmin or both, having it "just happen automagically" leads to happier people, less burnout, and ultimately more productivity.
4) Abuse the hell of k8s flexibility to get multiple deployments going on. The more expensive the underlying gear is, the more important it is. If your whole deployment is parameterised, and with things like crossplane to integrate tasks like "allocate $VENDORs postgresql offering", you can quickly setup, test/poc/do something fun/do a dog&pony show/etc. then teardown an environment. Can you do it with more classical setup? Sure. Personally I found k8s both faster in wall clock time & development time for this... and definitely less expensive.