The BUY-RIGHT 6: what to prepare, what to pay, what to demand, and the red flags that predict a wasted budget
For business owners, agency owners, and team leads considering their first custom AI tool. Written by someone who builds them - which means I'm biased, and also means I've seen exactly where these projects go wrong from both sides of the table.
There has never been a better time to buy a small custom AI tool, and there has never been an easier time to waste money on one. The same technology boom that makes a genuinely useful tool buildable in days also produced a wave of vendors selling demos, dashboards, and "AI transformation" to businesses that needed something much smaller and much more specific.
The difference between the buyers who get value and the buyers who get burned is almost never technical knowledge. It is knowing what to ask for. This guide is the checklist I wish every buyer walked in with - six checks, in order, from before you contact anyone to after delivery.
First, the mindset shift: buy a task, not "AI"
Every burned budget I have seen started the same way: the project was defined by the technology instead of the task. "We want to use AI in our business" is not a project - it is a mood. It produces pilots that impress in the demo and die in the drawer, because nobody could ever say what the tool was for.
The buyers who win define the purchase in one sentence with no technology in it: "Every inquiry that comes in gets assessed the same way, in minutes instead of an hour." "First drafts of our project updates get written in our voice, ready for a human polish." "Every incoming brief gets checked for scope risk before we quote."
If you cannot write that sentence yet, you are not ready to buy - you are ready to observe. Spend one week noticing which task your team repeats most often that follows a pattern: same kind of input, same kind of judgment, same kind of output. That task is your first tool. Not five tasks. One. The second tool is easier to buy, cheaper to build, and better specified - after the first one works.
Check 1 - You can describe the task in inputs and outputs
Before contacting any vendor, write down three things:
- What goes in. An email, a document, a brief, a list, a recording - the raw material, as it actually arrives, mess included.
- What should come out. A score, a draft, a checklist, a structured summary, a recommendation - and what "good" looks like.
- Who does this today, and how long it takes them. This is your value baseline; it's how you'll judge both the price and the result.
If writing these three takes you under ten minutes, you have an excellent first project. If it takes days of internal debate, the task involves more hidden judgment than anyone realized - which is worth knowing before you've paid someone to discover it.
Check 2 - You have real examples ready
This is the single strongest predictor of a good outcome, and the most commonly skipped step. Gather two or three real examples of the task: actual inputs, and - if they exist - examples of what a good output looked like when a human did it well.
Real examples do three jobs: they force the tool to handle your actual mess instead of an idealized version; they give the builder a test set, so "it works" means "it works on your material" rather than "it worked in my demo"; and they surface the edge cases early, when they're a conversation instead of a change request.
Anonymize what's sensitive - names, amounts, clients. Realistic beats complete. A vendor who doesn't ask for examples is planning to test on you, in production, after payment.
Check 3 - The vendor has a method, not just a model
Here is the question that separates builders from prompt-resellers: "What happens inside the tool - what does it actually check, and in what order?"
A good answer sounds like a method: the tool reviews the input against a fixed set of criteria, in a fixed sequence, and returns the same structure every time, for anyone on your team. A bad answer sounds like magic: "the AI understands your needs" - which means someone typed a paragraph into a chatbot and put a logo on it.
The difference matters because consistency is the entire point of a tool. A blank AI chat can produce a brilliant answer today and a different answer tomorrow, depending on who asks and how. A tool with a method produces the same judgment every time - that is what makes it usable by your team, trainable against your examples, and improvable when it's wrong. Ask to see one example of the vendor's previous tools and its output structure. Builders are proud to show this; resellers change the subject.
Check 4 - Fixed scope, fixed price, and a number that makes sense
For a first tool, insist on fixed scope at a fixed price. Not because hourly is evil, but because a first AI project priced hourly has no natural end - and you don't yet know enough to manage the meter. Fixed scope forces the definition conversation up front, where it belongs. (For larger builds where the scope itself is the unknown, there's a fairer structure than a big fixed quote: the validation slice - a small paid first step, credited against the build.)
What the market roughly looks like for a well-scoped single-task tool: a few hundred to around two thousand dollars/euros, depending on whether it runs inside an existing AI platform (cheaper) or stands alone with its own interface and integrations (more). Calibrate against your Check-1 baseline: a tool that saves one person five hours a week pays for a mid-range build inside two months.
The pricing red flags, both directions: too big - the vendor answers your one-task request with a platform, a retainer, a "transformation roadmap," or a five-figure discovery phase; too vague - "we'll see how far the budget gets us"; and the subtle one, too smooth - a price quoted instantly, before they've asked you a single narrowing question. Someone who quotes without asking what's in your examples is quoting a template, not your task.
Check 5 - Delivery means your team can use it without the vendor
Agree before purchase on what "delivered" includes. The minimum honest package:
- The working tool, tested against the examples you provided in Check 2 - and shown working on them.
- Usage instructions your team can follow without training - if using the tool requires the vendor on a call, you bought a dependency, not a tool.
- At least one revision round, defined: what counts as "fix within scope" versus "new request".
- Clarity on where it runs and what your team needs (an account on some AI platform? a link? a login?) - and any running costs, stated up front.
And define success in your own words before delivery - one sentence, agreed with the vendor: "In 30 days, [person] uses this for [task] and it saves [rough time] with output we'd actually send." That sentence is your acceptance test. Vendors who welcome it are planning to meet it.
Check 6 - Ownership and data, in plain words
Two questions, both answerable in one sentence each; hesitation on either is a red flag:
"Is the tool mine, and is it private to us?" The right answer: yes - built for you, not published, not reused for other clients, yours to keep using.
"Where does my data go?" The right answer names it plainly: your examples are used to build and test the tool; when the tool runs, inputs go to [the AI platform it runs on] and nowhere else; nothing of yours is used to train anything or shared with anyone. If your task touches genuinely sensitive material - client contracts, personal data, financials - say so up front and let the vendor design for it (anonymization steps, data-handling constraints). A good builder treats this as a design input, not an objection.
The red-flag list, collected
Walk away, or at least slow down, when you see:
- The everything-answer: whatever you ask for, they can do, immediately, no narrowing questions.
- Demo-first selling: a slick generic demo instead of curiosity about your task.
- The platform upsell: your one-task request keeps growing in their replies.
- No examples requested: they don't want your real material before building.
- No method visible: can't explain what the tool checks or show previous output structure.
- Hourly-open-ended for a first project, or a price quoted before a single question.
- Vague data answers, or visible discomfort with "is this private to us?"
- No definition of done: "we'll keep tweaking until you're happy" sounds generous and means nothing.
And one green flag worth naming, because it looks like a red flag to eager buyers: the vendor who tells you a task is a bad fit. "That one involves too much judgment to automate well - this other task on your list is the better first tool" is the sound of someone protecting your budget. That's the person to buy from. (The Automation You Shouldn't Build is the same idea from the builder's side: the five requests a good builder turns down.)
The whole guide on one page
Buy a task, not "AI" - one task, defined in inputs and outputs, with a time baseline. Bring two or three real examples; they are your test set. Demand a method, not magic: the tool should check fixed things in a fixed order and produce the same structure every time. Fix the scope and the price; calibrate the price against the hours saved; distrust instant quotes and platform upsells. Delivery means your team runs it alone: instructions, a tested tool, a defined revision, running costs stated. Own the tool, know where the data goes, in plain sentences. And when a vendor tells you not to build something - listen carefully. You may have found the right one.