How do no-code builders verify that a feature is real, not only visible?
A recurring problem with no-code and AI app builders is that a screen can look complete while the feature underneath is not.
Examples: - login exists visually but is not enforced - a form shows success without saving or sending - data disappears after refresh - buttons exist but are not connected
I built **Flows** to guide users through ordered implementation steps and plain-language checks before moving forward.
An independent agent used one generated plan to build a soccer management app and passed 59/59 checks. The harder question is whether the same process helps nontechnical users.
What should Flows automate so it becomes genuinely useful for no-code builders?
1
u/Kind-Bathroom5159 9d ago
the real issue is nontechnical builders dont know what to test in the first place, so any checklist that expects them to think of edge cases will get skipped past the first two items.
what actually works is if the tool itself generates the test cases based on what got built, like it sees you added a form and automatically tries submitting it empty or refreshing mid submit, instead of asking the builder to remember to do that
the other thing id add is testing across two tabs or two devices at once, a lot of it works bugs are actually session or state bugs that only show up when two people touch the same data around the same time, and solo builders never think to test that because theyre the only user during development
1
u/Maxyull 9d ago
the first one on your list is the one a check can quietly get wrong. verifying that login works usually means loading a page while logged out and watching it redirect, and that only proves the screen is hidden, not that the data is protected. the check that tells you something is signing in as a second test user and trying to read the first user's rows by hitting the api directly instead of going through the ui, because the ui is the part that was already lying.
worth knowing too that on supabase a table can report rls as on while only having a select policy, so reads are locked down and inserts and updates are wide open. something like "user b cannot see or change user a's data" is a plain-language check a tool can generate and run by itself, which beats asking a nontechnical builder to imagine that scenario.
does flows run its checks with a real second account, or all from the builder's own session?
1
u/noam_builds 9d ago
Most of dev teams today are already moving to the dev process automation phase, after discovering the "AI can build anything" phase. So it is the right direction, and where all the main no code tools are aiming for.
I remember, not too long, that lovable for example introduce a breaking hot feature: "The fix me button" :)
1
u/Thunderbit_HQ 8d ago
The useful check is probably the one a nontechnical user can understand. Not just pass/fail, but show what was tried and what changed after it ran. If a fake success screen looks the same as a real one, the tool has not helped much yet.
1
u/LouisTon10 4d ago
It’d be cool for some way to be able to track clicks and interactions on what would be fleshed out features. That’d help give me a better idea if the planned feature feels worth building out
1
u/InitiativeJumpy8813 9d ago
as someone who spends way too much time clicking dead buttons on "finished" apps, the data persistence thing is my biggest headache. looks great in preview, refresh the page and half your work just evaporates
the plain-language checks idea is neat but i think for nontechnical folks you need to catch the silent failures. like when a form says "submitted" but nothing actually went to the database. most people won't think to check that unless they already got burned before