I've watched smart developers hand over weeks of work for a fraction of what they should have earned. Not because they undercharged per hour, but because they never defined what the project actually was.
AI consulting has a scoping problem. Clients come in with vague ideas ("I want an AI chatbot for my business"), you build something reasonable, and then the goalposts move. Suddenly the chatbot needs to integrate with their CRM, handle refunds, speak three languages, and "learn" from conversations. What started as a two-week project becomes a two-month nightmare — at the original price.
Here's the framework I use to scope AI and LLM projects before touching a single line of code.
Why AI Projects Break Pricing Faster Than Any Other Work
Traditional software projects have bounded complexity. Build a contact form, it does what a contact form does. Build an LLM pipeline and you're contending with probabilistic outputs, prompt sensitivity, hallucination edge cases, context limits, inference costs, and clients who don't understand any of it.
This creates a specific danger: the client sees a demo, assumes it's done, and expects everything else for free.
A client once showed me a ChatGPT screenshot and said, "I want this, but for my documents." I quoted two weeks. Six weeks later I was still debugging chunk retrieval inconsistencies because their documents were scanned PDFs with two-column layouts. Nothing in the original spec mentioned document format. My fault for not asking.
The framework below is built from that kind of pain.
Step 1 — Separate the Demo from the Product
The first thing I do on any call is ask: "What does done look like to you?"
Most clients will describe a demo. A polished UI, a few impressive responses, something they can show their boss. That's not a product. A product handles edge cases, fails gracefully, monitors costs, and works at 2am when no one's watching.
Before pricing, draw a hard line between three states:
- Proof of concept — works in ideal conditions, no error handling, no logging, no infra
- MVP — works reliably for the defined happy path, basic monitoring, production-ready enough to show real users
- Production system — full error handling, fallback logic, cost controls, observability, documentation, handoff materials
Each of these is a different project with a different price. Confusing them is where scope creep is born. I now put this taxonomy in every proposal document, in plain language, and ask the client to point to which state they're buying.
Step 2 — Define the Input and Output Contracts First
LLM projects fail at the boundaries, not in the middle. The model is usually the easy part. What kills you is:
- Messy input data (PDFs, voice notes, inconsistent CSVs)
- Undefined output format (the client said "a summary" but meant a structured JSON for their API)
- Changing context sources (they add a new knowledge base in week three)
Before pricing, write an input/output contract: exactly what data goes in, in what format, and exactly what comes out, in what format. Specify who is responsible for preparing the input data. This is non-negotiable.
For a recent project — an automated competitor analysis tool — I specified: input is a list of URLs in a CSV, one per line, no authentication required. Output is a JSON object with six defined fields. Any deviation from that spec triggers a change request. The client agreed upfront. The project stayed on time.
If the client can't define their inputs and outputs in a 30-minute call, the project isn't ready to be scoped. I push back and reschedule.
Step 3 — Price by Deliverable, Not by Hour
Hourly pricing on AI projects punishes you for getting better at your craft and rewards you for struggling. It also creates constant anxiety for the client every time you send an invoice.
Instead, price by deliverable. Each item in your proposal should be a concrete, verifiable artifact:
- Working RAG pipeline that retrieves from X documents with Y accuracy threshold
- Prompt system with defined behavior across Z test cases (include the test suite)
- Deployed API endpoint with documented request/response schema
- Monitoring dashboard showing token usage and error rates
Each deliverable gets a fixed price. Change requests outside the defined spec get quoted separately before any work starts.
For pricing the deliverables themselves, I use a simple multiplier: estimate the time in ideal conditions, multiply by 2.5 for an AI project (versus 1.5 for a standard dev project). The extra buffer accounts for prompt iteration, unexpected model behavior, and client feedback loops that are harder to predict than in traditional development.
Step 4 — Build Inference Costs Into the Quote
This one is easy to forget and expensive when you do. If you're building a system that calls GPT-4o or Claude, those API calls cost money — and that cost belongs to the client, not you.
Be explicit about it. Include a section in every proposal that reads something like: "This system will make approximately N API calls per day at an estimated cost of $X/month at current rates. This cost is separate from development fees and will be borne by the client directly via their own API key."
Never run client workloads on your own API key unless you've built the billing pass-through explicitly. I learned this after absorbing $180 in inference costs on a "quick prototype" that the client ran 4,000 times over a weekend because it was on my endpoint.
Step 5 — Use a Scoping Doc as a Contract Appendix
Before any money moves, send a two-page scoping document. Not a proposal — a scope definition. It covers:
- What this project does (three sentences maximum)
- What this project explicitly does not do (list at least five things)
- Input and output contracts
- Deliverables and acceptance criteria
- Change request process (written request, 48h quote, approval before work)
The "does not do" list is the most important part. Writing it forces clarity. Showing it to the client surfaces mismatches before work starts, not during it. If they push back on something in that list, you either expand the scope and reprice, or you document that it's out of scope and hold the line.
I've started using this document on every project, even the small ones. It's stopped three scope-creep situations in the last year cold — the client looks at item four on the "does not do" list and says "oh, I thought that was included." Better to have that conversation on day one than day forty.
Pricing Is a Skill, Not a Formula
There's no spreadsheet that spits out the right number. Pricing AI work well comes from reps — proposals written, scope debates survived, projects that went sideways despite good intentions, and the gradual calibration of what "done" actually costs to deliver.
If you're early in that journey and want a shortcut, I put together everything I use — proposal templates, the scoping doc framework, pricing calculators, and a decision tree for fixed vs. retainer engagements — in the AI Project Pricing & Scoping Playbook. It's 12€ and built for indie developers and freelancers who are tired of getting squeezed on AI projects they underscoped.
The framework is learnable. The mistakes are avoidable. Start with the scoping doc, hold the line on your input/output contracts, and price the deliverable, not the hour.