Designed my mobile app with free AI — is it production-ready or just for prototyping?

Session management and data security in code exported from those tools are usually terrible. Once you go live, customer addresses and phone numbers could easily leak through unsecured API endpoints. You really need to use the visual design as a blueprint and have the backend rebuilt with a proper framework.

note: I wrote this based on my own experience, it might not apply to everyone.

We launched a salon booking app using a similar no-code AI export. The second 40 people logged in at the same time, the server froze up and push notifications stopped working. We ended up having to shell out 38,000 SAR two months later to get it rewritten from scratch anyway. It just can't handle live operations.

why drop 45,000 SAR on a mobile app when you haven't even booked your first cleaning gig yet? have you even tested the waters by taking bookings over whatsapp before rushing to publish an app to the stores?

i built a similar UI but honestly had no clue where the data goes when you tap the buttons. so you're saying when you upload it to the store customer credit cards don't just route to our bank automatically?

Take screenshots of all those screens and write one sentence under each explaining what it's supposed to do. Then get quotes from experienced freelance devs strictly for backend and API integrations; you'll get it sorted for half what that agency quoted.

great work, pulling off twenty screens in three days is a huge achievement. but those screens are just the body of the car; there's no engine or transmission under the hood. whatever you do, don't run ads and put it on the app stores like that you'll be bombarded with one-star reviews from day one.

Make the transition decision in this order: 1) Find out if the design platform exports clean code. 2) Check for compatibility with Saudi Arabian invoicing and local cards. 3) Have at least ten real users click through the prototype and note down where they get stuck in the flow.

I agree with this. The cheapest quote is usually the least thought-out one.

If you don't write this down from the start, it leads to arguments later.

The discussion got scattered, let me summarize. If you don't write this down from the start, it leads to arguments later.

If acceptance criteria aren't written, when the work is done is open to debate. If I were you I'd go this route.

There are three things to check when doing this. Ask who prepared the quote and who will actually do the work.

Hope this helps.

we experienced almost the exact same thing last year. if acceptance criteria arent written, when the work is done is open to debate.

that's all, sorry if I went on too long.

Let me summarize the topic, since several different answers were given. If code ownership isn't in the contract, you have no bargaining power when leaving.

Weekly written progress reports are much more useful than asking for dates. That's all, sorry if I went on too long.

The discussion got scattered, let me summarize. The cheapest quote is usually the least thought-out one.

Everything goes well for the first three months; problems arise in the fourth. This is my opinion, I'm not claiming it's absolute truth.

Thanks, that was the answer I was looking for.

You're right I've been down that road too. People defend habits, not processes. Resistance comes from there.

Proven by experience.

Generally correct, but one part is missing. Any unwritten clause becomes a point of disagreement later as both sides remember it differently.

Taking notes for two weeks yields better results than a six-month estimate.

Correct.

There's a trap here let me mention it. Most time waste accumulates in tasks waiting for approval.

Payment schedules should be tied to project phases not calendar dates.