Pretty much all the migration management tools and approaches work well on a new project. But you only have a new project once, and briefly.

In practice they often do take a significant amount of discipline at multiple different stages. And they need to account for schema changes outside of perfectly defined and reviewed migrations, because those do happen.

Or you can so "no those can't happen" but that discipline comes at a cost too. Outages and incidents happen, and sometimes the resolution of them will be an on the fly index or other schema change. Does the migration tool give you anything to manage that? Did anyone remember to run it to generate the schema diff and apply it to the other dbs?

And sure you can say "don't resolve incidents with out-of-migration schema changes" but that has costs too. You're going to add process, and time, both when you do it and before in defining and documenting these processes.

ORMs and/or their migration tools is the solution to this, but it isn't a perfect, easy solution. It tends to be fragile over time in the face of day to day changing requirements, as you generally have in a small startup-type company. It's only a solved problem from a purely technical standpoint. In practice every company I've seen has had at least some problems with this, or mountains of careful process to avoid it. Tradeoffs either way.