What we build with generative AI
Generative AI development here means building the system around the model, not wiring an API key to a button. A model on its own has no memory of your data, no way to check its own answer and nothing between a bad output and the person who receives it. We build those parts, plus the screen, API or workflow that a person or another system actually uses.
Most engagements combine some of the following.
- LLM features inside an existing product: a drafting assistant, a search-and-summarize layer, or a classification step in a workflow that used to be manual
- Retrieval over your own documents and records, with permission-aware access and answers that cite their source so they can be checked
- Agents and copilots that call your tools, with a step limit, approval steps and an audit log of every call
- Structured extraction and grading, where the model returns a typed result that lands in your records or dashboard instead of a paragraph someone has to read
- Data pipelines that turn messy source data into something a model can reason over accurately
- The evaluation and monitoring layer that shows whether the system is improving, regressing or drifting after launch
How we measure whether the output is right
A model's answer can be wrong in ways that pass every ordinary test, so quality has to be measured, not felt. Every build ships with an evaluation suite: a fixed set of representative inputs with known-good outcomes, scored automatically before every deploy. A change to a prompt, a model or the retrieval layer either measurably improves the score or it does not ship.
Guardrails are rules enforced in code, not a line in a prompt asking the model to be careful. Where a wrong answer would be expensive, the model drafts and a named person approves. In the clinical build described below, both the voice-to-chart and the radiograph pipelines write into a pending-review state, and nothing becomes part of the record until a provider has read, edited and signed it.
AI-assisted code goes through the same gate as anything else the pod writes: a pull request in your repository, reviewed by the engineer who owns it, typed contracts and tests in CI. A model writing the first draft does not exempt it from review.
Which models we use and where they run
We are not tied to one vendor. The model is chosen per task on cost, latency and how well it holds an instruction, from Claude, OpenAI GPT, Gemini, DeepSeek, Grok, Llama, Mistral and Qwen. It sits behind a single interface in your codebase, so a deprecation or a better model is a config change and a re-test, not a rebuild.
Where it runs is set by your compliance requirements, not our preference. We deploy into your own cloud account or VPC, and open-weight models can run inside your own network so regulated data never leaves your perimeter. We have shipped a fully air-gapped build, with local models and zero external API calls. We do not train models on your data, and a model tuned on your own data is built only on request and stays yours.
When a custom build is worth it, and when it is not
Some generative AI work does not need a build. If you only need drafting or summarizing of public text, a feature in a tool you already pay for costs less than any engagement with us, and we will tell you so on the first call.
A custom build earns its cost in three situations: the value comes from data nobody else has, your workflow does not match what a generic tool assumes, or a compliance requirement such as a signed BAA, an audit log or data that must stay in your own cloud rules out a shared product. A pod is also the wrong shape for a two-week one-off, which a freelancer can do for less, or for a permanent hire who will own one codebase for years.
How the pod is staffed and billed
A Builder Pod runs one active build track: a pod lead plus a two-engineer bench, weekly ship, month-to-month with 30 days notice. A Growth Pod runs two concurrent tracks with a three-engineer bench, weekly ship and a bi-weekly strategy call. Enterprise engagements, three or more parallel tracks with a dedicated senior lead, are scoped in a meeting. One generative AI workflow with its eval layer is one track. A second workflow, or a review dashboard next to the first, usually makes it two.
There is no per-hour billing and no change orders. You are billed for capacity, and the pod lead who scopes the work is accountable for shipping it. A small build typically runs one to three months and a medium one three to twelve. A paused month is not billed, and we hold your pod seat so the same team picks the work back up.