Why we price AI work before we build it

Ask a small team to “build us an AI agent” and you’ll usually get one of two answers. An hourly rate with no end in sight, or a confident number that turns out to be the price of a demo, not of something your team can use on a Monday morning.

Both answers have the same root problem: nobody wrote down what “done” means. AI work makes that worse than normal software, because the hard part is rarely the code. It’s deciding what the system should do when the input is messy, the model is wrong, or the task is ambiguous. If those decisions get made halfway through the build, the budget moves every time one comes up.

So we do it the other way round. We price the work before we build it, and the price comes with a written scope.

Packages, not open-ended quotes

Our Plans page lists fixed-scope packages for the work we do most often:

• AI Setup Session — a 90-minute call where we set up your AI tools around your real work, with a written playbook afterwards.
• Prompt System — a prompt library built on your team’s real tasks, versioned and tested against real outputs, with a handover doc and one revision round.
• Agent Sprint — one working agent with real tool use, evals and guardrails, deployed where your team already works, plus two weeks of fixes after launch.
• Data & Automation — scrapers, pipelines and dashboards, scheduled reports to your inbox, built on your data and documented.
• Studio Retainer — a fixed block of build hours every month for new automations, fixes and upgrades.

Each one has a price (or a starting price) and a duration on the card. You know roughly what you’re signing up for before you’ve spoken to us.

The packages are deliberately narrow. “One working agent” — not “an AI strategy”. “A prompt library built on your team’s real tasks” — not “prompt engineering”. Narrow is what makes a fixed price honest. It’s also a forcing function for us: if we can’t describe a deliverable in one line, we don’t understand it well enough to sell it.

How it works

Three steps, and none of them is a checkout maze:

1. Pick the closest package. Every card opens the contact form already tagged with it, so we know what you clicked.
2. Tell us the problem. A few lines on what you need and by when. No deck, no brief template.
3. Get a fixed scope. Within 48 hours you get a written scope and a fixed price. Then we build.

“From” prices exist because two Agent Sprints are rarely the same size. The scope document is where the “from” turns into one number — and once it’s agreed, that number doesn’t move unless the scope does.

What’s in a scope document

A scope document is short. It’s not a contract full of legal language; it’s the shared definition of “done”. Ours has the same sections every time:

The problem, in your words. Three or four sentences, using your vocabulary, not ours. If we can’t restate the problem in a way you’d nod at, we’re not ready to price it.

What we’ll build, as checkable items. Every deliverable is something you could point at and say “that’s done”. “An agent that drafts replies to support tickets in your helpdesk” is checkable. “Improved support efficiency” isn’t.

How we’ll know it works. For AI systems this is the part people skip. We write down the test cases up front: the real inputs we’ll run, what a good output looks like, and what the system should do when it doesn’t know. For an agent that means evals and guardrails; for a prompt system, the real outputs each prompt is tested against.

How we’ll work. Phases with dates, and what you see at each one. No two-week silence followed by a reveal.

What we need from you. Access, sample data, someone who can answer questions. A surprising amount of AI project delay is waiting for an API key.

What’s not included. This is the most important section, and the one that protects both sides most. Integrations we’re not doing, languages we’re not supporting, volumes we’re not designing for. Writing it down turns “I assumed that was included” into a conversation before the build, not an argument after it.

Price and what changes it. The fixed price, the payment schedule, and the specific things that would change it — usually new deliverables or a jump in scale.

Next step. One action, with a date.

How it protects you

You know the price before anything starts, and it’s tied to deliverables you can check, not hours you can’t. You can compare us to anyone else on the same terms. And if what you actually need is smaller than you thought — sometimes the honest answer to “build us an agent” is a good prompt and a 90-minute setup session — you find that out before you’ve spent anything.

How it protects us

A written scope protects a small studio just as much. It stops the slow creep where “one more small thing” turns a two-week sprint into a two-month one. It makes us think through the hard cases before we commit to a number, which is exactly where AI projects go over budget. And it makes changes clean: a new requirement isn’t a fight, it’s a line item with its own price.

It also keeps us honest about what we’re good at. If a request doesn’t fit any package and we can’t scope it clearly, that’s a signal — either we need to ask better questions, or it’s not a project we should take.

The trade-off

Fixed scope isn’t free. Scoping takes real work up front, on both sides. Some projects genuinely need exploration before anyone can price them — and for those, the right move is to scope the exploration itself: a short, fixed piece of work whose deliverable is the answer to “what should we build?”

What we won’t do is start building on a vague brief and an open meter. That’s how AI projects end up as impressive demos and disappointed clients.

If you have something in mind, start with the Plans page — or if nothing there fits, describe your project and we’ll come back with a scope.