The first version of an AI web application: one job, done properly

Most AI web applications that disappoint were not badly built. They were built too big. The first version tried to do everything the business could imagine, took months, and reached real users long after the budget and the patience had run out. The fix is not a smaller ambition. It is a smaller first version, chosen on purpose.

The short answer

A first version of an AI web application should do one job for one group of users, end to end, with a person able to check and correct what the AI produces. It should log every AI answer so you can measure it, cap what it can spend, and be usable by real people within weeks, not months. Everything else waits until that one job is proven.

Why the first version grows

The pattern is familiar. A company sees what AI can do and writes a wish list: a portal for customers, a dashboard for managers, automatic reports, a chatbot, Arabic and English, a mobile app. Each item is reasonable on its own. Together they become a platform, and a platform cannot be tested until all of it works.

AI adds a second problem. With ordinary software you know in advance what a feature will do. With AI you only find out how well it does its job once real inputs go through it. A first version that bundles ten AI features gives you ten unknowns at once, and when results are poor you cannot tell which one is at fault.

Pick the one job

The right first job has three properties. It happens often, so there is enough use to learn from. It costs someone real time today, so the benefit is visible. And a person can tell quickly whether the AI got it right, so mistakes are caught before they matter.

Take an illustrative case: a property management company in Salmiya that receives maintenance requests from tenants by phone, WhatsApp and email. Staff retype each request into a spreadsheet, guess the category and urgency, and assign a technician. A sensible first version is a simple web form and inbox where tenants describe the problem in Arabic or English, the AI proposes the category, urgency and the details a technician needs, and a coordinator approves or corrects it in one click before it is assigned.

It is one job. The coordinator sees every AI suggestion, so errors are cheap. And within a month the company knows how often the AI was right, which categories it confuses and how much time it saved. That is worth more than a half-finished platform.

What the first version must include

Small does not mean careless. A few things belong in the first version because adding them later is expensive or risky.

Include from day one	Why it cannot wait
A person reviewing AI output	Mistakes are caught before a customer or a decision depends on them
A log of every AI input and answer	Without it you cannot measure accuracy or find the cause of a complaint
Spending limits on AI usage	A loop or a misuse can run up a provider bill overnight
Login and permissions	Retrofitting who-can-see-what into a live system is slow and error-prone
Arabic and English where users need them	Right-to-left layout added at the end usually breaks the design
Your data exportable in a normal format	You should never be locked into the first vendor or model

What should wait

Almost everything else. Management dashboards can wait, because the log already holds the data and a simple export answers the first questions. A native mobile app can wait, because a well-built web app works on a phone. Automatic actions, where the AI acts without a person approving, should wait until the review data shows the AI is reliable for that task. Integrations with every system in the company can wait; connect the one system the job actually needs. We covered how to approach that in connecting AI to the systems you already run.

Waiting is not the same as dropping. Keep the list. The first version’s log will tell you which items on it matter, and usually it is fewer than you expected.

Security is part of the first version

An AI web application has the ordinary risks of any web application plus some of its own. The OWASP Top 10 for LLM Applications lists them: prompt injection, where text in the input tries to change the AI’s instructions; sensitive information disclosure; the AI being given more power than it needs; and unbounded consumption, where usage and cost grow without limit.

A first version does not need to solve every item on that list, but it should not create them. Give the AI access only to the data the one job needs. Do not let it take actions a person has not approved. Treat anything a user types as untrusted, including what they paste into a form that the AI later reads. Our note on prompt injection explains how that attack works in practice.

Data location matters too. Decide early which AI provider processes your data, under what terms, and what you tell your users about it. We set out the questions in where your company data actually goes.

How to know it works

Before you build, agree how success will be measured. For the maintenance example: the share of requests where the coordinator accepted the AI’s category unchanged, the average time from request to assignment, and the number of requests sent back to tenants for missing details. Measure the current process for two weeks first, so you have something to compare against.

Then test with real examples before launch. Collect a hundred past requests, run them through the system and check the answers by hand. It is slow and it is the only honest test. We described the method in the 100-example test.

The People + AI Guidebook from Google’s research team makes a related point about design: users need to know what the AI can and cannot do, and how to correct it. A first version that shows its suggestion, explains where it came from and makes correcting it easy earns trust faster than one that hides the AI behind confident output.

Budgeting beyond the build

The build is a one-off cost. Running the application is not. AI usage is paid per request, hosting and monitoring continue, and the answers need tuning as real use shows where the AI struggles. Plan the first year, not only the launch. Our guide to what AI costs after launch breaks those costs down.

One advantage of a small first version is that its running cost is small and measurable too. You learn the real cost per request from real use before committing to a larger system.

Mistakes to avoid

The first is choosing the job the AI finds hardest because it is the most impressive. Start where the AI is likely to succeed and a person can check it quickly. The second is launching to everyone at once. Start with the staff or customers who will give honest feedback. The third is measuring nothing. Without a baseline and a log, the first version produces opinions instead of evidence, and the next decision is a guess.

How Tothiq builds them

Tothiq builds AI-powered web applications in exactly this order: one job, a person in the loop, logging and spending limits from the first day, Arabic and English where your users need them. The first working version is KD 1,950, and the monthly running fee is agreed with you once the scope and expected usage are clear. If the job is narrower, such as answering questions from your own documents, a custom AI assistant may be the better fit. Tell us the job and we will say which.

Frequently asked questions

How long should a first version take?

Weeks rather than months. If the scope needs more than two or three months before anyone can use it, it is probably more than one job.

Can the first version be used by customers, or only staff?

Either, but staff-facing versions are easier to start with, because a mistake stays inside the company and staff give faster feedback.

Do we need a mobile app?

Rarely at first. A web application built to work well on phones covers most needs until usage proves an app is worth it.

What if the AI provider changes its prices or models?

Build so the model can be swapped and keep your data exportable. Then a provider change is a configuration task, not a rebuild.

Who owns the application and its data?

You should. Make sure the contract says so, and that the code, the data and the accounts are in your company’s name.