Introduction
Most business owners don’t build websites every day. They might do it once every 5–7 years. Developers, on the other hand, live inside website projects all day, every day.
That gap in experience is where a lot of stress, delays, and unexpected costs come from.
As a web developer who works with small and medium businesses, I see the same patterns over and over again: great businesses with good intentions, but unclear goals, missing content, and fuzzy expectations about what’s actually involved.
This article is the conversation I wish I could have with every client before we start. If you’re planning a new website or redesign, these are the things your developer secretly hopes you understand.
1. “What does success look like?” is the first (and most important) question
Most briefs start with: “We need a modern website” or “Our current site is outdated.”
That’s not a goal. It’s a description.
Before you talk colours, pages, or platforms, answer:
- Why are you doing this now?
- What would make this project a success in 6–12 months?
- How will you measure that success?
Examples of clear goals:
- “Increase online enquiries by 30% within 12 months.”
- “Get at least 20 sign-ups per month for our intro course.”
- “Make it easy for customers to book jobs online instead of calling.”
Once we know the real goal, we can make smarter decisions about:
- What pages we actually need (and which we don’t).
- What calls-to-action go on key pages.
- Whether we prioritise speed, SEO, ecommerce, or something else.
What you can prepare:
- 2–3 sentences on what success looks like.
- Any current data (analytics, enquiries, sales) if you have it.
- A shortlist of competitors or sites you like, with a note on why.
2. Content is almost always the biggest bottleneck
From a developer’s perspective, “we’re waiting on content” is the number one reason projects stall.
A website is really:
Structure (developer) + design (designer) + content (you).
If copy, photos, and assets arrive late or in pieces, everything slows down and small changes start compounding.
What your developer wishes you knew:
- We don’t need Shakespeare, but we do need something to work with.
- Good photos and clear copy will do more for your website than any clever animation.
- If you don’t have time to write, it’s often cheaper and faster to pay a copywriter than to drag the project out for weeks.
What to prepare before the build starts:
- A simple page list (e.g. Home, About, Services, Pricing, FAQ, Contact).
- Bullet-point copy for each page (a writer can polish later).
- Logo files (SVG/PNG), brand colours, fonts, any existing guidelines.
- A folder of usable photos (or at least a plan for a photographer/stock).
If you’re not sure where to start, I provide clients with a basic content worksheet they can fill in page by page. You can download a version of that worksheet here: [Project Brief Template].
3. Wireframes and prototypes save time (and money), even if they look “ugly”
When clients see an early wireframe, the reaction is often: “This looks really plain, where’s the design?”
But wireframes and low-fidelity prototypes are where we:
- Decide what goes on each page.
- Agree on layout, hierarchy, and user journeys.
- Catch missing pieces before they become expensive to change.
Changing the position of a section in a wireframe is a 30-second job. Changing it after everything is built, styled, and integrated with a CMS can mean hours of rework.
What your developer wishes you knew:
- The “ugly grey boxes stage” is where the most important decisions happen.
- Giving clear feedback at this stage will save you rounds of pixel-pushing later.
- It’s much better to argue about layout before anyone writes complex code.
How you can help:
When reviewing a wireframe or prototype, focus on:
- Does this page tell the right story for this audience?
- Is it clear what we want the user to do next?
- Is anything important missing or in the wrong place?
Don’t worry about colours or fonts yet that comes next.
4. Clear feedback and realistic timelines keep everyone sane
Web projects don’t usually go wrong because of one big disaster. They drift because of lots of small delays:
- Feedback arriving a week late.
- Stakeholders changing their minds after sign-off.
- “One more small change” added ten times.
From a developer’s side, we’re often juggling several projects and scheduling work in blocks. When feedback or approvals slip, it can knock the whole schedule out, which is where surprises on timeline and cost appear.
What your developer wishes you knew:
- “This week” feedback is very different from “today.”
- 5 rounds of tiny changes can be more expensive than 1 round of thoughtful, consolidated feedback.
- It’s okay if you need more time, but tell us early so we can plan around it.
Practical tips that help a lot:
- Nominate a single point of contact on your side.
- Agree rough milestones upfront:
- Content delivery
- Wireframe sign-off
- Design sign-off
- Development start
- Testing & launch
- Batch your feedback: one clear list per round, not lots of scattered emails and messages.
5. Not everything has to ship in version 1.0
Clients often arrive with a long wish-list:
- Blog
- Booking system
- Complex forms
- Member login
- Custom dashboards
- Multi-language
- Integrations with five tools
Sometimes all of that makes sense, but not always for launch.
Trying to squeeze everything into version 1 usually means:
- Longer timelines
- Higher upfront cost
- More things that can break
Most successful products and websites started with a smaller core and added features over time.
What your developer wishes you knew:
- It’s completely normal (and smart) to launch a simpler version first.
- You don’t have to abandon ideas; we can plan them as Phase 2 or 3.
- Cleaner scope leads to better quality and fewer bugs.
A simple way to sort features:
- Must-have: Without this, the site doesn’t achieve its core goal.
- Nice-to-have: Adds value, but you can live without it for a few months.
- Later: Interesting, but unproven—park it until real users give feedback.
Once we agree on what’s truly “must-have” for launch, we can give you a much more accurate price and realistic timeline.
Conclusion & CTA
Building or redesigning a website doesn’t have to be painful. When you:
- Define what success looks like,
- Prepare content and assets early,
- Respect the wireframe/prototype stage,
- Give clear, consolidated feedback, and
- Are willing to phase features,
You get a smoother project, better results, and usually a lower total cost.
If you’re planning a new site and want to start off on the right foot, I’ve put together a simple Website Project Brief Template you can fill out and share with your developer or agency. You can download it here: [Project Brief Template].