Your app works. Is it ready for real customers?
AI coding tools get an app working in days. The work they skip is the part customers never see: where the app runs, who can reach it, whether a backup restores, who patches the server and what a busy month costs. Answer five questions before the first paying customer signs in, and you know what to fix yourself and what to hand to an engineer.
Where does it run today?
Most apps built with AI tools start on a laptop, a free hosting tier or the preview link the tool gave you. Each of those is fine for a demo. A laptop goes offline when it sleeps, and a free tier usually limits how long the app stays awake and how much data it can hold.
Write down three things: the service the app runs on, the database it writes to, and who holds the login for each. If the answer to the third is one personal account, fix that first. A business that depends on the app needs more than one person who can get in.
Who can get in, and where are the keys?
The OWASP Top 10 for 2025 ranks broken access control first among web application risks, with security misconfiguration second. In plain terms, the most common serious problem is a user reaching data that belongs to someone else. Sign in as one test customer and try to open another test customer's records by changing the address in the browser. If it works, stop and fix it before launch.
Then look for passwords and API keys inside the code. The Twelve-Factor App method says to store config in the environment, and gives a simple test: could the code be made public at any moment without exposing a credential? An AI tool will happily paste a key into a source file, so search the code for every key your services issued.
What happens when it breaks?
A backup you have never restored is a guess. Restore last night's copy of the database to a separate place, open the app against it, and check that yesterday's records are there. Put the date of that test on a calendar and repeat it.
- Operating system and library updates: decide who installs them and how often.
- Monitoring: decide who gets the alert at 2 a.m. and what they are expected to do.
- A second environment: changes get tried on a copy before customers see them. Development, QA and staging explains what each copy is for.
What will it cost with real traffic?
Usage pricing is cheap at ten users and hard to predict at ten thousand. Find the three numbers your provider bills on, usually compute time, stored data and data sent out to the internet, and multiply each by the traffic you expect in a good month. How to read a cloud bill walks through the lines that grow fastest.
If the estimate swings widely, a predictable monthly rate may suit the app better. That is one reason steady applications move to application hosting.
When to bring in an engineer
You can answer the first two questions yourself in an afternoon. Bring in an engineer when a customer sends a security questionnaire, when the app holds health or payment data, or when nobody on your side wants to own patching and restore tests.
Bring your answers to a call with a consultant. Thirty minutes is enough to sort the list into what you keep and what Petrichor's engineers would run.