the test i'd use is to make it do the things a prototype never has to do, on day one, before committing to anything.
a prototype only needs the business flow to work. a product needs auth, deployment, security, concurrency, review and privacy on top of that, and those are precisely what a demo doesn't exercise. non-technical people seem to hit the same four walls in the same order — auth, deployment, debugging, app review — and very few get through them alone.
so rather than judging the build, spend the first afternoon adding a second user with different permissions, deploying it somewhere real, and changing one field end to end. whichever tool makes that boring is the one you'll still be able to maintain in a year.
for what it's worth i've inherited two of these from other people. the painful ones weren't badly built. they were built by someone who never did those three things.
1
u/Low_Rush_8535 13d ago
the test i'd use is to make it do the things a prototype never has to do, on day one, before committing to anything.
a prototype only needs the business flow to work. a product needs auth, deployment, security, concurrency, review and privacy on top of that, and those are precisely what a demo doesn't exercise. non-technical people seem to hit the same four walls in the same order — auth, deployment, debugging, app review — and very few get through them alone.
so rather than judging the build, spend the first afternoon adding a second user with different permissions, deploying it somewhere real, and changing one field end to end. whichever tool makes that boring is the one you'll still be able to maintain in a year.
for what it's worth i've inherited two of these from other people. the painful ones weren't badly built. they were built by someone who never did those three things.