
Adding AI to a web application is rarely difficult because of the model API itself. The harder work sits around it: keeping the interface responsive while tokens arrive, letting users cancel, controlling spend and checking answers before they affect real workflows.
I build these features inside production applications, including in-product copilots, document search with citations and agent flows that use application data. My role is to connect the model to clear frontend and backend contracts, useful fallbacks and controls the product team can operate.
That can mean a copilot that works with a user’s own data, structured extraction that turns free text into typed fields, semantic search or workflows that call approved tools under rules you define. The right shape depends on the job the user needs to complete.
Most AI features work on the happy path in a demo, then meet long documents, slow responses, dropped connections and confident wrong answers. Without cancellation, retries, monitoring and evals, teams often limit or remove the feature after launch.
I build it like any other production feature: typed end to end, observable, cost-controlled and released behind a flag to a small group first. If the existing frontend makes that difficult, a frontend framework migration or server rendering migration can reduce the implementation debt. Streaming UI itself does not require a particular framework.
Feasibility audit
The first step is pinning down the use case and whether an LLM is the right tool for it. I map your data sources, latency budget, privacy constraints and a realistic cost per user, then hand you a short report with the recommended approach, the risks and an effort estimate, before any code is written.
Architecture & design
The shape of the feature: model and provider choice, prompt and context strategy, retrieval design if it needs your own data, streaming and error contract between frontend and backend, plus the guardrails. You see the data flow, the types and the fallback path up front.
Build & evaluate
I build the interface with Vue 3 and strict TypeScript, including streaming responses, cancellation, partial rendering and accessible result states. An eval set shows whether a prompt change made the feature better or worse.
Ship & harden
A staged rollout behind a feature flag, cost and latency instrumentation, rate limiting and abuse handling, documentation and a team walkthrough, plus a 30-day technical warranty after go-live.
What an AI feature build delivers
- A streaming, cancellable interface with clear limits and fallback states when the model cannot answer reliably
- Cost per user measured during rollout, with usage caps, rate limits and alerts tied to an agreed budget
- An eval set, so prompt changes become measurable instead of vibes
- TypeScript strict end to end, plus documentation and a 30-day warranty after go-live


How much does it cost to add AI features to an existing app?
Scope depends on the use case, data access, privacy constraints, retrieval needs, eval coverage and rollout plan. The feasibility audit maps those dependencies first, then provides an effort, cost and timeline estimate based on the work the feature actually requires.
Which model or provider should we use?
Whichever fits the latency, cost and privacy constraints the audit pins down. A provider abstraction keeps model-specific code localized and reduces the work involved if you later change provider. Differences in APIs, model behavior and hosting still need to be assessed.
Will our data be sent to a third-party model?
Only if you decide it should. The audit covers exactly which fields leave your infrastructure, which stay, what gets redacted, and whether a self-hosted or EU-region model is required. I work with EU and US teams and treat this as an architecture constraint, not a checkbox.
How do you stop the AI from making things up?
You cannot eliminate it, so the design has to survive it: retrieval with citations users can click, schema-validated structured output instead of free text where the answer feeds other code, confidence and empty states that say “not found”, and an eval set that catches regressions before your users do.
Do you build chatbots?
I build in-product assistants, something that can see the user’s data, call your API and act, with the answers cited. That is a different thing from a support chatbot widget dropped on top of an FAQ, which a hosted tool will do faster and cheaper than I can. If a widget is what you need, take the widget. If the assistant has to understand your product and do work inside it, that is this.
Do you do the backend too, or only the frontend?
Frontend-led, full stack where the feature needs it. I use Node.js server routes for the streaming endpoint, retrieval and tool calls. Pure backend-only AI work is not what I take on; my role is to make the feature work inside the product.
Can we add AI features to an older frontend?
Yes. Older tooling and dependencies may increase implementation risk and cost, so I audit the existing stack first. That evidence determines whether it is sensible to add the feature in place or migrate first.
More Services
Get in touch
Athens, Greece, working remotely with EU & US teams
info@offline-web.com