Generative AI development AI you can measure, not a demo

The generative AI graveyard is full of impressive demos. A founder watches a prototype answer three questions perfectly in a meeting and greenlights it. Four months later the project is quietly shelved: the assistant invented a refund policy in front of a customer, nobody could say whether version two of the prompt was actually better than version one, and the "AI content" needed so much editing that the team went back to writing by hand.

None of those are model problems. They're engineering problems — retrieval, evaluation, and review flow — and they respond to the same discipline we bring to webapps: versioned, tested, measured, shipped.

What generative AI means in our hands

Grounded in your knowledge, with receipts. We build retrieval-augmented generation (RAG) over your actual documents — policies, product data, past work, support history — so answers come from your material and cite the source they came from. "I don't know" is a designed behaviour, not a failure state.

Measured before it's trusted. Every system ships with an evaluation harness: a golden set of real questions and expected answers, scored automatically on every prompt, model, or retrieval change. You never have to wonder whether the latest tweak made it better or worse. You get a number.

A human owns the output. Anything customer-facing or brand-facing lands in a review queue first — approve, edit, or reject, with an audit trail. The AI drafts; a person you trust signs. That single design decision is what separates systems that get adopted from systems that get switched off.

The stack and the approach

• Models: frontier APIs (Anthropic, OpenAI) selected per task; smaller open-weight models where latency or cost argue for them. We're model-agnostic by design — the eval harness is what makes swapping models safe.
• Retrieval: pgvector on Postgres. Embeddings live next to your data; there's no separate vector-database bill.
• Orchestration: TypeScript on Next.js 16. One repo, one deployable, no Python sidecar to babysit.
• Interface: streaming responses, structured outputs, WCAG 2.1 AA as the accessibility target — the same as everything else we build.
• Operations: prompt version logs, eval dashboards, spend alerts.

What this looks like in practice

Two typical engagement shapes:

A content operation with an editor in charge. A business that needs a high volume of on-brand pages — service descriptions, location pages, product copy — grounded in its own approved material. We ingest what already exists, build generation templates that match the house voice, and route every draft through a review queue. The writer's job shifts from producing to approving. This pairs naturally with an SEO architecture.

A knowledge-base assistant with an escape hatch. A company sitting on years of documentation, policies, and answered questions wants an assistant — internal or customer-facing — that answers with citations, refuses questions outside its scope, and hands off to a human the moment confidence drops. The eval set defines the launch bar before a single customer sees it.

Pricing

Generative AI work is scoped to the project. A review-gated content pipeline and a fine-tuned customer-facing assistant are different animals, and a rate card would flatter one and mislead the other. After a scoping call you get a fixed-price proposal with the eval criteria written into it — you'll know what "working" means before we start. Contact us for a quote. Ongoing eval monitoring and model upgrades can ride on a Care Plan afterwards.