Adding AI to your existing web application: where to start?

You have a web application that is up and running. A customer portal or an internal dashboard your team lives in all day. And everywhere you turn, people are talking about AI. Your CRM vendor suddenly has an AI button, and someone on your team asks whether "we should be doing something with that too". So you wonder: how do you add AI to a web application you already have, and where do you even start?

The short answer: with one thing. Not with an AI strategy, not with a chatbot that does everything. With one task in your application that costs time today and that you can measure. Below you will read how to approach that, which risks come with it, and how to tell whether it pays off.

Why you start with one feature

Why not put it everywhere at once? Because you do not yet know how it behaves in your application, with your data and your users. You only learn that by doing it.

One feature gives you a contained experiment. You see what the model does well and where it slips. You see what each call costs. And you see whether your users actually use it, or quietly work around it after a week. Start in five places at once and afterwards you cannot tell what caused what.

With us, a first working AI feature is usually ready in 2 to 4 weeks. Short enough to learn fast, small enough to stop without harm.

Which feature do you pick first?

Not every task makes a good first candidate. The best ones have a few things in common:

• Clear input and output. A text, document, or form goes in, and something comes out that you can judge as right or wrong.
• It happens often. A task you do twice a month returns little. A task your team does twenty times a day does.
• A mistake can be fixed. If the AI gets it wrong, a person spots it and corrects it. Do not start with something where an error costs money straight away or lands with a customer unchecked.
• You can already measure it. You roughly know how long it takes by hand, or how often it goes wrong.

In web applications we see a handful of feature types that often fit that bill.

Summarizing

A customer file with twenty notes, a ticket with a long email thread, the write-up of a call. The AI puts a summary at the top, and your colleague only digs into the details when needed.

Classifying and routing

Putting incoming messages, requests, or documents in the right category and in front of the right person. Is this a complaint, an invoice question, or a new lead? A model is usually good at it, as long as you define the categories clearly.

Searching your own data

Your users ask a question in plain language and get an answer based on your documents, manuals, or past cases, with a link to the source. That is called RAG, and it is a bigger step than summarizing. How it works and where it goes wrong, we cover in RAG explained.

Draft text

A first version of a reply to a customer, a quote text, or a product description. Key word: draft. A person reads it, edits it, and sends it. That saves typing without handing over control.

Pick one. Ideally the one your team complains about most.

Measure how it goes today

This step gets skipped almost every time, and it is the most important one. How long does it take each time? How often does it happen per week? How often does it go wrong or need redoing?

Ask a few people to track for a week how long they spend on it. A rough baseline is enough. Without one, all you can say later is that it "feels better", and you cannot base a decision on that.

How to add AI to a web application: the roadmap

This is what the route looks like in practice, from one feature to more.

Step 1: build the first feature behind a switch

Make sure you can switch the feature on and off per user or group, so you can roll back if it disappoints. Add logging from day one: what went in, what came out, and what the user did next. Was the output kept, edited, or thrown away?

Step 2: let a small group work with it

Pick a few people who know the work well and will tell you honestly what they think. Let them use the feature for a couple of weeks, look at the logs, and talk to them. Often the AI does the right thing, but in the wrong spot on the screen or at too much length.

Step 3: compare against your baseline

Is the task faster? Does less go wrong? How often do people have to correct the output? And what does each call cost in model usage? Put it side by side. If the result is clearly positive, roll it out to everyone. If you are unsure, adjust it or stop. Stopping is a valid outcome, and cheaper than running something for a year that helps nobody.

Step 4: build a shared foundation

Once the first feature works, the second comes faster, especially if the plumbing underneath is solid. We always put the model behind a layer of its own inside the application: one place where prompts, retries, output checks, and cost tracking live. The rest of your code talks to that layer, not straight to an AI vendor. Want to switch models later? You change one place. How we think about that, we wrote up in AI in the loop, not on autopilot.

Step 5: connect AI to more of your systems

Once a few features run well, you can let AI work more broadly: an assistant that looks up data and prepares actions a person confirms. MCP is a standard for connecting AI to your software in exactly that controlled way. More on that in MCP: how to connect AI to the software you already use.

The risks you want to know up front

AI behaves differently from code you write yourself. Think this through before you start.

Wrong output. A model can say something wrong with total confidence. That is why you start with tasks where a person checks the result, and why you build checks on the output. Is the format right, and does the source it cites actually exist?

Costs that creep up. Every call costs money. At normal SME volumes you are often looking at roughly €50 to €500 a month in model usage. A feature that calls a model on every page view pushes that up fast. Track it per feature.

Privacy. What do you send to the model, and where does it end up? Check your vendor's business terms, put a data processing agreement in place, and send no more than you need.

Depending on one vendor. Models and prices change fast. The layer from step 4 keeps you free to switch.

Nobody uses it. A feature that works technically but does not fit how your team works gets ignored. That is why step 2 exists: test with real users before you roll out.

How do you measure whether it pays off?

In the end you want a simple comparison: what does this feature cost, and what does it bring in? Here is what to track:

• Time per task, before and after. This is usually where the biggest gain is.
• Correction rate. How often do people edit the output or discard it?
• Usage. How many people still use the feature after a month?
• Cost per call against the time it saves.

A worked example, purely as an illustration: say your team summarizes a ticket 40 times a day and each one takes five minutes. If the AI saves three of those minutes, you gain two hours a day. That math only holds if you actually measured those five minutes.

A first feature is usually a manageable project. If it becomes an agent that takes several steps on its own across your systems, you are in a different league. What that costs, we lay out in what it costs to build an AI agent.

No web application yet? The first question then is what kind of application you need. We lay that choice out in native app, web app, or website. How we build web applications, with AI inside where it makes sense, you can read under web application development.

Want to figure out where to start together?

Not sure which task in your application makes the best first candidate? We are happy to work that out with you. Book a call, and we will walk through your application and your processes and look at where AI genuinely pays off. And if the answer is that you do not need it yet, we will tell you that too.

Frequently asked questions

Does my web application need to be rebuilt to add AI?

Usually not. You can generally add an AI feature to an existing application through a layer of its own that talks to the model. It only gets harder if your application is badly outdated or offers poor access to your data. You can tell that quickly up front.

How long does it take to build a first AI feature?

With us, a first working AI feature is usually ready in 2 to 4 weeks, depending on the task and how easily we can reach the data it needs. After that comes a test period with a small group of users.

Which AI model should I choose?

That depends on the task, the cost, and where your data is allowed to live. More important than the first choice is being able to switch later. That is why we put the model behind a layer of its own, so a different model is one change instead of a rebuild.

What if the AI makes mistakes?

It will, so you design for it. Start with tasks where a person sees the output before anything happens with it, check the output automatically for format and sources, and track how often people have to correct it.