Gen AI development
Two halves of one job. We build LLM products and internal copilots, and we take over the ones already built with AI. The second half keeps growing because a working demo is now cheap to produce, while running one in front of real customers costs what it always did.
AI-built codebases made production-grade
These reach us in one of two states: the demo works and real customers break it, or it runs and nobody left on staff understands it. We read the code, then tell you whether to harden it or replace it. Either way you get tests, a security review, the architecture it should have had, and documentation good enough to run it without us.
LLM products and internal copilots
Retrieval, tool use, agent loops and fine-tuning, built as software rather than as a prompt in a text box. The model is rarely the hard part. The hard parts are what happens when retrieval returns the wrong document, how someone catches a wrong answer before a user acts on it, and what the whole thing costs at ten times today's traffic.
Build-versus-buy strategy
What to build, what to buy, and what to leave alone. Most AI roadmaps we read carry at least one feature a vendor already sells for less than it would cost to match, and at least one that no model handles reliably yet. Both are cheaper to find before the quarter starts.
Evaluation, monitoring and cost control
An eval set built from your own traffic, monitoring that catches quality drift as well as errors, and cost controls that warn you before the invoice does. Without them there is no way to tell a good release from a bad one.
What we hand over.
- AI-generated codebases taken to production: tests, security review, documentation
- LLM-powered products, internal copilots, and model fine-tuning
- AI strategy: what to build, what to buy, and what not to build at all
- Evaluation, monitoring, and cost controls once it's in production
Questions this work usually raises.
We already built something with AI. Can you take it over?
Yes, and it is a growing part of what we do. The usual shape: it demos well and falls over with real customers, or it works and nobody left on staff understands it. We read it, tell you plainly whether to harden it or replace it, then do that. Tests, security review, the architecture it should have had, and documentation good enough that you are not dependent on us afterwards.
What tech stacks do you work in?
We choose the stack based on your team's ability to maintain it after we leave, not our own preference. In practice: TypeScript/Node, Python, and Go on the backend; React and native mobile on the front end; AWS, GCP, or Azure for infrastructure.
Who owns the code and IP?
You do, outright, on delivery. No licensing fees, no dependency on us to keep running your own software.
What if we're not technical?
We write proposals and updates for whoever is paying the invoice. If a decision needs a technical tradeoff explained, we explain it in plain terms before asking you to choose.
Most engagements cross more than one.
Bring us the whole problem.
Book a one-hour scoping call. No deck, no pitch: you describe the problem, we ask the questions that usually get skipped, and you get a straight answer on whether we're the right people for it. Scoping comes after, in writing.