[ufmace]

I don't know much about Supabase honestly.

On concerns about testing etc. I can see letting automated testing, keeping a clean version control history, good architecture, etc slide at an early stage in the name of building fast. To me, that looks like building stuff in a more mainstream language and framework, but letting yourself be a little bit sloppy about those things. The difference is, the tools you are using don't actively preclude those things, so you keep the option open of adding them in later as needed, as gradually as makes sense. If you're building in one of these limited but all encompassing frameworks like PostgREST, sure you can probably go fast at first, as long as you're coloring within their lines, but as soon as you need something more or need to add some of that other stuff in, you hit a wall, and your only option is to do basically a complete rewrite.

[everforward]

Is there a reason you can't do both? I.e. use PostgREST until you can't anymore (and hopefully get an MVP out of that), then create a backend that runs in parallel and implements whatever PostgREST can't?

It's tech debt that will likely need to be cleaned up at some point, but endpoints could be migrated one at a time, as needed. It seems fairly clean as far as dealing with tech debt goes.