Apps and software

OpenAI integration

The ChatGPT models doing real work inside your software, with the cost controls and testing that keep it usable after the demo.

The short answer

An OpenAI integration puts the ChatGPT models inside your own software, doing work like summarising a case file, drafting a reply or answering questions from your own documents. The API call is the easy part. The cost control, the grounding and the testing around it take the time.

What the work covers

  • The feature built into your product, not bolted on as a chat bubble
  • Retrieval, so answers come from your documents rather than the model's memory
  • Spend limits per user and per day, with alerting before the invoice does
  • Streaming responses, so the screen moves while the model is still writing
  • Input handling that assumes users will try to talk the model into something
  • A test set, so two versions can be compared before either ships
  • Prompt and response logging, so a bad answer can be traced

What separates a demo from something customers can use

Anyone can wire up the API in an afternoon, and the demo will look excellent. The gap between that and software you'd put in front of a paying customer is where the work sits, and it's nearly all guardrails rather than model calls.

Cost scales with usage, and an unbounded loop is an unbounded bill.

You aren't buying a licence, you're buying tokens, and every long document, every retry and every chatty user costs more of them. An agent that calls itself in a loop with no ceiling will spend hundreds of dollars overnight on a bug nobody noticed. Cap it per request and per day, cache what repeats, and use a smaller model where a smaller model does the job.

Latency is a design problem, not just a speed problem.

A model that takes eight seconds feels broken if the screen sits still. The same eight seconds feels fine if words start appearing after half a second. Stream the response, and push slow work into the background where nobody is waiting on it. What people report is perceived speed, not measured speed.

Ground it in your data instead of asking it to recall.

A model asked what your refund policy says will produce something confident and plausible. Give it the actual policy and the failure mode changes from invention to omission, which is much easier to live with. Answers should cite the document they came from, so a person can check in one click. Where the answer carries legal or clinical weight, a human signs it off before a customer sees it.

Prompt injection starts the moment user text reaches the model.

If a user can type into it, someone will paste instructions telling it to ignore its rules, reveal the prompt or call a tool it shouldn't. The same trick arrives through documents and web pages the model reads. Treat every input as untrusted, keep tool permissions narrow, and never let model output decide whether an action is allowed.

Without a test set you're guessing.

Change a prompt and it behaves differently on cases you didn't think about. The only way to know whether a change helped is a set of real examples with known good answers, scored the same way each time. Fifty examples from your own data beat trying it a few times and feeling positive about it.

How we run the build

  1. We pick the narrow use case

    One job the model does well, with a measurable before and after. Broad assistants are where budgets go to die.

  2. We agree scope and price

    Fixed scope, fixed number, with the running cost estimated separately so you know both.

  3. We build and evaluate

    Prompts, retrieval and limits, tested against a scored set before anything ships.

  4. We watch spend and quality

    Token cost, error rates and flagged answers reported monthly.

Who this suits, and who it doesn't

It suits businesses with a repetitive text job at volume, document heavy work, or a support queue full of questions your content already answers.

It's a poor fit if you want AI because competitors have it. Without a task and a number attached, it becomes something you pay for monthly and nobody uses.

Why clients hand us this work

Developers who also run the servers.

Whoever writes it keeps it running and watches what it costs. AWS certified, in house.

Your account, your data.

The OpenAI account is yours, along with the prompts and the logs.

No lock in contracts.

Projects are fixed scope. Support is month to month.

"We tried this and it made things up."

Usually because it was asked to recall rather than given the source. Grounding and citations fix most of it. The rest is deciding which answers a person checks first.

FAQs

Frequently asked questions

Still wondering about something? Call 07 3067 8910 or 0425 879 379, mon to fri, 8:30am to 5:30pm.

  • It depends on volume and how much text goes into each request. We estimate it during scoping and cap it.

Tell us the job you want it doing

Book a discovery call. Bring the task rather than the technology, and we'll tell you whether a model is the right answer and what it costs to run.

Book a discovery call Talk to a developer

Ready for a website that brings in work?

Tell us what you need and we'll show you how we'd approach it. No pressure, just a straight answer about what will work for your business.