What an AI brief actually costs you | How to create a proper AI website brief for your web developer
Twenty pages of generated requirements will not get you a better website. It will get you a slower, more expensive and less accurate quote. Here is why, and how to use AI properly when you brief a developer.
A photo booth startup in Cape Town sent New Perspective Design a twenty-page brief. It was thorough, well organised and written in confident, professional language.
It asked for a custom quotation builder, a full booking system with add-ons, online deposit and balance payments, a secure customer portal with artwork approval workflow, a business administration dashboard, calendar management, automated invoicing, WhatsApp notifications and integration with the physical booth software.
Their budget was R10,000.
That system, built properly, is around R30,000. Building it with AI-assisted tooling rather than from scratch still starts near R45,000, because the complexity is in the logic and the testing, not the typing.
Nobody was being unreasonable. They had no way of knowing. They asked a chatbot what to ask a web developer, and the chatbot gave them everything, because that is what it does when nobody tells it to stop.
This happens now most weeks. It is worth explaining what it costs, because it is not what people expect.
It makes your quote go up, not down
This is the part that surprises people. A longer, more detailed brief feels like it should make quoting easier. It does the opposite.
Nothing is prioritised
A generated brief lists sixty features and treats all sixty as requirements. There is no phase one, no nice-to-have, no “this can wait until we have revenue”. The model has no reason to prioritise because it has no budget, no deadline and no stake in the outcome.
So the developer either quotes the whole thing, which produces a number that ends the conversation, or spends hours working out what you probably actually meant. That time goes into the price.
Risk gets priced in
When a brief is ambiguous, a developer has two choices. Ask forty clarifying questions, or pad the quote to cover the interpretations that turn out to be wrong.
Most quote defensively, because the alternative is discovering three weeks in that “customer portal” meant something far larger than they assumed. You pay for that uncertainty whether or not it materialises.
You have asked for a roadmap for free
A quote request that says “tell us your recommended platform, your technology, your timeline, your milestones, your recommended payment gateway and its fee structure” is not a quote request. It is a request for a scoping document.
That is genuine consulting work. Several hours of it. Agencies that do it free recover the cost somewhere, usually in the build price. Agencies that do not do it free will either decline or charge for discovery.
It breaks the conversation
This is the real damage. A twenty-page document arriving cold replaces the call where a developer would have asked what the business actually needs. It looks like the brief has already answered those questions, so nobody asks them.
The project then gets built against the document rather than against the goal, and the features are wrong in ways nobody notices until launch.
The thing these briefs always leave out
The photo booth brief had a section headed customer journey. It listed thirty-odd features across the portal and the admin dashboard.
Here is what it never once said:
Customer books a package online and pays a deposit
We photograph their event
We upload the photographs
They log in, view their gallery and download their images
Four lines. That is the business. Everything else in twenty pages is decoration on top of those four steps.
With those four lines, a developer can tell you within an hour what is straightforward, what is expensive, what could be handled by an existing tool for R200 a month, and what should wait until phase two.
Without them, there is a feature list and no way to judge what matters. A model generating a brief produces features because features are what briefs contain. It cannot describe your customer journey, because you never told it what your customers actually do.
A brief that lists sixty features but cannot describe four steps has told the developer nothing.
The clauses that cannot be agreed to
Generated briefs pull standard commercial language from enterprise procurement templates. Most of it does not apply to a small website project, and some of it is impossible.
“We will own the source code”
You own your content, your design, your data, your domain and your customer information. All of that is yours outright and should be written into the agreement.
You cannot own the source code of WordPress, WooCommerce, a payment gateway SDK or a PHP framework. Nobody can. That code is licensed, usually open source, and it makes up the overwhelming majority of what is running your site. What is genuinely custom is yours. The framework beneath it is not anyone’s to hand over.
Exclusivity
Briefs sometimes ask that the developer never build anything similar for anyone else. No agency will agree to that, and you should be suspicious of one that does.
A web developer who has built ten booking systems is exactly who you want building yours. Asking them to never build another is asking them to stop being useful to the next client, and to stop getting better at the thing you hired them for.
“Warranty period after launch”
Reasonable in spirit, wrong in framing. Genuine defects get fixed free, and any decent developer will say so without being asked.
But a website is not an appliance. It sits on a server, connected to a payment gateway, running software that updates every few weeks, exposed to the open internet. It needs maintenance, not warranty. Asking for a twelve-month warranty on something that requires monthly attention is asking for the wrong product. That is what a managed WordPress hosting plan is for.
And sometimes it sends the code too
Briefs are one thing. Increasingly the brief arrives with a specification attached, or the client has already had a developer build from generated output and wants it finished.
Here is a real example. A CV submission form for a recruitment site, supplied as a JSON specification. Candidate name, email, phone, town, job category, CV upload. It looked like this:
{
“formId”: “localCvSubmission”,
“action”: “/submit-local-cv”,
“routing”: { “email”: “[email protected]” },
“fields”: [
{ “id”: “fullName”, “type”: “text”, “required”: true,
“validation”: { “minLength”: 2, “maxLength”: 150 } },
{ “id”: “emailAddress”, “type”: “email”, “required”: true },
{ “id”: “cvUpload”, “type”: “file”, “required”: true }
]
}
It is tidy. It is well structured. It has field IDs, validation rules and regex patterns. To anyone who is not a developer it reads as thorough and professional.
Built exactly as written, it would take the site down or leak every CV submitted to it.
What is missing
The validation is decorative
Every rule in that specification runs in the visitor’s browser. Browser validation is a convenience for honest users, not a security control. Anyone can bypass it in seconds because the request can simply be sent directly to the server instead of through the form.
There is no mention anywhere of validating the same data again on the server, which is the only place validation actually counts.
The file upload has no restrictions at all
No permitted file types. No maximum file size. No check that the file is what it claims to be.
Without a type restriction, the upload accepts executable files, not just documents. Without a size limit, a single upload can consume the server’s disk or memory. Neither of those is an exotic attack. Both are the first two things anyone testing a form will try.
Nowhere does it say where the files go
If uploaded CVs land in a publicly readable directory, and by default they often do, every CV on that site is reachable by anyone who can guess or discover the URL.
A CV contains a full name, contact details, employment history and frequently an identity number. That is exactly the category of personal information POPIA exists to protect, and the site owner carries that responsibility, not the person who generated the specification. Where a site is hosted and how it is configured matters here, which is part of why New Perspective Design hosts the sites it builds .
There is no protection against automated abuse
No rate limiting, no spam protection, no request verification. A form like this can be submitted thousands of times in minutes by a script, which fills the recipient’s inbox, fills the server’s storage, and buries the genuine applications.
The destination email address sits in the specification
Where the submission goes is a server-side decision. It should never appear in anything the browser can see, and it should certainly never be something the submitted data can influence.
There is no retention policy
How long are CVs kept. Who can access them. How does a candidate request deletion. What happens when the recruiter leaves the company. None of that is a technical question, and none of it appears, because the model was asked for a form rather than for a lawful way to handle personal information.
None of this is a criticism of the tool. It was asked to describe a form and it described a form accurately. Nobody asked it about server-side validation, upload restrictions, storage location, rate limiting or data retention, so it did not volunteer them.
That is the whole problem in one example. The output looks like engineering. It has the shape and the vocabulary of a specification. What it describes is how the form appears, not how it behaves under load or under attack.
A client cannot tell the difference between a specification and something that looks like one. That is not their job. It is the reason you hire someone.
Sent to a cheap developer who builds exactly what was asked for, that form goes live. It works fine for a month. Then it either falls over or quietly leaks candidate data for a year before anyone notices.
Fixing it afterwards costs more than building it correctly would have.
And then the same thing happens to your copy
The brief is usually not the only generated document. The website copy often arrives the same way, and it has the same problem in a place that matters more.
Generated website copy has recognisable fingerprints. The same sentence rhythms. The same words: seamless, robust, elevate, empower, leverage, unlock, delve. The same three-part lists. The same confident emptiness where a specific fact should be.
Three things go wrong:
- It does not sound like you. Your brand voice is one of the few things a competitor cannot copy, and it is built the same way the rest of a website is designed , deliberately. Generated copy has no voice, and your visitors can tell even if they cannot say why.
- It says nothing Google has not already indexed. Search engines reward pages that contain information not available elsewhere. A page assembled from the average of every page on the topic contains nothing new by definition, which is a problem for your SEO before it is a problem for your readers.
- It buries the things that would actually sell. The real reasons someone should buy from you are specific, and specifics are exactly what a model does not have. It does not know you have been doing this eleven years, or that you keep the stock in Cape Town, or that you answer WhatsApp on a Sunday. Those specifics are also what gets a page cited in AI search results rather than ignored.
How to write an AI brief for a web developer, properly
None of this is an argument against using AI. New Perspective Design uses it every day. The problem is not the tool, it is using it without a plan behind it.
Think of it this way. An electrician uses AI to help draft a schematic. That works, because the electrician already knows what the building needs, what the regulations require and when the output is wrong. A carpenter asking the same tool to wire a house and then following the instructions is a different situation entirely, and the difference is not the tool.
If you want to use AI to help you brief a website project, here is how to do it so it helps rather than hurts.
Start with the flow, not the features
Before you open a chatbot, write down what happens between a customer finding you and a customer being happy. In plain language, in under ten steps, the way you would explain it to a friend.
That document is worth more than twenty pages of requirements. Give it to the AI as your starting point rather than asking the AI to invent one.
Give it your budget and make it prioritise
A model will happily generate a R500,000 feature list for a R30,000 project because nobody told it not to. Tell it your budget, tell it your launch date, and ask it explicitly to split everything into phase one, phase two and not now.
Then ask it which items it thinks are unrealistic at that budget. It will usually tell you, if you ask.
Ask it to challenge you, not agree with you
Left alone, these tools agree. Ask directly: what am I missing, what in this is going to be expensive and why, what would you cut, what have I not thought about. That is where the useful output lives.
Cut it down before you send it
If the output runs to twenty pages, it is not ready. Get it to two. A developer reading two focused pages will give you a more accurate quote than one reading twenty unfocused ones.
If you cannot cut it down, that is a signal you have not decided yet. Which is fine, but it means the next step is a conversation, not a document.
Never send generated copy as final copy
Use it to get unstuck. Use it to organise your thoughts. Then rewrite it in your own words, or brief a copywriter properly. The words on your website are the part that has to sound like a person.
Talk to the developer first
Twenty minutes on a call will change the brief more than twenty pages of generated requirements. The developer knows which parts are expensive, which are solved problems and which are being asked for by mistake. That conversation is free and it is the highest-value thing in the whole process.
A prompt you can copy
If you want to use AI to help structure your thinking, use something closer to this. It forces prioritisation and it stops the model inventing scope.
I am briefing a web developer. Help me write a short, realistic brief, no longer than two pages.
My business is [what you do, in one sentence].
My budget is [amount].
I want to launch by [date].
Here is what happens between a customer finding us and a customer being happy:
[your steps, in plain language]
Here is what my current website or process cannot do:
[the actual problem you are solving]
Do not invent features I have not described. Split everything into phase one and later. Tell me which items are likely to be expensive and why. Tell me what I have not thought about. Ask me questions before you write anything.
That last line changes the output more than anything else in the prompt.
How New Perspective Design handles it
A brief arriving cold gets a phone call, not a quote.
The call is short. What does the business do, what does the website need to achieve, what is the budget range, what is driving the deadline. Fifteen or twenty minutes, usually enough to establish whether a project is straightforward or genuinely complex.
After that, one of two things happens.
If the project is clear, New Perspective Design quotes it. If it is not, New Perspective Design sends a structured intake form covering the things a quote actually depends on. That form can be filled in with AI assistance, and it works well that way, because the questions keep the model anchored to the real project instead of letting it generate scope from nothing.
That is the whole distinction. New Perspective Design works with AI constantly, across development, content and research. The difference is knowing what to ask it, where it conflicts with itself, when it is padding, and when the output is confidently wrong. That judgement comes from having built the thing before, across a decade of client work .
If you take one thing from this
The photo booth founders were not doing anything wrong. They wanted to be thorough and they used the tool available to them. The brief was genuinely well organised.
It just could not tell New Perspective Design the four things that mattered, because nobody had told it what the business does.
Write those four lines yourself. Send them with a budget and a date. That is a better brief than twenty generated pages, and it will get you a faster, more accurate and usually cheaper quote.
Send the four lines. Skip the twenty pages.
New Perspective Design builds custom websites and ecommerce stores for South African businesses. Start with a conversation and a realistic scope, not a generated requirements document.
