LLM application development for business teams

What an LLM application actually is

An LLM application is ordinary software with a language model as one component. The model reads text, and sometimes images, and returns text or structured data. Everything around it is normal engineering: an interface or API, a queue, a database, permissions, logging and error handling.

That framing matters because most failed pilots are not model failures. They are scoping failures. Someone asks for an assistant that knows everything about the company, and nobody can say what a correct answer looks like. We start from the opposite end: one job, one input type, one definition of correct.

• Reading incoming emails and filing them into the right queue
• Pulling dates, amounts and parties out of contracts or invoices
• Writing a first draft of a reply that a person edits and sends
• Summarizing long call notes into the three fields your CRM needs
• Answering staff questions from your own manuals (this is a RAG chatbot)

Which kind of app fits which job

Different jobs fail in different ways, so they are tested in different ways. This is the table we use in the first call to decide what is worth building.

If the cost of a wrong answer is high and the volume is low, a person doing the work with a drafting aid is usually better than automation. We will tell you that on the call.

How we build it

1. Pick one jobWe agree the input, the output format and what counts as correct. If this takes more than one page, the job is too big and we split it.
2. Collect real examplesYou send about 50 real inputs with the answer a good employee would give. This becomes the test set and it never leaves your control.
3. Score a baselineWe run the simplest possible prompt against the test set across two or three models and record the score. Many projects stop here with a working answer.
4. Build the applicationInterface or API, queue, storage, authentication, retries, and a review screen where a person can accept or correct each result.
5. Add limits and loggingPer-day spend caps, input size limits, a log of every call and a way to replay any failure.
6. Pilot with a small groupA few users for two weeks. We read the failures together and re-run the test set after every change.

A worked example: sizing the volume before you commit

Suppose a support team receives 2,000 tickets a month and wants a short summary on each. An average ticket with its thread is about 1,500 tokens of input, and the summary is about 300 tokens of output. That is 1,800 tokens per ticket, so 2,000 tickets use 3.6 million tokens a month.

Add roughly 30 percent for retries, longer threads and prompt changes during the pilot and you plan for about 4.7 million tokens. You then multiply by the model vendor's current per-million-token rates, which we read from their price page at scoping time because those rates change. The point is that the sum takes ten minutes, and it tells you whether a larger model for every ticket is affordable or whether a small model should handle the easy ones first.

If the monthly bill matters less than the hours saved, we say so and pick the more accurate model. If volume is in the hundreds of thousands, routing matters more than any prompt.

What you get

• The working application, source code and deployment notes in your own cloud account
• The test set, the scoring script and the results for each model we tried
• Prompts stored as versioned files, not buried in code
• Spend caps, alerts and a log you can search
• A one-page runbook: what to do when the model vendor has an outage or changes a model

You get a fixed quote after a short call. Start at contact and tell us the job you have in mind.

Timeline and reporting

These are planning estimates, not promises. A single-job pilot with one integration usually takes three to six weeks from the first call to a pilot in front of users. Anything with several systems, permissions per user or document uploads takes longer, and we confirm the number in the quote.

During the pilot you get a short weekly note: test-set score now versus last week, the number of runs, spend against the cap, and the five worst failures with what we changed. After launch the same note goes monthly.

Our experience, stated plainly

We do not have a published LLM case study on this site, and we will not invent one. What we can point to is the custom software around data: for Aura Realty we built a CRM that pulls leads from the website, Instagram, WhatsApp and calls into one place. A model could sit on top of a system like that, but that project did not use one.

If you want proof of fit before paying for a build, the baseline step above is built for that. It costs a small fraction of the full project and produces a score you can judge yourself.

When you do not need custom development

If your task is general writing help for a few people, a team plan on a mainstream chat product is cheaper than any build. If you want a branded assistant with fixed instructions and some uploaded files, a custom GPT may be enough. Build custom when the model must sit inside your systems, handle volume, respect permissions or leave an audit trail.