The single biggest reason an AI project goes off the rails is a fuzzy brief. A good brief is short, but it answers the questions a freelancer needs to give you an accurate price and timeline.
This is the structure we recommend on Clapwork.
The 7-part brief
1. Goal
What does success look like in plain language?
Bad: "We want to use AI."
Better: "We want to reduce the time our support team spends classifying tickets from 4 hours/day to under 1 hour/day."
A good goal includes the user, the action, and the change you want to see.
2. Data
What data is available, where does it live, and who can grant access?
- File formats (CSV, JSON, PDF, audio, video)
- Volume (rows, files, total size)
- Quality (clean, messy, mixed)
- Sensitivity (public, internal, regulated, PII)
If you do not have data yet, say so. That is a different (and bigger) project.
3. Constraints
Things that are not negotiable:
- Hosting region (e.g., must run in EU)
- Cloud or on-prem
- Allowed and disallowed third-party services
- Privacy rules (GDPR, HIPAA, India DPDPA)
- License requirements
4. Budget
A range is fine. "We can spend $3,000 to $5,000 for the initial build" tells a freelancer whether to propose a thorough solution or a quick prototype. "Reasonable" is not a budget.
If you don't know the typical range yet, list the work and ask freelancers to propose ranges in their first reply.
5. Timeline
When do you need the first usable version, and what is the hard deadline (if any)? Tie this to a real event — a launch, a board meeting, a quarter end — so the freelancer knows what is driving it.
6. Deliverables
List the things you expect to receive. For an AI feature, that often includes:
- Code in a repository you own
- A short README that explains how to run it
- An evaluation report (what was tested, what passed, what failed)
- Documentation for any prompts, training data, or model configs
- A demo (notebook, script, or short Loom video)
7. Success criteria
How will both sides know the work is done?
- A specific accuracy or quality target ("≥85% F1 on the held-out set")
- A specific latency target ("p95 latency under 800ms")
- A user-facing test ("the support team can run the classifier end-to-end without your help")
Without success criteria, the project can never officially finish.
A short example brief
Goal: Build a Retrieval-Augmented Generation answer engine over our internal product docs (~1,200 markdown files) so support agents can paste a customer question and get a cited draft reply.
Data: Public Git repo, English only, ~12 MB total. No PII.
Constraints: Must use an open-weights model we can self-host. No data sent to third-party APIs. Code in TypeScript or Python.
Budget: $4,000–$7,000 for the first build.
Timeline: Working prototype in 4 weeks; hand-off complete in 6.
Deliverables: Repo, README, eval report, weekly status, 30-minute hand-off call.
Success criteria: On a 50-question test set we will share, ≥80% of answers should be judged "good or very good" by two members of the support team. p95 latency under 5 seconds.
What freelancers do with a brief like this
They write a focused proposal that responds to each section. They flag risks (e.g., "1,200 markdown files is small — we may need to test if a re-ranker is worth it"). They give a price and timeline that match the scope, not a guess.
That saves both sides a week of back-and-forth.
A pre-submit checklist
- [ ] Goal in one sentence
- [ ] Data inventoried (format, volume, sensitivity)
- [ ] Constraints listed
- [ ] Budget range stated
- [ ] Timeline with at least one hard date
- [ ] Deliverables itemized
- [ ] Success criteria measurable
If any line is empty, the brief is not ready to post.