AI & Machine Learning
OpenAI
AI features built on OpenAI’s API by engineers who evaluate, guardrail and operate them — not a demo that falls over in production.
Overview
OpenAI is not a single product; it is a family of hosted models and an API that lets you build AI features into your own software. The models span the frontier GPT line — general-purpose models that read, write and reason over text, images and audio — and the o-series reasoning models, which are trained to spend more time working through hard problems step by step before answering. You do not run these models yourself. You send a request to OpenAI’s API, their infrastructure does the inference, and you get a response back. That framing matters, because almost everything worth saying about building on OpenAI is about building a reliable product around a capability you rent rather than own.
The API surface is what we actually build against. Chat completions and the newer Responses API handle the core generate-a-reply loop; function and tool calling let the model decide to call your code with structured arguments; structured outputs let you constrain a response to a JSON schema so you get parseable data rather than prose you have to scrape. Around that sit the specialised endpoints — embeddings for semantic search and retrieval, vision for reading images and documents, the Realtime API for low-latency spoken conversation, Whisper for speech-to-text, and image generation. We compose these into retrieval-augmented generation systems, agentic workflows, document pipelines and voice interfaces, using streaming for responsive interfaces and the Batch API for cheaper bulk work that is not time-sensitive.
The mature position — and the one we hold with clients — is that the frontier hosted models are genuinely excellent, and you should still not build as though OpenAI is the only vendor or the model is a source of truth. Models get deprecated, prices change, a competitor leapfrogs on a specific task, and every request sends your data to a third party. So we design for portability behind a thin abstraction, we treat model output as a claim to be checked rather than a fact, and we build the evaluation and guardrail scaffolding that separates a convincing prototype from something you can put in front of customers and depend on.
Best for — Products that need frontier language, reasoning or multimodal capability delivered as a feature — chat, retrieval, extraction, agents, voice — where a senior team handles the evaluation, guardrails, cost control and portability that turn an impressive demo into something dependable.
Why teams choose OpenAI
Frontier capability with no infrastructure
You get access to some of the strongest models available through a request over HTTPS. There is no GPU fleet to provision, no model to fine-tune before it is useful, and no MLOps team to keep it running. The capability is available the day you start, and OpenAI absorbs the cost and complexity of serving it.
Structured, programmable output
Function calling and structured outputs turn the model from a text generator into a component you can wire into software. You define a JSON schema, the model returns data that conforms to it, and your code consumes it directly — which is what lets an LLM drive a workflow, populate a form, or decide which tool to call rather than just produce prose.
One vendor across text, voice and vision
A single API covers language, reasoning, embeddings, speech-to-text via Whisper, real-time voice and image understanding. A document pipeline that reads a scanned PDF, extracts fields, and answers questions about it can be built against one provider and one SDK, rather than stitching together several specialised services.
Why businesses choose OpenAI
- You want the strongest available language and reasoning capability in your product now, without building the infrastructure or the ML expertise to host and tune a model yourself.
- Your feature depends on structured, programmable output — the model calling your functions and returning schema-valid data — rather than just generating free text for a human to read.
- You need speed to a validated product, and you want the option to migrate the workload to another provider or a self-hosted model later without rewriting your application.
- You have — or want us to provide — the engineering judgement to evaluate outputs, guardrail against failure and prompt injection, control token spend, and keep the whole thing honest under real usage.
What we build with OpenAI
The capabilities this technology is genuinely strong at — and what we most often build with it.
Responses and chat completions
The core generate-a-reply loop. We build against the Responses API for new work and chat completions where it fits, managing conversation state, system prompts and message history deliberately — because the prompt is the program here, and how you structure context directly determines quality, cost and latency.
Function and tool calling
We define the tools the model may call — a database query, a search, an action in your system — as typed function schemas, and let the model choose when to invoke them and with what arguments. This is the mechanism behind agentic behaviour, and we design it so the model proposes actions while our code decides whether and how to execute them.
Structured outputs with JSON schema
When we need data rather than prose, we constrain the response to a JSON schema so the output is guaranteed to parse and match the shape our code expects. It removes the fragile regex-and-hope parsing that plagues naive integrations, and turns the model into a reliable extraction and classification component.
Embeddings and retrieval
We use OpenAI’s embedding models to turn documents and queries into vectors for semantic search, stored in a vector database. This is the retrieval half of a RAG system — finding the right passages to ground an answer — and we treat retrieval quality as a first-class problem, because a model can only be as accurate as the context you give it.
Realtime voice and Whisper
For spoken interfaces we build on the Realtime API for low-latency, interruptible voice conversation, and on Whisper for accurate speech-to-text in transcription and analysis pipelines. We are candid about the added complexity of streaming audio, turn-taking and latency budgets that voice introduces over a text integration.
Vision and image generation
The vision-capable models read images and documents — invoices, forms, screenshots, scanned PDFs — and return structured data or answers, and image generation produces or edits visuals from a prompt. We combine vision with structured outputs for document-understanding pipelines where the input is a picture and the output must be clean, typed data.
Use cases
Retrieval-augmented question answering
A system that answers questions over your own knowledge — policies, documentation, support history — by retrieving the relevant passages with embeddings and having the model answer grounded in them, with citations back to source so answers can be checked rather than trusted blindly.
Agentic workflows
Multi-step processes where the model plans, calls tools to gather information or take actions, and works towards a goal — triaging a request, researching across systems, drafting an output. We build these with explicit guardrails and human checkpoints, because an agent with real permissions needs real supervision.
Document and data extraction
Turning unstructured input — contracts, emails, PDFs, scanned forms — into structured, validated data using vision and structured outputs. This is one of the highest-ROI uses of the API: replacing manual data entry with a pipeline whose output conforms to a schema your systems already understand.
Voice and conversational interfaces
Spoken assistants and transcription-driven products built on the Realtime API and Whisper — a support line that understands and responds in real time, or a pipeline that transcribes and analyses recorded calls at scale to surface what matters.
When OpenAI is the right choice
- You want state-of-the-art language, reasoning or multimodal capability without training or hosting a model yourself. OpenAI’s frontier models are among the strongest available, and the API removes the entire burden of GPU infrastructure — this is the common, sensible case.
- Your problem is genuinely language-shaped: summarising, extracting structure from messy text, classifying, drafting, answering questions over your own documents, transcribing speech, or reading images and PDFs. These are the tasks the models are strongest at and where the ROI is clearest.
- You need to move quickly and validate a product idea. Building on a hosted API gets you from concept to a working feature in days, not the months a self-hosted or fine-tuned model would take — and you can always migrate the workload later if economics or privacy demand it.
- Wrong for: anything you need to be deterministic, auditable and exactly repeatable — pricing calculations, financial postings, legal thresholds, safety-critical logic. These belong in ordinary code you can test and reason about, not behind a probabilistic model, even a very good one.
- Wrong for: data that legally or contractually cannot leave your control, where even OpenAI’s zero-retention and enterprise arrangements do not satisfy the requirement. In that case an open-weights model you host, or a different architecture entirely, is the honest answer — and we will say so rather than talk you past the constraint.
OpenAI: pros and cons
Strengths
- Consistently at or near the frontier on general language and reasoning tasks, with the o-series adding genuine step-by-step problem solving for the harder cases where a single-shot answer is not enough.
- A broad, well-documented API — Responses and chat, tool calling, structured outputs, embeddings, vision, Realtime and Whisper — with mature SDKs, so most product ideas can be built without leaving the ecosystem.
- Structured outputs and function calling make the model programmable: you get schema-valid JSON and tool invocations you can depend on, which is the difference between a chatbot and an AI feature embedded in a real workflow.
- Fastest path from idea to working product. You validate whether AI solves your problem in days, and the operational burden of serving a large model sits with OpenAI rather than your team.
Trade-offs
- Cost at scale is real and easy to underestimate. Per-token pricing is cheap for a prototype and a serious line item at volume, especially with large contexts, long retrieved passages or reasoning models that consume tokens while they think. Without prompt discipline, caching and the Batch API for non-urgent work, spend climbs faster than usage.
- Every request sends data to a third party. That raises privacy and compliance questions that must be answered honestly. Zero-retention endpoints and enterprise agreements mitigate this and often satisfy the requirement — but not always, and for some data the correct answer is that it cannot go to OpenAI at all.
- Vendor dependency and model deprecations. You are building on a platform whose models are retired on OpenAI’s schedule, whose prices you do not set, and whose behaviour shifts between versions. A model your prompts were tuned against will eventually be sunset, and you must be ready to move.
- Non-determinism and hallucination are inherent. The same prompt can yield different answers, and the model will state false things with complete confidence. This is not a bug to be patched but a property to be engineered around, with evaluation, retrieval grounding, guardrails and human review where the stakes justify it.
Architecture
Building a product on OpenAI’s API is a software-engineering problem, not a prompt-writing one, and the architecture is where success is decided. We treat the prompt as a designed artefact with a clear contract, version it, and keep it in the codebase rather than scattered through the app. Around it we build the pieces that make the model useful and safe: a retrieval layer that fetches the right context so the model answers from your data rather than its training, output validation that checks structured responses against a schema before anything downstream trusts them, and guardrails that constrain what the model is allowed to see and do.
Two decisions get made early because they are expensive to retrofit. The first is an evaluation harness — a set of representative inputs with known-good outputs that we run prompts and model changes against, so quality is measured rather than felt, and so we can tell whether a prompt tweak or a model upgrade actually helped. Without evals you are flying blind, and every change is a guess. The second is fallback and degradation behaviour: what happens when the API is slow, rate-limited or down, whether we retry with backoff, drop to a cheaper or alternative model, or fail gracefully with a clear message rather than a hung request.
Underpinning both is portability. We put the model behind a thin internal interface so the rest of the application does not know or care which provider or model is serving a request. That is what lets us swap models when OpenAI deprecates one, route different tasks to different models on cost or quality grounds, or move a sensitive workload to a self-hosted model — without rewriting the product. Critically, we never let the LLM be the source of truth: it drafts, extracts, classifies and proposes, and deterministic code and your systems of record hold the facts.
Performance
Performance on the API is mostly about latency and how you hide it. Large models take real time to generate, and reasoning models take longer still because they are working through the problem before answering. For anything a user waits on, we stream tokens so text appears as it is produced and the interface feels responsive even while the full answer is still being generated. We keep prompts and retrieved context as tight as they need to be and no tighter, because every unnecessary token adds both latency and cost, and we choose the smallest model that meets the quality bar for each task rather than defaulting to the largest for everything.
For work that is not interactive — bulk classification, embedding a large corpus, overnight document processing — we use the Batch API, which trades immediacy for a substantially lower price and higher throughput. We design pipelines to separate the interactive path, where latency matters, from the bulk path, where it does not, so each is optimised for what it needs. And we measure real latency and token consumption per feature under representative load, because the cost and speed of an LLM feature are properties you engineer deliberately, not numbers you discover on the bill.
Security
The first security fact about OpenAI is that requests leave your infrastructure and go to a third party, so data governance comes before code. We map what data actually needs to reach the model, minimise and redact where we can, and use zero-retention endpoints and enterprise agreements where the compliance requirement calls for them — and where even those are insufficient, we say so and design around it rather than quietly sending data that should not go. API keys are treated as the secrets they are: held server-side, never shipped to a browser or mobile client, scoped and rotated.
The second is that an LLM integration introduces failure modes ordinary software does not have. Prompt injection — malicious instructions hidden in a document, a web page or user input that try to hijack the model — is a genuine and current threat, especially in agentic and retrieval systems where the model reads untrusted content. We defend by never granting the model unmediated power: tool calls and generated actions are validated and authorised by our code before execution, model output never reaches a shell, a raw database query or a filesystem without checks, and we bound what an agent can do so a successful injection cannot cause real damage. We also guard against the model leaking one user’s data to another and against it being coaxed into unsafe output.
Scalability
Scaling on OpenAI is unusual because the expensive, hard-to-scale part — running the model — is OpenAI’s problem, not yours. Your application tier stays a normal, stateless, horizontally scalable service. What you scale against instead is rate limits and cost. OpenAI enforces per-model request and token limits, so a system under load must handle throttling deliberately: queuing, exponential backoff, and shaping bursty demand so it does not hit the ceiling all at once. We build these in from the start rather than discovering them when traffic arrives.
Cost scales with usage in a way that ordinary compute does not, so scaling well means spending well. We route each task to the cheapest model that meets its quality bar, cache aggressively where inputs repeat, push non-urgent work to the Batch API, and keep prompts and context lean. For high volume we can spread load across providers and models behind the same portability layer, both to stay under any single vendor’s limits and to arbitrage on price and capability. The result scales on traffic without the bill scaling faster than the value.
OpenAI integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start by pressure-testing whether the problem is actually one an LLM should solve, because the honest answer is sometimes no — and it is far cheaper to hear that in week one than after a build. When it is a fit, we get a thin end-to-end slice working against real data quickly: one prompt, real retrieval, structured output validated, running in your application rather than a notebook. That slice tells us more about feasibility and cost than any amount of planning, and it is built on the evaluation and guardrail scaffolding from the outset rather than bolted on once the demo has already convinced everyone.
From there we iterate with measurement, not vibes. Prompt and model changes are run against the evaluation harness so we can see whether they help; cost and latency are tracked per feature; guardrails and fallbacks are tested against the failure cases, not just the happy path. The engineers who design the system operate it, which is the point of the way we work — we are the ones who will be paged when a model is deprecated or a bill spikes or an injection is attempted, so we build for that reality from the first commit.
The service behind it
Delivered throughAI DevelopmentWhat we build with OpenAI
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use OpenAI in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in AI & Machine Learning
Related terms
Why teams choose us for OpenAI
We build products, not demos
Anyone can get an impressive answer out of the API in an afternoon. The hard part — evaluation, guardrails, cost control, handling non-determinism and failure — is where most integrations quietly break in production. That hard part is exactly what we do, because we are the ones who then have to keep the thing running.
We operate what we build
We run the AI systems we ship, so we design for the on-call reality: rate limits handled, fallbacks in place, spend watched, model deprecations survivable. You get a feature that stays useful and affordable under real traffic, not one that works in the pitch and surprises you on the invoice.
Honest about the model’s limits
We treat the LLM as a capable but fallible component, never a source of truth. We are blunt about hallucination, about what should stay in deterministic code, and about data that should not go to a third party at all — and we build accordingly rather than pretending the model is more reliable than it is.
Portable by design
We put OpenAI behind a thin abstraction from day one, so you are never trapped. When a model is deprecated, a competitor pulls ahead, or a workload needs to move on-premise for compliance, you change a layer rather than rewrite the product. Building on the best hosted model and keeping the exit open are not in tension — we do both.
Typical timeline
- 01
Discovery and feasibility
One to two weeks establishing whether an LLM genuinely fits the problem, what data it needs, the quality and compliance bar, and the model and architecture that suit — with an honest answer if the answer is that AI is the wrong tool here.
- 02
End-to-end slice
Two to three weeks building one real feature against real data — prompt, retrieval, structured output, validation and a first evaluation set — running in your application, so feasibility, quality and cost are proven against reality rather than a plan.
- 03
Iterative build and evaluation
Feature-by-feature delivery in short cycles, each measured against the evaluation harness, with guardrails, fallbacks, cost controls and prompt-injection defences built in as we go rather than added at the end.
- 04
Hardening and handover
Load and rate-limit testing, a security and data-governance review, cost profiling under real usage, and documentation of prompts, evals and the portability layer so your team can own, extend and swap models safely.
How pricing works
- Fixed-scope builds for well-defined AI features — a retrieval assistant, a document-extraction pipeline, a voice interface — quoted once the data, the quality bar and the integration points are understood.
- Monthly senior engagement for ongoing AI product work, where the scope evolves as you learn what the model can and cannot do for your users and you want continuity rather than a one-off deliverable.
- Focused audits and rescues for existing OpenAI integrations — a prototype that will not survive production, spiralling token costs, weak evaluation, or a system that hallucinates in ways you cannot control — priced by the assessment.
Hire OpenAI engineers
Need OpenAI capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire OpenAI engineersCommon questions
Should we use OpenAI, or self-host an open-weights model?
For most teams starting out, OpenAI is the right call: the frontier models are stronger than what you can easily self-host, and you avoid the cost and complexity of running GPUs. Self-hosting an open-weights model earns its keep when data cannot leave your control for compliance reasons, when volume is high enough that per-token pricing outweighs infrastructure cost, or when you need a level of control and determinism the API will not give you. Because we put the model behind a portability layer, this is not a one-way door — we can start on OpenAI to validate the product and move specific workloads later without rewriting the application.
How do you stop the model from hallucinating or making things up?
You cannot make a language model incapable of being wrong, so we engineer around it rather than pretend otherwise. Retrieval grounds answers in your actual documents and we cite sources so claims can be checked. Structured outputs constrain the model to a schema so it cannot wander. Evaluation harnesses catch regressions in accuracy before they ship. And critically, we never let the model be the source of truth — it drafts, extracts and proposes, while deterministic code and your systems of record hold the facts. For high-stakes outputs we keep a human in the loop. The goal is a system whose failures are bounded and visible, not a model that never errs.
What will this actually cost to run at scale?
That is the right question to ask early, because token costs are trivial in a prototype and a real line item at volume. The drivers are how many requests you make, how large your prompts and retrieved context are, which model you use, and whether reasoning models are consuming tokens while they think. We control it by routing each task to the cheapest model that meets its quality bar, caching where inputs repeat, keeping prompts and context lean, and pushing non-urgent work to the Batch API for a substantial discount. We model expected cost per feature during discovery so there are no surprises on the bill, and we track it in production.
Is it safe to send our data to OpenAI?
It depends entirely on the data and your obligations, and we treat that as the first question, not an afterthought. For much business data, OpenAI’s zero-retention endpoints and enterprise agreements — under which your inputs are not used for training and are not retained — satisfy the compliance requirement. For genuinely sensitive or regulated data, they may not, and in that case the honest answer is that the data should not go to OpenAI at all, and we design around it with redaction, minimisation, or a self-hosted model. We will map your data flows and tell you plainly which category you are in rather than wave the concern away.
What happens when OpenAI deprecates the model we built on?
It will happen — models are retired on OpenAI’s schedule, and behaviour shifts between versions — which is exactly why we design for it. The model sits behind a thin internal interface, so swapping to a successor or an alternative provider is a change in one layer rather than a rewrite of your application. Our evaluation harness then tells us whether the new model actually holds up on your tasks, so a migration is a measured, low-drama exercise rather than a fire drill. Building on the best available model and staying free to move off it are not a contradiction; treating them as one is how teams get trapped.
Building on OpenAI?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.