Adding AI Features to a Web App Without Making It Fragile

Whoopit — Thu, 08 Oct 2026 10:51:03 +0000

AI features are easy to demo and hard to run in production. Models time out, return malformed output, cost money on every call and sometimes answer with total confidence and no accuracy. Here is how to build them so the rest of your app stays dependable.

1. Keep model calls on the server

Never call a model from the browser. Keep keys, prompts and provider logic behind your own API so you can add auth, rate limits, logging and provider changes without touching the client.

2. Constrain the output

Ask for structured output and validate it before using it. A response that doesn't match the schema should be treated as a failure, not passed to the UI.

import { z } from "zod";

const Reply = z.object({
  answer: z.string(),
  confidence: z.enum(["low", "medium", "high"]),
});

export async function ask(question: string) {
  try {
    const raw = await callModel(question);
    const parsed = Reply.safeParse(JSON.parse(raw));
    if (parsed.success && parsed.data.confidence !== "low") {
      return { ...parsed.data, escalate: false };
    }
  } catch {}
  return {
    answer: "I'm not sure about that. Let me pass you to a person.",
    confidence: "low",
    escalate: true,
  };
}

callModel stands for a thin wrapper around your provider's SDK.

3. Ground answers in your own data

For anything factual, retrieve the relevant content from your own documents or database and pass it to the model, with instructions to answer only from it. If nothing relevant is found, say so instead of guessing.

4. Plan for failure

Set timeouts on every call
Retry once with backoff, then fall back
Provide a non-AI path: a form, a search box or a human handover
Never block the main user flow on a model response if it can load afterwards

5. Control cost and load

Cache repeated questions and expensive results
Rate limit per user
Cap input and output length
Use a smaller model for simple tasks

6. Log everything you can

Store the input, retrieved context, output and validation result for each call. Without that you can't debug a bad answer or measure improvement.

7. Test with real examples

Keep a set of real questions with expected outcomes and run it whenever you change a prompt, model or retrieval step. A prompt tweak that fixes one case often breaks another.

8. Treat personal data carefully

Decide what is sent to the provider, what is stored and for how long, and how a user's data is deleted. In the UK, UK GDPR applies as soon as personal data is involved.

Summary

Treat the model as an unreliable but useful dependency: validate what comes out, have a fallback, watch the cost and keep a record of what it did.

If you would rather have this built than build it yourself, ZevIQ AI is a UK-based team that develops custom AI-powered web and app projects.

Building an AI Chatbot That Doesn't Make Things Up

Whoopit — Thu, 08 Oct 2026 06:56:05 +0000

Most AI chatbot projects don't fail because of the model. They fail because of everything around it: what it knows, what it's allowed to do, and what happens when it's wrong.

Here is the architecture and the decisions that matter, whether you build it yourself or hire a team.

1. Define the scope before the stack

Write down what the bot owns and what it must hand off. A narrow scope (tier-1 support, lead qualification, appointment booking) beats a general assistant every time. Escalation rules are part of the spec, not an afterthought.

2. Ground answers in your own data

A raw LLM will answer confidently from general training data. For business use, answers should come from your content: FAQs, policy documents, product or course material.

The usual pattern is retrieval-augmented generation (RAG):

Split your documents into chunks and index them
Retrieve the most relevant chunks for each user question
Pass them to the model with instructions to answer only from that context
Return "I don't know, here's a person who can help" when nothing relevant is found

Step 4 is the one most projects skip, and it is what separates a trustworthy bot from a liability.

3. Add guardrails

Decide in advance what the bot must refuse: off-topic requests, legal or medical advice, anything outside its knowledge base. Combine a clear system prompt with output checks, and test with adversarial questions before launch, not after.

4. Integrate, don't just converse

A chatbot becomes useful when it can act:

Create or update a lead in your CRM
Book a slot in a calendar
Look up an order or record via API
Open a ticket and attach the conversation

Workflow tools such as n8n are a common way to wire this up without writing every integration by hand. Multi-channel deployment (website, WhatsApp, an LMS, internal tools) is mostly a matter of putting one backend behind several front ends.

5. Build the human handover properly

When the bot escalates, pass the full conversation history to the agent. Making a customer repeat themselves defeats the purpose of automating in the first place.

6. Log everything and review it

Store conversations, and track:

Resolution rate
Escalation rate
Questions the bot couldn't answer
User ratings

Every unanswered question is a gap in your knowledge base. A monthly review loop is what keeps the bot improving after launch.

7. Treat data protection as a requirement

If you operate in the UK, UK GDPR applies as soon as the bot handles personal data. Know what you collect, where it is stored, how long it is kept, and how a user can request deletion. This matters most in education, care and other sectors with sensitive data.

A sensible build order

Knowledge audit
Use case and escalation definition
Build and train
Integrations
Testing with real conversations
Launch with analytics

If you'd rather have this built than build it yourself, ZevIQ AI is a UK-based team that develops custom chatbots connected to CRMs, ERPs, LMS platforms and knowledge bases.

DEV Community: Whoopit