So I've been working with a Ruby DSL my colleague wrote for our rails app that builds app flows represented by data using migrations, which are consumed and rendered by the frontend. So data-driven UI.

It's very solid in prod, so we're running with it, but it can be hard to work with because everything is built using migrations - for example, the one signup flow we have spans across 7 migrations that add/change/remove components in the flow, change decision logic, etc.

I'm building a particularly complex one and can't decide which development method is better. I can either

1. write the flow in one huge migration, then change as needed - keep rolling back, resetting and testing until it works, or

2. increment changes and additions in multiple migrations across multiple pull requests, such that the final product spans across about 10-12 smaller migrations

Which one?

Both are super icky to me but I'm leaning toward 1. At least all of the shit would be in one place and would make sense without needing to switch between 10-12 files to see where shit is being defined, changed, etc. because it reads chronologically.