Skip to content

AI development

AI development that reaches production.

Vuewer builds AI features into existing web applications: retrieval-augmented search, document extraction, generation inside real workflows, and multi-step agents. We work in Laravel and PHP with OpenAI and Anthropic models, ship a first production feature in three to six weeks, and set cost, latency and accuracy budgets before writing code.

What we build

Five things worth building with AI.

Every one of these is in production somewhere. None of them is a chatbot in the corner of a homepage.

Search that answers
Retrieval-augmented search over your own documents, products and support history. Answers cite the source they came from, so a user can check them and a reviewer can audit them.
Typical build: 3–4 weeks
Document and email extraction
Invoices, contracts, applications and inbound email turned into structured data your existing systems can act on. Low-confidence results are routed to a person instead of guessed at.
Typical build: 2–4 weeks
Drafting inside the workflow
Replies, descriptions, summaries and translations generated where your team already works, with their tone and constraints built in. Always a draft, never an automatic send.
Typical build: 2–3 weeks
Multi-step agents
Tasks completed end to end across several systems, with a human approval step wherever the cost of being wrong justifies one. Every action logged and reversible.
Typical build: 4–8 weeks
MCP servers for your team
Your own systems exposed to Claude, ChatGPT or Cursor through the Model Context Protocol, with scoped permissions, so your team can query production safely without writing SQL.
Typical build: 1–2 weeks

01 AI features

AI that lives inside your product.

Not a chatbot bolted onto the corner of your site. Features that use your own data and do real work.

support/assistant grounded · 4 sources
Every claim links to the document it came from.
  • Grounded in your own content

    Retrieval over your documents, products and history, so answers cite something real.

  • Inside existing workflows

    Generation and summarisation where your users already are, not in a separate tab.

  • Structured extraction

    Documents, email and forms turned into data your systems can act on.

  • Evals and guardrails

    A test set from day one, so you know when the model is wrong before your customers do.

  • Budgets set up front

    Cost per request and response time agreed before we build, not discovered after.

AI development

02 Agents & automation

Put the busywork on autopilot.

The repetitive work your team does by hand, handed to something that does not get bored.

automations last 24 hours
Approval steps sit exactly where the stakes justify them.
  • Multi-step agents

    Real tasks completed end to end, with a human approval step where the stakes justify it.

  • Connected to your tools

    The systems you already pay for, wired together properly instead of by copy and paste.

  • Scheduled and event-driven

    Work that starts because something happened, not because someone remembered.

  • Fully auditable

    Every action logged, so you can answer what happened and why.

  • MCP servers

    Your team's own AI tools given safe, scoped access to your systems.

AI development

What you get

Every AI build ships with these.

Not optional extras. An AI feature without an eval set is a feature nobody can prove works.

An eval set
A fixed set of real inputs and expected outputs, run on every change, so accuracy is a number rather than an impression.
A cost and latency budget
Agreed before we build: cost per request and a response time target, measured in production.
Model portability
The model sits behind an interface. Swapping OpenAI for Anthropic, or for a cheaper model, is a config change.
A defined failure path
What the feature does when the model is unavailable, too slow, or not confident enough. Decided up front, not discovered live.
Data boundaries in writing
Which data leaves your infrastructure, which provider processes it, under what retention terms.
Documentation and handover
Written so your own developers can extend it. No dependency on us by design.

When not to

When AI is the wrong answer.

We turn work down for these reasons, and saying so up front saves everyone a wasted month.

A rule would do the job
If the logic can be written as deterministic rules, write the rules. They are cheaper, faster, testable and they never hallucinate.
There is nothing to ground it in
Retrieval needs content worth retrieving. If the documentation does not exist yet, writing it is the actual project.
The cost per request does not work
At some volumes and margins the arithmetic simply fails. We check that with you before we start, not after.
Being wrong is unacceptable
Where a single incorrect answer has legal or financial consequences and no human reviews it, a model is the wrong tool.

FAQ

Questions worth asking.

What kind of AI features can you actually build?

Retrieval-augmented search over your own content, document and email extraction, generation and summarisation inside existing workflows, and multi-step agents that complete real tasks. In practice that means a support assistant that answers from your documentation, a pipeline that turns incoming invoices into structured data, or an agent that drafts work and hands it to a human to approve.

Which AI models do you use?

Mostly OpenAI and Anthropic models, chosen per task rather than per project. Some work runs better and cheaper on a small open model, and we will tell you when that is the case. We build so the model can be swapped without rewriting the feature, because the best option changes every few months.

What happens to our data?

Your data stays in your infrastructure and is sent to a model provider only for the specific request that needs it. We use business API tiers where the provider contractually does not train on your data, and we can run entirely on self-hosted models if your compliance requirements demand it.

How do you stop it from making things up?

By grounding answers in your own data, citing the source of every claim in the interface, and building an eval set before building the feature. The eval set is a list of real questions with correct answers that runs on every change, so accuracy becomes something you can measure rather than something you hope for.

When is AI the wrong answer?

When a deterministic rule would do the job, when there is no data to ground the model in, or when the cost per request does not work at your volume. We would rather tell you that in the first call than six weeks into a build.

How long does an AI feature take to build?

Three to six weeks from first call to a feature your users can use, for a well-scoped first feature. Week one is discovery and building the eval set, week two is the build, week three is hardening and shipping. Larger or more integrated work takes longer, and we will say so before you commit.

Get in touch

We'd love to hear from you.

Do you have a question or need help with a website or web application? Whether you are starting from scratch, refining what you already have, or stuck on something complex.

Fill in the form and we'll get back to you as soon as possible.