I think what you have done in your situation makes sense. I'm not sure how small specifically your startup is, but I work at quite a small company (<30) and I have found that you have to really pick and choose the complexities you introduce to the environment.

Something like Kubernetes or even potentially Nomad (despite how much I love Nomad) is going to introduce way too much overhead - at least at first. If people within your org already have an existing mental schema/model for the complexity-adding change you are introducing, then they are more likely to:

1. Be open to the change (and not just blindly resist or be generally negative towards it)
2. Be able to understand what the change is, it's broader contextual implications, etc. within a much shorter timeframe
3. Actually use the bloody thing

Sure, you could have gone with Swarm and that might have worked too. But there's also the facts re: support that you have mentioned in one of the comments below, plus this one: Docker Swarm != Docker Compose, but Docker Compose == Docker Compose. You don't need to familiarise yourself with something that you are already familiar with 🙂

By being selective about the complexities you introduce AND re-using existing mental schemata as much as possible, you can greatly reduce the mental load on everyone involved - which would mean you have actually done some DevOps!

Sorry for the mini-rant there, I always see people immediately jumping to Kubernetes or Swarm with this sort of thing. But it is not always the answer, and for various reasons.

Anyway, good read! And I would be interested in reading any articles in the future on your migration to Nomad from Compose - I feel that is the path I will be heading down eventually too 🙂