Ultimately, I would love for something to exist out there that had the opinions and scope of deployment like Swarm in terms of simplicity, but didn't conflate other tools out there so that ergonomics and documentation were better and less confusing. Kubernetes gives you so much, but I do feel like it's a misstep that the only reasonable way we've simplified Kubernetes for production workflows is to pay a large PaaS to manage it for us.
I will say Kubernetes being as open as it is and all the overlapping tooling would seem incredibly overwhelming for someone trying to enter that space.
Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config.
My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernetes.
The swarm middle ground isn't really worth it IMNHO.
Fwiw I found swarm lovely and just so much easier to work with than anything else solving the same problems.
For a new app, one generally should and can embrace 12-facors, and delegate state to stateful services (managed databases, key-value stores, s3 etc).
Do note that for simple services, local disk can be very hard to beat for low complexity, extremely high performance - with the caveat that horizontal scaling might be tricky.
Ed: also depending on privacy requirements - self- hosted s3 (eg minio) might be tricky for a production load. OTOH self-hosted Kubernetes is no walk in the park either!
One way round that is to use an NFS volume. However, I've hit problems with too many client NFS connections on a docker swarm and so found it better to mount the NFS volume on each host and use a bind mount instead.
Also the volume plugin spec is so simple that it is possible to maintain your own plugin (even without csi).
the inevitable "you could have used something simpler than Kubernetes!" comments that appear every time it's mentioned neglect to note that you're more likely to find a Kubernetes example for whatever you're doing readily available in the wild.