Is Your AI-Built App Ready for Real Users?

Building the first version is step one

An AI tool gets you to a working product quickly, and what it builds is shaped by how you tested it: one person, one browser, a few records, a patient owner who knows which buttons to press. Every screen you tried works because you tried it that way.

Real users arrive differently. Several of them act within the same second. Some upload a file ten times larger than yours. A few are scripts written by strangers that try your sign-up form thousands of times overnight, or call your AI feature in a loop because your account pays for it. None of that shows up while you are the only user, so the app can pass every test you have run and still be unprepared.

The checks below fall into two groups. One group is about abuse: what a stranger can do to your app, your users' records and your bills. The other is about load: whether the app stays quick and upright when ordinary people use it together. You can assess most of them yourself in an afternoon, and the table in the next section says which ones have to be done before you open the doors.

Seven checks, and which ones cannot wait

Read each row against your own app. The third column gives a way to tell where you stand using your own accounts and the dashboards of services you already use. The last column is our view of timing for a typical small product with open sign-up. An app used by ten invited people can relax the load rows, and an app holding health or payment information should treat every row as before launch.

The before-launch rows share one trait: a failure there harms someone or costs you money on the first bad day, and you may not get a warning. The soon-after rows mostly make the app slow before they make it fail, which gives you time to react if you are watching.

Seven readiness checks, what goes wrong without each, how a founder can tell, and when to do it

The check: Limits on login, sign-up and AI features
What goes wrong without it: A script guesses passwords, floods you with fake accounts, or calls your AI feature until the bill arrives
How you can tell: Submit the same form many times in quick succession from a test account and see whether the app ever asks you to slow down
When to do it: Before launch

The check: Login from an established authentication service
What goes wrong without it: Homemade login tends to miss something in password storage, reset links or session expiry, and each miss is a way into accounts
How you can tell: Ask your AI tool which service handles sign-in. If the answer is code it wrote itself, that is your finding
When to do it: Before launch

The check: Database rules that keep each user to their own records
What goes wrong without it: One signed-in customer can read or change another customer's records
How you can tell: Create two test accounts, add a record in the first, and try to open it from the second
When to do it: Before launch

The check: API keys and secrets kept on the server
What goes wrong without it: Anyone can copy a key out of the code the browser downloads and use your paid services as you
How you can tell: Ask your tool to list every secret and where it is read, then look through the page source for long strings that resemble keys
When to do it: Before launch

The check: Saved answers for repeated requests
What goes wrong without it: The app works out the same result again for every visitor, pages slow down, and usage-based bills climb
How you can tell: Reload a busy page several times and notice whether it takes just as long on each visit
When to do it: Soon after launch. Earlier if a page calls a paid service on every view

The check: Slow work moved into background jobs
What goes wrong without it: A user watches a spinner while an email sends or a PDF is read, the request is cut off, and they press the button again
How you can tell: Time the slowest action in your app. Anything a person waits on for many seconds is a candidate
When to do it: Soon after launch. Before launch if the action already fails on long inputs

The check: A trial under load
What goes wrong without it: The first busy hour is the first time anyone learns where the app gives way
How you can tell: Using the app alone cannot show it. It takes a test that acts like many people at once
When to do it: Before any launch you plan to announce widely

Seven readiness checks, what goes wrong without each, how a founder can tell, and when to do it
The check	What goes wrong without it	How you can tell	When to do it
Limits on login, sign-up and AI features	A script guesses passwords, floods you with fake accounts, or calls your AI feature until the bill arrives	Submit the same form many times in quick succession from a test account and see whether the app ever asks you to slow down	Before launch
Login from an established authentication service	Homemade login tends to miss something in password storage, reset links or session expiry, and each miss is a way into accounts	Ask your AI tool which service handles sign-in. If the answer is code it wrote itself, that is your finding	Before launch
Database rules that keep each user to their own records	One signed-in customer can read or change another customer's records	Create two test accounts, add a record in the first, and try to open it from the second	Before launch
API keys and secrets kept on the server	Anyone can copy a key out of the code the browser downloads and use your paid services as you	Ask your tool to list every secret and where it is read, then look through the page source for long strings that resemble keys	Before launch
Saved answers for repeated requests	The app works out the same result again for every visitor, pages slow down, and usage-based bills climb	Reload a busy page several times and notice whether it takes just as long on each visit	Soon after launch. Earlier if a page calls a paid service on every view
Slow work moved into background jobs	A user watches a spinner while an email sends or a PDF is read, the request is cut off, and they press the button again	Time the slowest action in your app. Anything a person waits on for many seconds is a candidate	Soon after launch. Before launch if the action already fails on long inputs
A trial under load	The first busy hour is the first time anyone learns where the app gives way	Using the app alone cannot show it. It takes a test that acts like many people at once	Before any launch you plan to announce widely

Limits on how often someone can hit login, sign-up and AI features

A rate limit is a rule that says how many times one account or one network address may do a thing in a given stretch of time. Past that number the app answers with a polite refusal and asks them to wait. Ordinary users never meet the limit. A script that tries a login form thousands of times meets it almost at once.

The places that need one are the places where a request costs you something or opens something. Login and password reset need one because repeated guesses are how accounts get taken over. Sign-up needs one because fake accounts fill your database and can send confirmation emails from your domain to addresses that never asked for them. Any feature that calls an AI model needs one because you pay the model provider for each call, and a stranger with a loop can spend your money while you sleep.

AI-built apps commonly ship without these limits, since nothing in a prompt like "add a chat feature" asks for them and the feature works without them. The limit also has to be enforced on the server. A counter kept in the browser can be cleared by the person it is meant to restrain.

Two more protections belong beside the limit on anything that spends money. Set a spending cap or a usage alert in the account of each paid service, so a mistake has a ceiling. Then require sign-in before an AI feature can be used, so that each call is tied to an account you can limit or close.

Login is the part of an app where writing your own is most likely to hurt you. A sign-in system has to store passwords so that a stolen database does not reveal them, expire sessions, issue reset links that work once, and resist a long list of known tricks. Established authentication services, whether the one bundled with your hosted database or a dedicated provider, have been attacked for years and repaired each time. If your AI tool wrote its own password table and its own session handling, ask it to replace them with such a service before real people register.

Signing in settles who someone is. What they may reach is a separate question, answered by rules on the database or the server: each record carries the id of the account that owns it, and a request for it is refused unless the signed-in account matches. Apps built quickly often filter records on the screen and leave the stored data open to any signed-in user who asks for it directly. Our guide on users seeing each other's data has a test you can run with two accounts of your own.

Your app also holds keys: long strings that let it talk to the payment provider, the email sender, the AI model and the database with full rights. Everything the browser downloads can be read by the person using it, including code that looks hidden. A secret key placed in that code is published. It needs to sit in the server's settings, with the browser asking your server to do the work and the server making the call. Some keys are designed to be public and are safe in the browser. Your tool can tell you which kind each one is, and you can confirm it in the provider's documentation.

If you find that a secret key has already been in browser code or in a public code repository, moving it is half the repair. Create a new key in the provider's account, switch the app to it, and revoke the old one, because you cannot know who copied it.

Stop redoing the same work, and move slow work out of the way

Many AI-built apps do everything fresh on every request. Each visit to the dashboard runs the same heavy database question again, and each view of a product page asks an outside service for a price that last changed a week ago. With five users nobody notices. With five hundred, the database spends its day answering one question over and over and the page gets slower for everyone.

Caching means keeping the answer for a while and handing it back to the next person who asks. It suits anything that many people request and that changes rarely, such as a public catalogue or an AI-written summary of a document nobody has edited since. It carries one risk you should name when you ask for it. A cached answer that is personal to one user must never be served to another, so tell your tool which data is shared by everyone and which belongs to a single account.

Slow work is a separate matter. Sending an email, calling an AI model, reading an uploaded PDF and building an export can each take many seconds. When that work runs while the user's request waits, the page hangs, and hosting platforms commonly cut a request off after a set time. The user then presses the button again, which starts the same work twice.

A background job changes the order of events. The app records that the work was requested, answers the user straight away with something like "we are processing your file", and a separate worker does the slow part and marks it finished. The job can be tried again if the outside service was down, and the user can close the tab without losing it. Ask your tool where each slow action runs today and whether a failed one is retried or silently dropped.

Try the app under load before you announce it

A load test uses a script to act like many users at once: signing in, opening the main pages, saving records and uploading files. It runs for a few minutes while you watch response times and error counts. Its purpose is to find the first thing that gives way while the only people affected are simulated.

Run it against a copy of the app with made-up data, never against the live product with customers in it, and read the terms of your host and of any outside service before pointing heavy traffic at them. Switch paid AI calls to a stand-in or a very low cap for the test, so the trial does not produce the bill you were trying to avoid.

What gives way first in the apps we see is often the database: too many connections open at once, or one list that reads a whole table to show twenty rows. After that it tends to be an outside service refusing calls because you sent too many. Each finding is specific and can be repaired, which is the reason to learn it on a quiet afternoon.

Decide the target from your own plans. If you expect a few dozen people in the first month, test for a modest multiple of that and move on. If you are about to be featured somewhere or to email a large list, test for that day.

One app, checked the week before launch

Illustrative example

This example is illustrative. It was made up to show how the checks play out and does not describe a client.

The app: A founder has built a tool that reads an uploaded lease and writes a plain summary. It works on every lease she has tried, and she plans to announce it to a mailing list.
Limits: Signed out, she finds the summary feature can be called from the landing page with no account. She submits the same lease twenty times in a row and nothing slows her down.
Login and records: Sign-in already comes from the service bundled with her database. With two test accounts, the second can open the first account's summary by its address.
Keys: Her AI tool lists the secrets on request. The key for the AI model is read in browser code, so anyone could copy it.
Slow work: A long lease takes most of a minute, and the page shows an error before the summary arrives. Pressing the button again starts a second paid call.
What she changed before launch: Summaries now require sign-in and have a limit for each account. The model key moved to the server and the old one was revoked. A rule on the summaries table ties each row to its owner. The summary runs as a background job with a progress message.
What she left for later: Saved answers for the public example pages, and a wider load test. She ran a small one on a copy of the app, set a spending alert with the model provider, and planned the rest for after launch.

What to ask your AI tool, and when to get help

Start by asking for a report before asking for changes. A tool that is told to "make the app secure" will change many files and tell you it is done. A tool that is asked to list things gives you something you can check. Use the prompts below one at a time, read each answer, and compare it with what you see in the running app.

Then ask for one change at a time, and test after each with your two accounts. Tightening a rule often breaks a screen that depended on the loose one, and a single change makes the cause easy to find. Save a version before each change so you can go back.

Get help when the answers stop matching the app: the tool says a limit exists and your repeated test never meets it, or it reports a rule that your second account walks past. Get help too when real customers' records or payments are involved, when a key has been exposed and you are unsure what it could reach, or when the load test fails and the repair would mean restructuring how data is read. In those cases a person reading all of the code together finds what one prompt at a time misses.

Our Diagnostic is a fixed-price written plan. We read the code, the database and the service settings, mark each of the seven checks as in place or missing, and set out the repairs in order, with the fee credited to the build if you go ahead with us. The work happens in your accounts, and your repo and accounts stay yours. If you would like to gauge the size of the remaining work first, our guide on what it costs to finish an AI-built app covers what drives it.

List every place a request can be made without signing in, and what each one can read or change.
Which service handles sign-in, password storage and password reset? Point to the files.
For each table, state who can read, add, change and delete a row, and where that rule is enforced.
List every API key and secret, where its value is stored, and whether any code sent to the browser reads it.
Which requests have a rate limit, what is the limit, and where is it counted?
Which actions take longer than a couple of seconds, and do they run inside the user's request or as a background job?

Before you invite real users

Each line should be something you have seen for yourself, with the date you checked it.

Login, password reset, sign-up and every AI feature refuse a rapid run of repeated requests.
Sign-in is handled by an established authentication service.
A second test account cannot open, change or delete the first account's records.
No secret key appears in code the browser downloads, and any key that once did has been replaced.
Each paid service has a spending cap or a usage alert set in its own account.
The slowest action in the app answers the user promptly and finishes in the background.
A load test on a copy of the app has run at the traffic you expect, and you know what gave way first.
You have a saved version of the app from before these changes.

How we can help

We can check your app before real users do.

Book a free consultation and tell us what you built and when you plan to open it up. We will say which of the checks sound like work you can do in your builder and which sound like work for the Diagnostic. If we do the build work, it happens in your accounts and you get the result of each check in writing.

Book a free consultation

On the project call, we’ll discuss the problem, your existing tools and what TDAT should take off your hands. Then we can define the scope and next steps.

Or call (919) 289-1231

Questions before we start

How do I know if my AI-built app is ready for real users?

Check seven things: limits on repeated requests, login from an established service, database rules that separate users, secret keys kept on the server, saved answers for repeated requests, background jobs for slow work, and a test under load. The first four should be in place before anyone you do not know signs up.

What is rate limiting, in plain terms?

It is a cap on how many times one account or network address can do something in a set period, such as attempts to sign in or calls to an AI feature. Past the cap the app asks them to wait. It stops a script from guessing passwords or spending your money.

Can someone really run up my AI bill?

Yes, if a feature that calls an AI model can be used without signing in or has no limit for each account. You pay the provider for each call, so a script that repeats the call spends your money. Require sign-in, add a limit on the server, and set a spending cap or alert with the provider.

Is the login my AI tool wrote safe to launch with?

If the tool connected an established authentication service, usually yes once you have tested sign-in and password reset. If it wrote its own password storage and session handling, have that replaced with a service built for the job before real people register.

Do I need caching and background jobs before launch?

Often they can follow launch, because their absence makes an app slow before it makes it unsafe. Do them first if an action already times out, or if a page calls a paid service every time it is viewed.

Can I ask my AI tool to do all of this?

You can ask it to report on each check and to make the changes one at a time, and for a simple app with test data that is a reasonable way to work. Verify every claim in the running app with your own test accounts. Bring in a person when the tool's answers and your tests disagree, or when real customer data is involved.

What does TDAT look at in a readiness review?

The code, the database rules, the settings of the services the app depends on and the live app itself, all inside your own accounts. We agree the access with you first and test with accounts made for the purpose.