My second point is that even no-code tools tend to require developer support sooner or later. What I've noticed for admin tooling is that it often works best when it is driven by the product team. For example, customer support requests comes in which requires devs to stop working, investigate the issue, manually fix up data where necessary, etc. Devs hate doing this. Give the dev the ability to add the functionality to the admin and they often will, just to make the support requests go away. If you take away the admin from the product team then there is more friction in this path.
I will admit however, that the quality of life improvements demanded by the support teams often go un-attended. But I don't see how Refine will help this go away if it requires someone familiar with next.js/React, Ant/MaterialUI, etc. to make changes.
Refine does appear to require developer build-out and is more of quickstart framework.
If you have semi-technical users (can muddle through generating SQL using stackoverflow) then unleashing them on a read-only DB copy with an app builder can be better for everyone involved.
Something like: “Hey I saw your ticket requesting a ‘user address’ field in the dashboard, do you want the mailing address or billing address? Lmk then I can probably add this today and it’ll go live in the next deploy” -> user instead adds the field on their own in < 5min
Lots of additional use cases for other db interactions too where “let’s just spin up an internal admin panel in the app” can turn into days or weeks of getting input and now the design needs to be thought about and more stakeholders consulted vs. absolute basic functionality being stood up in Retool in a couple of hours. It’s sort of similar to presenting a wireframe instead of high-fidelity mock-ups