OpenAI API
Shipped on the OpenAI API, under real traffic
Our engineers run OpenAI models behind a phone line that books repairs, a trading alert dashboard and a meeting platform used in dozens of countries. The demo is the easy half.
What you are getting
4 things that decide this
- 01Senior engineers with OpenAI models live in named products on this site, including function calling on a real phone line.
- 02They design for the two things that decide whether it survives: what happens when the model is wrong, and what it costs at ten times the volume.
- 03You interview each engineer with your own process, and turning one down needs no explanation.
- 04Prompts, evaluation sets and the code around them sit in your repository from the first commit.
What shipping on the OpenAI API actually involves
A first API call takes an afternoon. What takes real engineering is everything protecting the product from the model's bad days.
On ZhoopZhoop, OpenAI Chat Completions handles reasoning and function calling inside a live phone system with Deepgram doing speech. A caller talks, the assistant decides which action to take, and a booking lands in a real calendar. On Trading CoPilot the OpenAI Responses API sits behind live trading alerts. Broollie uses GPT-4o and the smaller GPT-4o-mini together across meeting workflows.
That last detail is the one people skip. Choosing the cheaper model for the easy work is a design decision, and it is usually the difference between a feature that scales and a bill that surprises you.
What they build around the API call
Function calling with real limits
Tools the model may invoke, scoped narrowly, with arguments validated before anything runs. A confused model should fail a check, not book something wrong.
Output you can rely on
Structured responses validated against a schema. Parsing free text with string matching breaks the first time the model words it differently.
Routing by difficulty
Smaller models for classification and extraction, the larger one where it earns its cost. Broollie runs both for this reason.
Failure that stays contained
Timeouts, retries and a fallback path, so a slow or failed API call degrades one feature instead of the whole page.
Spend you can see per feature
Token use tracked where it happens, not as one monthly total. Usage-based costs are easy to ignore until the invoice arrives.
- InputCleaned and checked
- RouteWhich model, and why
- API callStructured output asked for
- ValidateShape and values checked
- Act or refuseTools run only if valid
- RecordCost, latency, outcome
Boxes two and four are where the money and the reliability live. Teams that build only box three ship a demo.
OpenAI models in live products
“They really help you understand the problem and deliver solutions in a short time frame.”
Johannes Peter · CEO, TomoDomo Coliving
How hiring works
- 01
Tell us what it must get right
A free call about the feature, the volume and what a wrong answer costs you. If a simpler approach beats a model here, we say so.
- 02
Meet the engineers
We shortlist people who have run OpenAI models under real traffic, and you interview them against your own bar.
- 03
They embed
Your repository, your release process, your environments. One of our engineers is named on the work and answers for it.
- 04
They hand over
Prompts under version control, the evaluation set, and cost figures per feature so nothing is a mystery later. Some clients keep us watching quality instead, under a service level we agree.
Stack
OpenAI
Around it
Practices
Bring us the feature that works four times in five
Show us where it fails and what that costs you. The scoping call is free, and you will leave knowing whether this needs a better prompt or a different design.
01Does OpenAI train on the data we send through the API?
No, not by default. OpenAI's developer documentation states that data sent to the API is not used to train or improve its models unless you explicitly opt in. Their consumer chat products are governed separately, which is where teams usually get caught. We check the current terms for the products you use during scoping.
02Should we use GPT-4o or one of the smaller models?
Both, for different work. Classification, extraction and routing usually run well on a smaller, cheaper model, while the harder reasoning justifies the larger one. Broollie uses GPT-4o and GPT-4o-mini together for exactly this reason, and picking per task is what keeps the cost sane at volume.
03What if we want to switch to a different model provider later?
Keep the provider behind your own interface and the switch stays a contained change. Our engineers build that boundary by default, because model quality and pricing move and being locked to one vendor is a business risk rather than a technical one. We also work with Claude, so this is not a loyalty question for us.
04How do you stop function calling from doing something harmful?
Validate the arguments before anything executes and expose only narrow tools. On ZhoopZhoop the assistant works a live phone line, so a booking action is checked before it reaches the calendar. Anything expensive or irreversible sits behind an approval step rather than the model's judgement.
05What does it take to keep API costs predictable?
Route easy work to cheaper models, cap what one request may spend, cache repeated calls, and track tokens per feature rather than as one bill. Costs scale with usage, so the surprise usually arrives in the month after a successful launch.
06What shapes the price of this work?
How much a wrong answer costs you. A feature where mistakes are cheap ships quickly. One touching money, bookings or customer records needs validation, review steps and far more testing. Scoping calls are free. Where the answer needs us inside your existing codebase, a paid two-week diagnostic replaces the estimate with a fixed price.
