Briefing a developer properly – turning “make it look modern” into something they can build from

Briefing a web developer well is the single biggest thing you can do to get a website that works for your business. Plenty of business owners approach a developer with something like make it look modern, and nothing else, that phrase means nothing on its own. It could mean a minimalist redesign, a completely different colour scheme, or just newer fonts. Without more detail, the developer is left guessing, and guessing rarely produces the result you had in mind.

A good brief does not need to be a technical document. It needs to answer a handful of specific questions clearly enough that a developer can price the work, plan it properly, and build something that matches what you meant.

Why Make It Look Modern Is Not a Brief

Modern is subjective. One person’s modern is bold colour and big typography. Another person’s modern is white space and restraint. Neither is wrong, but a developer working from that single word has no way of knowing which one you mean.

A brief needs to translate feeling into specifics: which pages matter most, what a visitor should do once they land, and what success looks like once the site is live.

The same problem applies to phrases like clean, professional, and eye-catching. They describe a feeling, not a set of decisions. In other words, a brief needs to translate feeling into specifics. Which pages matter most, what a visitor should do once they land, and what success looks like once the site is live.

What a Web Developer Needs From You

Start With the Business Problem

Before any conversation about design, explain what the website is failing to do right now. Are enquiries too low? Is the site embarrassing to send people to? Does it fail to reflect the standard of work you deliver? A developer who understands the underlying problem can make better decisions throughout the project, not just at the design stage.

Content and Structure

List the pages you need and roughly what each one should contain. You do not need finished copy at this stage. Instead, a developer just needs to know if you are planning five pages or fifty, whether you need a blog, and whether visitors need to find specific services quickly.

Functionality and Integrations

Be specific about anything beyond a standard page. For example, booking systems, CRM connections, membership areas, and custom forms all change the scope and the price significantly. Mentioning these early avoids a quote that has to be revised halfway through a project.

Examples of What You Like, and Why

Sending three or four reference websites is useful, but only if you explain what you like about each one. Is it the layout, the photography, the navigation, or the tone of the copy? A link with no explanation leaves a developer to guess which element mattered to you.

Questions Worth Answering Before You Approach a Developer

A handful of questions, answered honestly, make the rest of the conversation much easier. What is the website currently failing to do? Who is the ideal visitor, and what do they need to find quickly? Is there a realistic budget range in mind? What’s the timeline, and is there a fixed deadline behind it? And what content do you already have versus what still needs creating?

None of these require technical knowledge. They require you to think about the business problem before you think about the visual one.

What a Good Developer Will Ask You

A brief does not need to be perfect before you send it. Part of a developer’s job is asking the questions you have not thought of yet. How visitors currently find you, what happens after someone submits a contact form, and whether the site needs to grow with the business over the next few years. Treat the first conversation as a two-way process rather than a test you need to pass alone.

What Happens When You Skip This Step

Vague briefs lead to vague proposals, and in turn, to the “I thought this included…” conversation partway through a project. Scope creep, missed expectations, and drawn-out revision rounds are almost always traced back to a brief that never properly defined what modern, professional, or clean meant in practice.

A proper discovery process at the start of a project exists to close that gap. I have written more about what that stage looks like, and why it matters so much to the overall cost of a build, in the Small Business Website Investment Guide.

Briefing a Web Developer Does Not Mean Writing a Spec

The businesses that get the best results from a web project are rarely the ones with the most polished brief.

None of this means you need to produce a technical document before you pick up the phone. A good developer will ask the right questions and help shape a vague idea into something buildable. What you owe them, and yourself, is honesty about the business problem, clarity about the must-haves, and reference material so that modern stops being a guess.

The businesses that get the best results from a web project are rarely the ones with the most polished brief. They are the ones who have thought properly about what the website needs to do before the first conversation happens.

If you’re weighing up a web project and want to talk through what the website needs to do before you commit to anything, that’s exactly the conversation I like having. No pressure, just an honest look at whether kupu is the right fit to build it.

Get in touch: enquiries@kupu.co.uk or connect on LinkedIn.