How to Spec a Custom AI System for Your Business

I read custom AI briefs every week. Most of them can’t be quoted. Not because the ideas are bad — because the brief describes an ambition (“we want to automate customer service with AI”) rather than a system. A developer can’t price an ambition. So you either get no number, a padded number, or a confident number from someone who didn’t read carefully. All three waste your time.

The fix is a spec. Not a requirements document, not a workshop series — one page that answers six questions. Every custom AI system I’ve shipped, from a WhatsApp support agent to a full operations platform, reduces to the same six decisions. Answer them and any competent developer can give you a real price and a real timeline.

This post walks through each decision. If you’d rather answer them interactively, use the interactive builder to assemble your spec in three minutes — it mirrors this exact framework and sends me the result, and I reply with a written quote.

Why most custom AI briefs fail

Three patterns account for nearly all of the unquotable briefs I see:

1. The outcome brief. “We want to save 20 hours a week with AI.” That’s a goal, not a system. Twenty hours saved doing what, on which channel, touching which software? The same goal could be a two-week build or a four-month one.
2. The tool brief. “We want a chatbot like ChatGPT but for our business.” This names a product instead of describing the job. It skips the questions that actually drive cost: what the bot must look up, what it’s allowed to do, and who supervises it.
3. The kitchen-sink brief. Twelve use cases, every department, no priority order. Nobody can phase or price it, so nobody does.

All three fail the same way: they leave the six defining decisions unmade, so the developer has to guess. Guesses become padding, padding becomes a quote you don’t trust, and the project stalls before it starts.

The six decisions that define an AI system

When you build your own AI system — whether you write the code or hire someone like me — these six decisions are the architecture. Everything else is implementation detail.

1. Channels: how does work enter the system?

Every AI system has a front door. WhatsApp, email, your website, phone calls, Slack or Teams, an internal dashboard — or several at once. List them, and mark which is primary.

This matters because each channel is real engineering with its own rules. WhatsApp Business has template approval and session windows. Voice needs speech handling and latency budgets. Email needs threading and tone control. “All channels eventually” is fine — but the spec should say which one ships first.

2. Platforms: what must it read from and write to?

Name every system the AI touches: your CRM, accounting software, calendar, e-commerce platform, ticketing tool, internal databases, spreadsheets. For each one, note whether the AI only reads (looks up an order) or also writes (creates an invoice, updates a deal).

Integrations are usually the biggest cost driver in a custom build — more than the AI itself. A brief that says “connects to our systems” hides the number. A brief that says “reads from HubSpot and Shopify, writes to Xero” reveals it. Write access always costs more than read access, because it needs guardrails, logging, and undo paths.

3. Autonomy: what runs without a human?

This is the decision most briefs skip entirely, and it’s the one that separates a demo from a production system. Draw the line explicitly:

• Fully autonomous: the AI acts and nobody reviews it. Answering FAQ-grade questions, routing tickets, sending appointment reminders.
• Human-approved: the AI drafts, a person clicks send. Quotes, refunds, anything with money or legal weight.
• Human-only: the AI stays out. Complaints from your biggest client, HR matters.

Start conservative. Every system I’ve shipped moves items from “human-approved” to “autonomous” over the first months as trust builds. The spec just needs the day-one line.

4. Users: who works with it, and what are they allowed to do?

Is this customer-facing, internal to one team, or company-wide? How many people, roughly? Does everyone see everything, or do sales and finance need different views?

User count and roles decide whether you need login, permissions, and an admin panel — the difference between a bot and a platform. A five-person team sharing one view is a small build. Forty users across three departments with role-based access is a different project, and the spec should say so up front.

5. Hosting: where does it live?

Three realistic options: managed cloud (your developer hosts and maintains it), your own cloud account (AWS, Google Cloud, Azure — you hold the keys), or on-premise (your hardware, usually for compliance).

For most 10–500 person companies, managed cloud is the right default — fastest to ship, cheapest to run. Choose your own cloud when data residency, an existing security policy, or a compliance framework demands it. Choose on-premise only when a regulator or a contract forces your hand. Whichever you pick, the spec should name it, because it changes both build effort and monthly running cost.

6. Training and adoption: who runs this after launch?

The least glamorous decision and the best predictor of whether the system earns its keep. Answer three things: who on your team owns the system internally, who needs training to use it, and what handover you expect — documentation, recorded walkthroughs, live sessions, a support period.

AI systems fail in month three, not week one. They fail when the one person who understood them leaves, or when the team quietly reverts to the old way. Naming an internal owner in the spec costs nothing and roughly doubles the odds the system is still running a year later.

How to write the one-page spec

Take your six answers and write them down in this order. Plain English, no diagrams required:

THE JOB (one sentence)
What the system does, for whom, and what success looks like.

CHANNELS
Where work enters. Primary channel first.

PLATFORMS
Every system touched. Mark each: read / write.

AUTONOMY
What runs alone. What needs approval. What stays human.

USERS
Who uses it, how many, what roles.

HOSTING
Managed cloud / own cloud / on-premise — and why.

ADOPTION
Internal owner by name. Training needed. Handover expected.

OUT OF SCOPE (optional but powerful)
Two or three things the system explicitly will NOT do in v1.

The “out of scope” section is the mark of a buyer who knows what they’re doing. Writing “v1 does not handle refunds” kills scope creep before it starts and tells the developer you’ll be easy to build for. Easy clients get sharper prices.

A spec like this takes 30–45 minutes to write from scratch. If you want it faster, the interactive builder on this site asks the same six questions with clickable options, draws the system map live as you answer, and produces the spec at the end.

What a good written quote looks like

Once your spec is in a developer’s hands, the response tells you almost everything about who you’re dealing with. A serious quote has four properties:

1. Fixed price. A one-page spec is enough information to commit to a number. If the answer is a day rate and a shrug, the developer is transferring their estimation risk onto you. Hourly billing on a scoped build means you pay for every wrong turn.
2. Milestones you can see. The build should be broken into stages with something demonstrable at each — a working channel connection, the first integration live, the approval flow in front of real users. Payments tied to milestones, not calendar dates.
3. You own the code. Full stop. The repository, the prompts, the infrastructure configuration — handed over, in your accounts or transferable to them. If a vendor’s pricing only works because you can never leave, that’s not a build, it’s a subscription wearing a build’s clothes.
4. It answers your spec, point by point. A quote that restates your six decisions back to you — these channels, these integrations, this autonomy line, this hosting — proves the developer read it. A quote that could have been sent to anyone probably was.

For what the numbers themselves tend to look like across the market, the cost estimator gives you a realistic range in three questions — useful for sanity-checking any quote that lands in your inbox.

Spec first, shop second

The order matters. Companies that collect quotes before writing a spec get numbers that aren’t comparable — each vendor quietly quoted a different imaginary project. Companies that spec first can put three quotes side by side and see who’s sharp, who’s padded, and who didn’t read.

So: make the six decisions, write the page, then start conversations. If you want the fast path, build your own AI system spec with the interactive builder — pick your channels, platforms, automations, users and hosting, watch the system map assemble, and I’ll come back to you with a written, fixed-price quote against exactly what you specified. No call required to get the number.

Related reading

• How to Estimate Cost & Time to Build a Custom AI — the pricing framework that pairs with this spec
• Questions to ask before hiring an AI developer — vetting the people who answer your spec
• How custom AI development actually works — the six-stage methodology after the spec is signed
• Why AI projects fail — the month-three failure modes a good spec prevents