How to Brief a Web Developer When You Are Not Technical

Most web projects that go sideways do not fail in the build. They fail in the brief. The developer builds exactly what they heard. The client wanted something different. Nobody is lying. The information was never captured in the first place.

We have inherited enough rescue projects to see the pattern. Same budget range, same timelines, same stack. The ones that worked had clients who knew how to describe what they wanted. The ones that collapsed had clients who said "I just need a website" and expected the agency to fill in the rest.

You do not need to learn code to brief a developer well. You need to learn what information a developer actually needs to make good decisions on your behalf.

Why "I just need a website" guarantees a bad outcome

"I just need a website" is not a brief. It is an invitation for the developer to guess. A good developer will guess conservatively. They will build something generic, on a template, with assumptions that may or may not match your business. A less scrupulous developer will guess expensively. They will build features you never asked for and bill you for them.

Both outcomes are your fault, not theirs. You did not give them enough information to do better.

A website is not a product you buy off a shelf. It is a custom system that has to fit your business model, your customers, your operations, and your goals. The person who knows all of that is you. The person who knows how to translate it into code is the developer. The brief is where those two things meet.

The minimum information a good developer needs

Before you talk to a single agency, you should be able to answer these questions in writing. If you cannot, get clear on them first. The time you spend here saves months on the back end.

Business model. How do you make money? Who pays you, for what, and how often? A law firm converting leads over a six-week sales cycle needs a different site than a Shopify store converting impulse buys. If your developer does not understand how revenue enters your business, they cannot design a site that supports it. Target user. Who shows up on your site, and what are they trying to do? Be specific. "Small business owners" is not a user. "A restaurant owner in Chicago searching for a new POS system at 10pm after close" is a user. The more concrete your description, the better the decisions downstream. Conversion goals. What do you want visitors to do? Book a call. Buy a product. Request a quote. Download a guide. Call a phone number. Pick the primary action and the secondary action. Every page on your site should push toward one of them. Integrations. What other systems does your business already run on? CRM, email platform, accounting software, scheduling tool, POS, inventory system, payment processor. List every tool by name. Every integration you leave off the brief becomes a surprise later, and surprises are expensive. Content. Who is writing the words and taking the photos? If the answer is "the developer," you need to know that up front because it changes the price and the timeline significantly. If the answer is you, be honest about your capacity. Most projects stall in content, not code. Timeline. When do you need this live, and why? A real deadline tied to a real event (launch, season, trade show) is a useful constraint. An arbitrary date pulled out of nowhere is not. If you do not have a real deadline, say so. That is also useful information. Budget. Yes, share it. Developers get asked to quote blind all the time, and the result is either a sandbagged estimate to land the job or a wildly inflated one to protect against scope creep. A number, even a rough range, lets a good developer tell you honestly what you can and cannot get for that money.

How to describe design preferences without technical terms

You do not need to say "I want a minimalist design with a hero section and a CTA above the fold." You need to show examples and react to them.

Pick five websites you like. They do not have to be in your industry. For each one, write one sentence explaining what works for you. "This feels calm and trustworthy." "I like how the prices are right on the homepage." "The photos make the business look established." You are giving the developer raw material to reverse-engineer your taste.

Then pick three websites you hate. Same exercise. "This feels cluttered." "I cannot find their phone number." "The stock photos make it look fake." Negative examples are often more useful than positive ones because they surface the instincts you did not know you had.

Avoid words like "modern" and "clean" without examples attached. Those words mean different things to different people. A reference site pins down the meaning.

How to discuss functionality with examples

Same principle, different subject. Do not try to describe a feature in words. Point at a site that already does it and say "like this, but for my business."

"I want online booking like the way OpenTable handles it." "I want a project gallery like this architect's site, where you can filter by project type." "I want a service list like this competitor, where each service has its own detailed page." A competent developer can look at a working example and tell you immediately what it takes to build something similar.

This approach also surfaces disagreements early. If you point at a feature and the developer says "that takes six weeks and thirty thousand dollars," you know right away whether it fits your project or not. No one has to guess.

Common mistakes that kill projects

Vague scope. "A website with a few pages" is not a scope. A scope is a list of every page, every form, every integration, every interactive feature, by name. If it is not on the list, it is not in the project. Change the scope mid-build, and you either pay for the change or lose something else. Hidden integrations. "Oh, and we also use this scheduling tool, it should just plug in, right?" No. It probably will not "just plug in." Every third-party tool has its own API, its own quirks, its own limits. Surface every integration on day one. No decision maker. If three cofounders all have opinions and no one has final authority, the project dies in committee. Pick one person to own the decisions. Everyone else gives input, but the owner signs off. Moving goalposts. "Can we also add a blog?" "Can we also add a members area?" "Can we also add multi-language support?" These are not small additions. They are entire features. Each one extends the timeline and the budget. A good developer will push back. Let them. Reviewing at the end instead of along the way. If you see the site for the first time at launch, it is too late to change anything without starting over. Ask for checkpoints every one to two weeks. Review them seriously. Give feedback in writing. Ghosting the developer. They send content requests and you do not respond. They send a draft and it sits in your inbox for three weeks. The project does not pause gracefully when you go silent. It breaks.

A simple brief template you can copy

Paste this into a doc, fill it in, and hand it to any developer or agency you are considering.

Business summary What your business does, who pays you, and how. Primary goal for the website The single most important thing this site needs to do. Secondary goals Other actions that matter, in order of priority. Target users Describe two or three specific people who will use the site. Pages required List every page by name. Features required List every interactive element (forms, booking, search, login, etc). Integrations required List every third-party tool by name. Content status Who is writing and sourcing images, and when will it be ready. Design references Five sites you like, one sentence each on why. Design anti-references Three sites you dislike, one sentence each on why. Timeline Target launch date and the reason behind it. Budget Your range. Be honest. Decision maker One name. One email. One phone number. Current site (if any) URL and what is wrong with it. Anything else a developer should know Compliance requirements, accessibility standards, multi-language needs, known constraints.

What changes when you brief well

A good brief does not guarantee a good project. It does three things that give you a fighting chance.

It filters out bad developers. Anyone who skims your brief and comes back with a generic proposal is telling you they do not read carefully. Pass.

It lets good developers price accurately. The proposal you get back reflects your actual project, not an average of every project they have ever quoted.

It gives you a reference point when things get confusing mid-build. If a request falls outside the brief, everyone knows. If it falls inside, everyone knows that too. Arguments get shorter. Decisions get faster.

You are not being asked to become technical. You are being asked to be specific about your own business. That is the one part of the project only you can do. Get that right, and the rest is the developer's problem to solve.