We already pay for AI tools. What are we actually buying here?

Consistency, and the distribution of what your best person already worked out. The usual pattern three months after a company-wide rollout is that a handful of people get excellent results, most get mediocre ones, and nobody knows why. The difference is almost entirely in how the request is written. This turns that into shared property instead of individual knack.

Why do you need to watch people work rather than just ask them?

Because people describe the job they think they do, not the one they actually do. Sitting alongside someone for an hour reveals the reformatting, the re-asking, the copying between two windows and the small corrections at the end — and those are where the time goes. A library built from interviews covers tasks nobody performs and misses the ones that eat the week.

How do we know the prompts actually work?

Because each one is run against your own real data five to ten times before it is handed over, and the results are recorded. That record is part of what you receive, not something we keep. It also tells you where a prompt is reliable and where a human still needs to check the output, which is information nobody gets from a prompt they downloaded.

Will this stop people pasting things they should not?

It addresses the largest part of it. The library carries an explicit list of what never goes into an AI tool — customer personal data, credentials, anything under a confidentiality agreement — and which outputs require a person to review before they are used. That is a written standard people can follow, and a rollout on its own does not produce one.

Can the prompts live in our own systems rather than a document?

They can, and it changes the nature of the job. A library in a document or a wiki is this service. Wiring prompts into your own software, with versioning and monitoring around them, is a software project with a different scope and a different price, and we would quote it that way rather than let it grow quietly out of this one.

How long before the library goes stale?

The prompts themselves age slowly — what ages is your business. New processes appear, formats change, and a prompt written against last year's report structure stops fitting. The library is built so a prompt can be edited by the person who uses it, and the training session covers exactly that, because a library only one supplier can change becomes a liability.

AI & Machine Learning

A tested prompt library your whole team can use

The fifteen to twenty-five things your people ask an AI tool to do every week, written properly once, tested against your own real data, and handed over with the rules about what must never be pasted in.

From: $500–$5,000
Typical time: 1–4 weeks
Usually bought by: Teams adopting AI

What this actually solves

The common situation is a company that did the obvious thing and bought everyone access to an AI tool. Three months later, five people are producing genuinely useful work with it, fifteen are producing output that needs so much correction it saves nothing, and two or three have pasted customer information into a system nobody vetted. None of that is a tool problem. It is entirely a question of how the request is written, and that knowledge is currently sitting in a few people's heads.

What a company buys here is repeatability. Two people in the same role should get comparable output from the same task, and the excellent prompt one person developed by trial and error should belong to everybody. This is the least expensive service in the category and often the first one a company buys, largely because the result is visible inside a fortnight and needs no engineering commitment at all.

How the work runs

Watch the work being done. Sitting with people while they use the tool, rather than asking them to describe it. This is where the real list comes from — including the tasks people are quietly doing badly and the ones they abandoned because the results were poor. Two to four days.
Choose the fifteen to twenty-five tasks worth writing. Frequency first, then how much time each one absorbs, then how much variation there currently is between people doing it. One to two days.
Write each prompt in full. Role, the shape of the input with placeholders, the task, the exact output format including section lengths, the explicit list of things it must never produce — speculation, anything not present in the supplied data, blame directed at a named person — and two worked examples. Where it earns its place, a short version, a detailed version and a one-line version of the same prompt. Four to seven days.
Test every prompt on your real data. Five to ten runs each, deliberately including the awkward cases — empty data, contradictory data, unusually long inputs, angry source material. Results recorded in a sheet that comes to you with the library. Three to five days.
Write the guardrails. What must never be entered under any circumstances, which outputs require review before use, and which tasks should not be given to an AI tool at all. This is the shortest document in the project and the one your risk people will care about. One to two days.
Assemble, train and hand over. The library goes wherever your team already works — usually a wiki or a shared document space rather than somewhere new. A two-hour session walks through using and editing the prompts, and everyone gets a one-page reference for the desk. Two to three days.

One detail worth knowing, because it affects your bill as well as your output: generated text costs several times more than supplied text on every commercial model. A line in a prompt capping the response length is simultaneously a quality decision and a cost control, and prompts written without one are a quiet recurring expense.

What changes the quote

How many departments are involved. Marketing, customer success and finance are three separate task inventories, three sets of real test data and three different vocabularies. One department sits at the bottom of the range and the work is genuinely quick.

Whether training and materials are included. A set of written prompts is one thing. A delivered session, a reference sheet and a written standard for the whole team is the thing that actually changes behaviour, and it is a real addition to the scope.

Whether the prompts stay in a document or go into your systems. The moment prompts are embedded in your own software, with versioning and monitoring around them, this stops being a library project and becomes a build. That is a legitimate thing to want — it is simply priced as what it is.

Where these go wrong

A beautiful library of untested prompts. A well-organised page with twenty-five prompts in it looks like excellent value on the day it is delivered. Two weeks later the team reports that half of them do not survive contact with real inputs, because they were written against tidy imagined examples. Every prompt gets run on your own data before handover, and the record of those runs is part of what you are buying.

The task list comes from asking rather than watching. People describe the clean version of their job. The library then covers work that occurs twice a month and completely misses the reformatting task somebody does eleven times a day, which was the one worth automating. The inventory has to come from observation or the whole library aims at the wrong targets.

No written rule about what must never be entered. This is the half of the job that gets skipped because it is not the fun part, and it is the half your legal or compliance people will ask about first. Without it, the predictable outcome is a customer list, a contract under an agreement, or a set of credentials pasted into a general consumer tool by someone who was simply trying to get their work done.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We already pay for AI tools. What are we actually buying here?: Consistency, and the distribution of what your best person already worked out. The usual pattern three months after a company-wide rollout is that a handful of people get excellent results, most get mediocre ones, and nobody knows why. The difference is almost entirely in how the request is written. This turns that into shared property instead of individual knack.
Why do you need to watch people work rather than just ask them?: Because people describe the job they think they do, not the one they actually do. Sitting alongside someone for an hour reveals the reformatting, the re-asking, the copying between two windows and the small corrections at the end — and those are where the time goes. A library built from interviews covers tasks nobody performs and misses the ones that eat the week.
How do we know the prompts actually work?: Because each one is run against your own real data five to ten times before it is handed over, and the results are recorded. That record is part of what you receive, not something we keep. It also tells you where a prompt is reliable and where a human still needs to check the output, which is information nobody gets from a prompt they downloaded.
Will this stop people pasting things they should not?: It addresses the largest part of it. The library carries an explicit list of what never goes into an AI tool — customer personal data, credentials, anything under a confidentiality agreement — and which outputs require a person to review before they are used. That is a written standard people can follow, and a rollout on its own does not produce one.
Can the prompts live in our own systems rather than a document?: They can, and it changes the nature of the job. A library in a document or a wiki is this service. Wiring prompts into your own software, with versioning and monitoring around them, is a software project with a different scope and a different price, and we would quote it that way rather than let it grow quietly out of this one.
How long before the library goes stale?: The prompts themselves age slowly — what ages is your business. New processes appear, formats change, and a prompt written against last year's report structure stops fitting. The library is built so a prompt can be edited by the person who uses it, and the training session covers exactly that, because a library only one supplier can change becomes a liability.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Prompt engineering & prompt library All AI & Machine Learning services