How to Brief a Website or Automation Project That Starts Well
A clear project brief cuts the back-and-forth before work begins, produces a more accurate quote and reduces the chance of scope creep once development is underway. The brief does not need to be a formal document — a short, honest description of what you need, what you already have and what success looks like is enough to get a useful reply within 24–48 hours.
Why the Brief Matters More Than the Budget
Most projects that run over time or over budget do so because the scope was unclear at the start, not because the budget was too small. When a studio cannot see the full picture, it quotes for the most likely interpretation — which may not match yours. Every discovery call that could have been avoided with a written brief costs both sides time before a single line of work begins.
A good brief also protects you. Once scope is agreed in writing, you have a reference point if priorities shift mid-project. Anything added later is a change, not a surprise charge.
The Eight Things Every Brief Should Cover
You do not need every answer immediately, but the closer you get to all eight, the faster the studio can respond with something useful.
| Item | What to include | Why it matters |
|---|---|---|
| 1. The goal | What the finished project must do, in one sentence | Anchors every other decision |
| 2. What you already have | Existing domain, hosting, WordPress install, plugins, design files | Determines whether this is a build, a rescue or an upgrade |
| 3. The audience | Who buys from you, what languages they speak, where they are | Affects translation scope, shipping, payment methods, legal requirements |
| 4. Integrations needed | Payment gateways, couriers, CRM, ERP, marketing tools, any existing APIs | Often the largest share of build time and ongoing API cost |
| 5. Content | Who writes copy, provides images, supplies product data | Missing content is the most common cause of a delayed launch |
| 6. Scale | Rough number of products, languages, order volume per month | Determines hosting tier, automation design, plugin choice |
| 7. Deadlines | Any fixed dates and why they are fixed | A deadline without a reason is usually flexible; one with a reason is not |
| 8. What you will manage yourself | Tasks you will handle after launch: orders, content, stock updates | Affects whether the system needs an admin interface or can run fully automated |
Briefing an Automation Specifically
Automations need a slightly different kind of brief from a website build. The most useful thing you can describe is the manual task you want to eliminate — not the technology you think should solve it. Walk through the task step by step as a human does it today: what triggers it, what data it touches, what the output looks like and where it goes.
Then note the failure modes. What should happen when a supplier API times out? What if the data is incomplete? Who should be notified when something goes wrong? These questions seem small before a project starts and become urgent the first time the automation runs at two in the morning and nobody is watching.
It also helps to separate the must-haves from the nice-to-haves. An automation that sends an instant order alert with product, stock level, payment method and traffic source is a must-have. Auto-formatting the message with emoji might be a nice-to-have. Separating them keeps the first version lean and the quote accurate. If you are unsure where to start, the article on which task a small store should automate first gives a practical framework.
What You Do Not Need to Know Before You Write a Brief
You do not need to specify the technology stack, the plugin names, the hosting provider or the exact automation tool. That is the studio’s job. Trying to specify those things before you understand the full scope often locks in choices that become problems later — a plugin that does not support your language, a hosting tier too small for your traffic, an automation tool with rate limits that break under load.
What you do need is clarity on the business outcome. “I want every new WooCommerce order to send me a Telegram message with the order total, the product name and the remaining stock” is a brief. “I want to use Make.com with a webhook and a Telegram bot module” is a technology choice that may or may not be the best fit once someone looks at the full picture.
Similarly, you do not need a finished design before briefing a project. A reference site — something whose layout or tone you like — is more useful than a mock-up made in a tool the developer cannot open.
Common Briefing Mistakes and How to Avoid Them
- Describing the solution instead of the problem. Tell the studio what is broken or slow in your business today. Let them propose how to fix it.
- Leaving integrations until after the quote. A WooCommerce store that also needs a live DPD shipping rate, a Stripe checkout and a CRM sync costs significantly more to build than the same store without those connections. All integrations belong in the first brief.
- Not mentioning legal obligations. If you sell to customers in the EU, your project scope includes GDPR-compliant cookie consent, real script blocking and a consent record — not as an optional add-on but as a legal requirement. Discovering this after the site is built means rework. Projects that handle personal data or use AI-generated content visible to users may also have EU AI Act transparency obligations.
- Assuming “a website” means a finished website. A domain, a WordPress install and a theme are not a website. A website is a system with hosting, security, speed, SEO structure, payment connections and content. Be specific about what done looks like for you.
- Skipping the question of who maintains it. A site with a fully automated content pipeline needs different admin tooling than a site a human updates weekly. The fully automated content website architecture is a different project from a standard managed WordPress site — your brief should say which you want.
How We Run This in Our Own Projects
At Supreme Commerce, every project starts with a written scope agreed before any work begins. The systems we offer clients are the same ones we run in our own businesses, so the brief questions we ask are the same ones we answered ourselves when we built those systems. When we built GiantParts.eu, for example, the scope covered ten languages, live DPD and DHL rates at checkout, an AI part finder, automated order alerts, a daily business report and a Stock Guard integration — each of those was a line in the original scope, not a surprise added after launch.
That discipline is why the projects run reliably. Anything not in the agreed scope is a separate conversation. It keeps both sides honest and keeps the timeline predictable.
FAQ
How long should a project brief be?
One to two pages of plain text, or a short form submission, is enough for most projects. The goal is to give the studio enough to understand your business outcome and the integrations involved — not to write a technical specification. If you are unsure what to include, describe the problem in plain language and let the studio ask follow-up questions.
What if I do not know my exact requirements yet?
That is a normal starting point. Write down what you do know — your goal, your audience, what you already have and what must be working on launch day — and flag the open questions explicitly. A studio can often help you decide the unknowns once it understands the context, but it needs the knowns first.
Should I get quotes from multiple studios before writing a brief?
Writing the brief first is almost always better. A brief forces you to clarify your own requirements, which makes every quote more comparable. Studios quoting against different assumptions produce numbers that cannot be meaningfully compared, and the cheapest quote is usually the one that understood the least.
How much detail do integrations need in the brief?
Name the systems you use — payment gateway, courier, CRM, ERP, marketing platform — and whether each one has a documented API. If you are unsure, say so. The important thing is not to omit an integration because you assume it is simple. Live shipping rate calculations, real-time stock syncs and payment gateway connections each add meaningful scope whether they appear in the brief or not.
Where to Go Next
If you are ready to describe your project, the fastest way to start is the quote form at Supreme Commerce — send a short description and expect a reply within 24–48 hours. If you want to see the kinds of automation systems a finished brief can produce, the AI automation page shows every live system the studio builds and runs. When you are ready, request a project quote and the studio will reply within 24–48 hours.
