AI can write your app. Here is what makes it production-grade.

AI tools that turn a description into a working app have improved quickly. Ask for a salon booking system or an abaya store and you can get screens, a database and working buttons in one conversation. That is real progress. It is also where many tools stop: you get a prototype, and then the hard part, running it safely for real customers, is left to you.

This guide is for business owners, not developers. It explains what AI does well today, what turns a prototype into production-grade software, where the limits still are, and how to tell the difference before you trust a tool with your customers.

What frontier AI does well today

The most capable AI models, often called frontier models, write good code for patterns that have been built many times before. For a business, that covers a lot:

• Content pages: a clinic's services, doctors and opening hours in Arabic and English.
• Catalogues and stores: products with photos and prices in KWD, and a checkout.
• Bookings: customers choose a service and a time, and requests arrive in an admin.
• Member areas: students sign in to follow their courses.
• Admin screens: where the owner sees new orders, bookings and enquiries and updates them.
• Custom records: a simple client list, a scheduling board or a request tracker, described in plain words.

These are well-trodden patterns, which is why results there tend to be solid. The quality of the code is no longer the main question. The main question is what happens around it.

What turns a prototype into production-grade software

A prototype works on the day you see it. Production-grade software keeps working when real customers use it, when something goes wrong, and when you ask for the twentieth change. Five things make the difference:

1. Architecture. The app is built on a foundation that already handles sign-in, payments, the admin and the database, so the AI writes your business's pages and rules instead of reinventing security each time.
2. Checks before every release. Each new version is started, its pages are opened and its code is checked before it replaces the one your customers use. A broken change should never go live.
3. Managed hosting. Someone keeps the app running, serves it over HTTPS, and applies each update for you. You should never have to deploy anything.
4. Payments done the safe way. Customers pay on the payment gateway's own page, the money reaches your own account, and an order counts as paid only when the gateway confirms it. Payment keys are never written into the code.
5. Data kept apart, and protection against abuse. Each business has its own database and file storage, and sign-in and public forms are limited against floods of automated requests. The OWASP Top 10, a widely used list of web security risks, shows how many of the common problems come from exactly these areas.

When you compare tools, ask about each of the five. A demo shows you the screens; these answers tell you whether you can run a business on it.

Why AI makes mistakes, and how good builders guard against them

AI fills gaps with guesses. If you write "a booking system", it has to guess: bookings for what, how long, who confirms them, can people cancel? Every guess is a chance to be wrong, and long, tangled requests multiply the guesses. Like any code, generated code can also have bugs.

You cannot remove these risks, but a good builder shrinks them. Look for:

1. Clarifying questions before assumptions, ideally with a sensible default you can accept.
2. A plan you confirm: a plain-language summary of the pages, who uses them, the main actions and what gets stored, before building starts.
3. A preview: a link where you can try every change before customers see it.
4. Safe releases: a new version goes live only once its checks pass, so a broken build does not replace a working site.

Will Google rank software an AI built?

Google's published guidance is about the content, not the tool: what matters is whether pages are helpful, reliable and written for people. Using AI is not against its rules, but mass-producing low-value pages to game search is. In practice, write your real business details yourself, check every claim on the site, and add pages only when they answer a real customer question.

How to write a good request

The clearer your request, the fewer guesses. A few habits help:

• Say who the software is for and the one main job it must do.
• Name the screens and who sees each: customers or only you.
• List what needs to be stored, such as name, phone number, date and service.
• Give real details: your services, prices in KWD, hours and delivery areas.
• Say which languages you need and which comes first.
• Start small and add features in steps once the core works.

Here is an example. Say you run a women's salon in Jabriya.

Vague: "Make me a salon app."

Clear: "I run a women's salon in Jabriya. I want an Arabic and English site where customers see our services and prices in KWD, choose a service and a preferred date and time, and send a booking request with their name and phone number. I want to see all requests in my dashboard and mark each one confirmed or cancelled. Customers pay a KNET deposit for bridal packages only."

The second version answers most of the builder's questions before it asks them, and it is easy to check against the plan.

Where the limits still are

Being candid here saves you time and money. Even with frontier models and a strong foundation, some things are hard or not available in most builders today:

• Real-time features. Live chat, live order tracking on a map or live auctions need constant two-way connections and careful engineering.
• Heavy custom logic. Payroll, or stock across branches with accounting rules, is where small misunderstandings become expensive.
• Money split between many sellers. A marketplace's listings are ordinary pages, but paying out several sellers from one checkout needs special payment agreements.
• Connections to other systems. Linking to accounting software or delivery apps needs integration work.
• App Store and Google Play apps. Many builders make sites that work well in a phone's browser rather than store apps.
• Team accounts. If several staff need their own sign-in with different permissions, check that the tool supports it.

None of this makes the tools weak. It means matching the tool to the job.

When to hire a developer instead

Consider a developer or agency if your idea depends on the limits above from day one, if you handle sensitive data such as medical records with legal requirements you must get right, or if you already have a developer who should own the system.

There is also a middle path: test the idea with real customers using a builder, then bring in a developer when you outgrow it. That only works if you can take your software with you, so ask every builder what an export contains before you start. More in owning your data and code.

How darwaza makes AI-built software production-grade

darwaza builds the software a business runs on, and it is built by frontier AI models; higher plans use more capable ones. You describe your business in Arabic or English, answer a few questions, edit the plan and see the designs before anything is built. Every site is custom software on a managed foundation: sign-in, payments, the admin and the database are built in, ready when your business needs them, and beyond the ready-made parts darwaza writes the custom pages, data and admin screens you describe.

Around the code, darwaza does the hard part. Hosting is included and managed over HTTPS, and a new version goes live only after its checks pass, including a check for unsafe code. Changes reach your site through darwaza, so you never deploy anything. Each site that keeps data has its own database and file storage, kept apart from every other site, and sign-in and public forms are limited against floods of requests. Customers pay with KNET, cards or Apple Pay through your own account with UPayments, Tap, MyFatoorah or Hesabe, and the gateway's keys are added securely, never written into the code. Our guide to how your customers' data stays yours explains each layer.

And the limits, plainly: darwaza does not yet send emails or text messages to your customers, connect to accounting software or delivery apps, build App Store or Google Play apps, or give staff their own sign-in; only you sign in to the admin. Paying out several sellers from one checkout is not available yet. On paid plans: Paid plans can download the site's source code and a copy of its database as an SQL file. Photos and files uploaded to the site are not part of the download yet.

If your idea fits, you can describe it and start free. You will see the plan before anything is built.