Article

Adding AI to an Existing Platform: What Is Realistic

Some AI features are now cheap and reliable to add to a platform you already run, and others are not worth it yet. Here is how to tell them apart.

October 13, 2026
7 min read

Adding AI to an Existing Platform: What Is Realistic

Most companies we talk to are not asking for a new AI product. They already have a platform: a customer portal, a booking system, an internal admin. They want to know if AI can make it more useful, and what that would take.

Some AI features are now cheap and reliable to add. Some are possible but need careful work. Some are not worth doing yet. This guide is for owners and CTOs with a working product who want to add AI without putting that product at risk. It covers which features to start with, what drives the cost, the risks to plan for and a rollout plan.

Start with a job, not with a model

The most common mistake is starting with the technology. "We should add a chatbot" or "we need an LLM" is not a requirement. A requirement sounds like this:

  • "Support staff spend two hours a day answering the same ten questions."

  • "Managers want a weekly summary of what changed, without opening five reports."

  • "Our team enters data from PDFs by hand."

  • "Admins need to do routine tasks without clicking through ten screens."

Each of these has a clear user, a clear task and a way to measure if it worked. That is what decides whether an AI feature succeeds.

Four kinds of AI features, from easiest to hardest

1. Text generation and summaries

Drafting replies, summarizing long records, rewriting text in another tone or language. Large language models (LLMs) are good at this. The risk is low if a person reviews the output before it is sent. This is usually the best first feature.

2. Extraction and classification

Reading an invoice, a CV or a support ticket and turning it into structured fields. Tagging incoming requests by type or urgency. This works well when the inputs are fairly consistent and you check results against real examples before going live. Ask the model for a fixed output format and validate it like any other user input.

3. Assistants that act inside your system

An assistant that can look up records, create entries or run reports. This is where the value is high, and so is the need for care. Decide exactly who can use it, what it can change, and how each change is logged.

4. Specialized models

Things a general LLM does not do well out of the box, such as scoring speech, detecting defects in images or forecasting from your own data. These need specific models, often trained or tuned, and usually a separate service.

What we built for Meraki

Meraki is a web and desktop platform for a children's language school. It has two AI parts, and they show the difference between categories 3 and 4.

The first is AI pronunciation scoring. Children record voice exercises and get a score. Scoring runs as a separate Python service next to the Laravel platform, so the main application stays fast and the model can be improved on its own schedule.

The second is an MCP server that lets the school's administrators run day-to-day operations from Claude. MCP (Model Context Protocol) is an open standard that lets an AI assistant call tools you define. Instead of building a chatbot inside the platform, we exposed a defined set of platform operations as tools: listing students, enrolling them in groups, recording payments, pulling reports.

The assistant cannot run free-form database queries. It can only call those tools, and the guardrails are in the code:

  • Only super-admin accounts can connect. The server sits behind OAuth, and every other role is refused.

  • Payments use the same logic as the finance screens. The payment tools call the same payment service as the admin form, so pricing, discounts and dues follow the same rules.

  • Payments need a preview first. To record or edit a payment, the assistant must preview it and then confirm it. If the price changed in between, the payment is refused.

  • Every write tool validates its input. Each payment recorded, edited or reversed is logged as coming from the assistant, under the admin's account.

Why MCP is worth a look for business platforms

If your platform already has a clean set of operations, an MCP server is often the fastest way to make it usable from an AI assistant:

  • You reuse your existing logic. Tools should call the same services your admin panel calls, so business rules are not duplicated.

  • You choose exactly what is exposed. Start with read-only tools, then add write tools one by one.

  • You avoid building a chat interface. Staff use an assistant they already know.

  • It is an open standard. Several AI assistants support it, so you are not tied to one vendor's plugin format.

It is not the right fit for customer-facing features, where you usually want the AI inside your own interface. For internal operations, it removes a lot of clicking.

The real cost drivers

We will not quote a generic price, because AI features vary too much. These are the things that drive the cost:

Cost driverWhat it means
Data accessThe work needed to give the AI clean, permission-aware access to the right data.
EvaluationBuilding a set of real examples and checking the output against them, before and after launch.
GuardrailsLimits on what the AI can do, confirmation steps for risky actions, logging.
Usage feesModel API costs per request, which grow with traffic and with the amount of text sent each time.
MaintenanceProviders retire and replace models. Prompts and evaluations need re-running when you switch.

In most projects, the AI call itself is the small part. The work is in the plumbing around it: clean data, permissions, tests and monitoring. That is why a platform with a solid structure is much cheaper to extend with AI than one with tangled code. If yours is in the second group, our guide to modernizing a legacy Laravel application covers the groundwork.

Risks to plan for

  • Wrong answers stated with confidence. LLMs can produce plausible but false output. Keep a person in the loop for anything that goes to customers or moves money.

  • Permission leaks. If the AI can see data the user cannot, it can reveal it. Filter data by the user's permissions before it reaches the model. Instructions in the prompt are not access control.

  • Prompt injection. Text inside emails, documents or web pages can carry instructions aimed at the AI. No prompt fully prevents this. Limit which tools the AI can call, treat everything it reads as untrusted, and require a human confirmation for destructive actions.

  • Data privacy. Know what data you send to which provider, how long they keep it, and whether that fits your contracts and local rules. Send only the fields the task needs.

  • Cost surprises. Long documents and chat histories multiply usage fees. Set per-user limits and spending alerts from day one.

A sensible rollout plan

  1. Pick one job. Choose a task with a clear user and a measurable result.

  2. Collect real examples. Gather actual inputs and the outputs you would accept. These become your test set.

  3. Build a narrow version. Read-only, or with human review on every output.

  4. Test against the examples. Measure how often it is right before showing it to users, and re-run the same set whenever you change the prompt or the model.

  5. Release to a small group. Watch logs, costs and feedback.

  6. Widen carefully. Add write actions and more users once the narrow version has earned trust.

This is the same phased approach we recommend for any feature. We wrote more about it in MVP vs. full product.

What is not worth doing yet

  • Letting an AI take irreversible actions, such as refunds or deletions, with no human confirmation.

  • Replacing a working, predictable rule with an AI just to say the product uses AI.

  • A general chatbot on your website with no clear job and no access to accurate data.

Where to start

If you have a platform and a task in mind, the first step is a short scoping exercise: which data the feature needs, what it is allowed to do, how you will measure it and what it will cost to run. Our Discovery sprint is built for this. It takes one to two weeks, costs $1.5k to $4k, and ends with a specification, an architecture and a fixed estimate. The fee is credited in full if the build starts within 60 days.

Thinking about adding AI to a platform you already run? Book a consultation to talk it through, or request a quote if you already know what you need.

Enjoyed this article?

Subscribe to our newsletter for more insights and stay updated with the latest in technology