Website development brief template voor founders

Een website build loopt scheef wanneer de kickoff een Loom is, een Figma moodboard, en de hoop dat iedereen dezelfde definitie van “done” deelt. Founders voelen dit het eerst. Je betaalt voor een site die leads moet winnen, het product uitleggen of een funding round sluiten, en in plaats daarvan krijg je eindeloze polish op de verkeerde pagina’s.

Een website development brief is het korte document dat dat fixt. Het stelt wat je bouwt, voor wie, wat in en out of scope is, wie welke accounts bezit, en hoe je het werk accepteert. Deze gids geeft je een copy-ready brief template plus de reden waarom elk blok bestaat, zodat je een freelancer, agency of in-house builder kunt briefen zonder dezelfde gaps mid-sprint opnieuw te ontdekken.

Waarom een brief een vage kickoff-call wint

Kickoff-calls zijn nuttig voor tone en trust. Ze zijn verschrikkelijk als enige source of truth. Mensen herinneren verschillende zinnen. Slack-threads begraven de ene beslissing die ertoe deed. Drie weken later vraagt iemand of blog SEO inbegrepen was, en niemand kan naar een antwoord wijzen dat opgeschreven stond.

Een brief forceert de harde vragen vroeg, wanneer van richting veranderen goedkoop is. Het beschermt ook de builder. Duidelijke scope is hoe goede freelancers eerlijk quoten en hoe jij quotes vergelijkt zonder apples-to-oranges theater.

Een klembord-brief zit tussen een kickoff-call en een build-kalender zodat beslissingen geschreven blijven.

Belangrijkste takeaway: Staat een beslissing niet in de brief of een amendment ervan, behandel die als undecided. Die ene regel voorkomt de meeste “ik dacht dat we het eens waren”-ruzies.

Goals en hoe je weet dat de site werkte

Begin met outcomes, niet page count. “We hebben een marketing site nodig” is een categorie. “We hebben gekwalificeerde demo requests nodig van Series A SaaS-buyers in de US en EU” is een goal. Schrijf maximaal twee of drie goals. Meer betekent meestal dat je een brand site, product app en content engine mengt in één vage wens.

Voor elk goal: voeg een success signal toe dat je in de eerste 30 tot 90 dagen na launch kunt observeren. Voorbeelden die in een brief werken:

• Demo form completions per week (baseline vs target range)
• Time-to-first-useful-page voor een nieuwe bezoeker (home naar pricing of docs)
• Organische impressions voor een gedefinieerde cluster van phrases zodra Search Console is gekoppeld
• Support tickets die stoppen omdat een FAQ- of docs-pagina ze nu beantwoordt

Zet niet “rank #1 voor ons category keyword” als success signal tenzij je al een content- en linkplan hebt. Rankings zijn een outcome van veel systemen. Een brief kan SEO-expectations zetten (zie later). Hij mag geen posities beloven.

Goals zitten boven page lists. Elk goal koppelt aan een signal dat je na launch kunt checken.

Audience, primaire jobs en objections

De meeste briefs skippen audience of plakken een persona uit een pitch deck. Builders hebben scherper nodig. Wie komt aan, welke job proberen ze af te maken, en wat zou hen doen vertrekken?

Schrijf maximaal drie korte audience notes. Beantwoord voor elk:

1. Wat zochten, klikten of werden ze zojuist naar doorverwezen?
2. Welke beslissing proberen ze op dit bezoek te maken?
3. Welk bewijs zou risico verlagen (customer logos, pricing clarity, security page, founder story)?

Verkoop je aan buyers én users, zeg welke site voor wie is. Een founder product site die end users en CFO’s op dezelfde homepage probeert te converteren, verdunt meestal beide.

Elke audience note paart een job-to-be-done met het bewijs dat bounce verlaagt.

Sitemap, pagina’s en kritieke flows

Hier worden vage projecten shippable. Lijst de pagina’s die je in v1 nodig hebt, daarna de flows die end to end moeten werken. Een page list zonder flows is hoe contactforms broken shippen en hoe “book a demo” een mailto-link wordt die niemand op mobile testte.

Voorgestelde vorm voor de brief:

• Must-ship pages. Home, product of services, pricing (of hoe je verkoopt), about, contact of demo, legal pages die je echt nodig hebt.
• Should-ship als budget het toelaat. Case studies, blog index, careers, integrations, status page.
• Expliciet later. Alles wat je mid-build geneigd bent te verzinnen (customer portal, full docs site, community forum).

Lijst flows daarna als genummerde paden, niet als features:

1. Bezoeker landt op home → pricing → demo form → thank-you page → e-mail notification naar sales.
2. Bezoeker landt op een servicepagina → related case study → contact.
3. Returning visitor raakt een oude URL → redirect naar het nieuwe pad (redirect map stub).

Heb je al een live site, voeg de current URL inventory toe en markeer keep / merge / kill. Redesigns die de oude URL map negeren, creëren SEO- en bookmark-schade die eruitziet als “de nieuwe site doodde traffic” terwijl de brief nooit om redirects vroeg.

Page boxes en flow-pijlen horen in dezelfde sectie zodat “done” het pad omvat, niet alleen de layout.

SEO-expectations die de moeite waard zijn om op te schrijven

Founders zeggen vaak “we hebben SEO nodig” zoals ze “we hebben branding nodig” zeggen. Builders horen ofwel een full content program of basic technical hygiene. Zet de expectation in de brief zodat quotes de realiteit matchen.

Een praktisch SEO-blok voor een marketing site build dekt meestal:

• Technical baseline. HTTPS, sensibele URL-structuur, XML-sitemap, robots.txt die money pages niet blokkeert, canonicals op primaire templates, crawlbare HTML voor main content.
• On-page voor afgesproken templates. Unieke titles en H1s, meta descriptions die je later kunt editen, interne links tussen hubs en money pages.
• Analytics en Search Console. Wie de properties aanmaakt, wiens Google-account ze bezit, en dat de builder alleen toegang krijgt wanneer nodig.
• Content production. Zeg of launch N artikelen omvat, migratie van oude posts, of geen. “We doen blog later” is fine wanneer het opgeschreven staat.
• Redirects. Vereist wanneer je een bestaand domein of padstructuur vervangt.

Wat het SEO-blok niet mag doen: rankings, traffic of een vaste positie op een datum garanderen. Google’s eigen guidance over creating helpful content gaat over usefulness en trust, niet vendor promises. Je brief kan een site eisen die crawlbaar en duidelijk is. Hij kan geen SERP-slot kopen.

Technical baseline, on-page templates, Search Console-ownership en redirects zitten in één eerlijke SEO-sectie.

Veelgemaakte fout: Vragen om “full SEO” zonder content budget en zonder redirect map, en daarna het theme de schuld geven wanneer organic daalt na een redesign.

Milestones, reviews en decision owners

Milestones maken van een brief een kalender waar mensen omheen kunnen plannen. Houd ze weinig en concreet. Een typische marketing site-vorm:

1. Brief locked. Jij en de builder signen off op scope, pages, SEO-expectations en out of scope.
2. Structure en wireframes. Information architecture en key templates afgesproken vóór visual polish.
3. Design voor primaire templates. Home plus één interior money page vóór elke pagina te designen.
4. Build en content drop. Copy en assets arriveren op een gestelde datum of de timeline slip’t per definitie.
5. Staging review. Functionele en content QA tegen de acceptance list.
6. Launch en handoff. DNS, analytics, repo access en documentatie zoals gedefinieerd in ownership.

Noem een decision owner voor design, copy en technical go-live. Committees die allemaal “approven” en niemand beslist, verbranden je timeline. Ben jij de founder, schrijf je eigen naam voor final call op brand en messaging, en noem wie staging bugs day to day kan approven.

Elke milestone heeft een date window en één named owner voor de call die de volgende stap unblocked.

Ownership van accounts, domains en code

Deze sectie redt relaties. Voordat iemand start, schrijf wie bezit:

• Domain registrar en DNS
• Hosting of platform account (Vercel, Netlify, Cloudflare Pages, WP Engine, enzovoort)
• Git repository
• CMS (indien aanwezig)
• Google Analytics / GA4 en Google Search Console
• E-mailverzending voor forms (Resend, Formspree, jouw ESP)
• Third-party scripts (chat, ads, A/B-tools)
• Design files (Figma)

Default regel die voor de meeste founders werkt: het bedrijf bezit elk production account. De builder krijgt invited collaborator access, geen persoonlijk ownership van het domein of de repo. Als een freelancer erop staat het domein “tot final payment” te houden, is dat een negotiation flag, geen standaardpraktijk.

Schrijf ook wat er bij handoff gebeurt: admin invites overgedragen, persoonlijke builder-accounts verwijderd, deploy keys geroteerd indien nodig, en een korte README voor hoe je een change ship’t.

Company-owned accounts met builder access, geen builder-owned production keys.

Waarschuwing: Laat Search Console of het domein na launch niet onder de persoonlijke Gmail van een contractor. Wanneer die relatie eindigt, wordt recovery lelijk.

Out of scope (de sectie die iedereen beschermt)

Out of scope is geen vijandigheid. Het is hoe je de quote eerlijk houdt. Lijst het werk dat je in deze engagement niet koopt, ook als het related klinkt.

Veelvoorkomende items voor een marketing site brief:

• Custom web app of logged-in product UI
• Doorlopende content writing voorbij een afgesproken article count
• Link building of outreach
• Paid ads setup en management
• Brand identity from scratch (logo, full guidelines) tenzij gequote
• Photography of video production
• Multilingual expansion voorbij listed locales
• Migraties van e-maillijsten, CRM pipelines of billing systems
• SLA-backed uptime voorbij de default van de host

Als iets later kan verschijnen, zet het onder “phase 2 candidates” in plaats van het verbaal in v1 te smokkelen. Builders die meenikken met infinite scope onderleveren of sturen change orders. Founders die weigeren out of scope op te schrijven, ontdekken het meestal als surprise invoices.

Out of scope-items zitten buiten de v1-fence zodat quotes vergelijkbaar blijven en change orders intentioneel blijven.

Acceptance criteria die zeggen wanneer de site done is

Acceptance is de checklist die je op staging gebruikt vóór DNS flipt. Zonder wordt “done” smaak. Met blijft smaak ertoe doen voor design, maar ship-blocking issues zijn objectief.

Schrijf acceptance als pass/fail-statements gekoppeld aan de brief:

• Elke must-ship page is bereikbaar vanuit primaire navigatie of een afgesproken sitemap-pad.
• Elke listed flow complete’t op desktop en een mid-size phone (form submits, thank-you toont, notification komt aan).
• Redirects van de afgesproken map retourneren de correcte bestemming.
• Titles en H1s bestaan voor primaire templates en matchen de afgesproken copy deck.
• Analytics fired op key events die je listte (form submit, outbound calendar click).
• Legal pages gelinkt in de footer zijn aanwezig als vereist voor jouw markt.
• Broken links en console errors op primaire templates zijn opgelost of expliciet waived.
• Repo-, hosting- en analytics-access matchen de ownership-sectie.

Design polish kan een aparte “known follow-ups”-lijst hebben. Houd launch niet hostage voor pixel debates die nooit in de brief stonden, en skip geen broken flows omdat de homepage er goed uitziet.

Pass/fail acceptance-regels maken van staging review een ship-beslissing in plaats van een smaakargument.

Uitgewerkt scenario voor een B2B SaaS-founder die v1 brief’t

Maya run’t een Series A workflow tool. Ze heeft een publieke site nodig vóór een partner announcement over zes weken. Ze is geneigd te vragen om “een moderne site als Linear, plus een blog, plus een customer portal teaser.”

Ze vult in plaats daarvan de brief:

• Goals. Partner-ready product story; demo requests van mid-market ops leads; Search Console gekoppeld met redirects van de oude Webflow-paden.
• Audience. Ops managers die deze quarter tools evalueren; partners die integration credibility checken.
• Must-ship pages. Home, product, integrations, pricing, security, about, demo, privacy, terms. Blog index met alleen drie gemigreerde posts.
• Flows. Demo form naar HubSpot; security page gelinkt vanuit footer en pricing footnote.
• SEO. Technical baseline, redirects van 14 oude URL’s, geen nieuw content retainer in v1.
• Out of scope. Customer portal UI, custom illustrations pack, ads, doorlopende blog production.
• Ownership. Company Cloudflare en GitHub; builder als collaborator; Maya bezit GA4 en Search Console.
• Acceptance. Flows getest op staging; redirect spot-checks; form landt in de juiste HubSpot pipeline.

De quote die ze krijgt is vergelijkbaar over twee freelancers omdat beiden dezelfde fence pricen. Wanneer iemand in week drie een portal mock voorstelt, wijst ze naar out of scope en plant phase 2 in plaats van de partner date te blazen.

Maya’s brief fenced partner-ready pages en redirects, en parked de portal in phase 2.

Copy-paste website development brief template

Gebruik dit als working doc. Verwijder de guidance tussen haakjes terwijl je antwoorden vult.

1. Project snapshot

• Working title / bedrijfsnaam:
• Primair domein (huidig en intended):
• Target launch window:
• Decision owner (final call op scope en go-live):
• Day-to-day contact:

2. Goals en success signals

• Goal 1 + hoe we het in 30-90 dagen meten:
• Goal 2 + hoe we het meten:
• Goal 3 (optioneel):
• Wat deze site niet bedoeld is om op te lossen:

3. Audience en jobs

Voor maximaal drie audiences:

• Wie ze zijn:
• Job op dit bezoek:
• Bewijs dat risico verlaagt:
• Primaire CTA die we van hen willen:

4. Brand en constraints

• Bestaande brand assets (logo, kleuren, fonts, Figma):
• Tone notes (maximaal drie adjectieven, plus één “avoid”):
• Competitors of reference sites (wat structureel te lenen, niet te kopiëren):
• Accessibility- of compliance-notes (WCAG-target, industries, regio’s):
• Talen / locales in v1:

5. Sitemap en flows

• Must-ship pages:
• Should-ship als budget het toelaat:
• Expliciet later / phase 2:
• Kritieke flows (genummerd):
• Existing URL inventory attached? (ja/nee + link):
• Redirect map owner:

6. Content en assets

• Wie schrijft copy:
• Copy freeze date voor launch templates:
• Image / video sources:
• Customer quotes of logos goedgekeurd voor gebruik:
• Legal pages vereist:

7. SEO en measurement

• Technical SEO baseline vereist? (ja/nee)
• On-page voor welke templates:
• Blog / content in v1 (count of none):
• Redirects vereist? (ja/nee)
• Analytics tools en event list:
• Search Console- en analytics-account owners:

8. Stack preferences (optioneel)

• Preferred framework of CMS (of “builder recommends”):
• Hosting preference:
• Form / CRM destination:
• Things we already pay for that must be reused:

9. Milestones

Milestone	Target window	Owner	Exit criteria
Brief locked
IA / wireframes
Design for primary templates
Build + content drop
Staging acceptance
Launch + handoff

10. Ownership

Asset	Company owner account	Builder access level	Handoff note
Domain / DNS
Hosting
Git repo
CMS
Analytics
Search Console
Forms / ESP
Design files

11. Out of scope

• Lijst items niet inbegrepen in deze quote:
• Phase 2 candidates (optioneel):

12. Acceptance criteria

• Checklist van pass/fail-statements voor staging:
• Known follow-ups toegestaan na launch (non-blocking):
• Sign-off names en date:

13. Commercial notes (houd kort)

• Fixed fee of time-and-materials:
• Wat een change order triggert:
• Support window na launch (dagen bug fix, indien aanwezig):

Dat is de bruikbare template. Alles erboven bestaat zodat je deze fields met intent vult in plaats van lege headings.

De brief overdragen zonder de plot te verliezen

Stuur de brief voordat je om een final quote vraagt. Loop die één keer live door als de builder nieuw voor je is, freeze daarna een versie (datum in de filename of shared doc version history). Changes na freeze worden amendments. Dat klinkt formeel voor een site van vijf pagina’s. Het is hoe je voorkomt dat je twee keer betaalt voor dezelfde week werk.

Wanneer je vendors vergelijkt, score hen tegen dezelfde brief. Vraag waar ze het oneens zijn met jouw out of scope of SEO-blok. Oneensheid vroeg is nuttig. Stilte die later “SEO was implied” wordt, is dat niet.

Na launch: archiveer de brief met de handoff README. De volgende contractor mag geen seance met je Slack-historie nodig hebben.

Een gedateerde brief-versie beweegt van founder naar builder vóór de final quote, en archiveert daarna met handoff-notes.

Veelgestelde vragen

Hoe lang moet een website development brief zijn?

Twee tot vijf pagina’s is genoeg voor de meeste marketing sites. Heb je een roman nodig, specificeer je waarschijnlijk een product application. Houd de brief kort en attach inventories (URL’s, redirects, copy decks) in plaats van elke rij in de narrative te proppen.

Kan ik deze brief gebruiken voor Webflow, WordPress en custom code?

Ja. De brief is bewust stack-agnostic. Zet preferences in de stack-sectie als je die hebt. Zo niet, vraag de builder een stack te recommenden die matcht met jouw ownership en update-behoeften, en schrijf die keuze terug in de brief vóór de build start.

Wat als ik mijn sitemap nog niet ken?

Zeg dat, en maak discovery een paid milestone met een duidelijke exit: een voorgestelde sitemap en flows die je approvet vóór visual design. Doe alsof-zekerheid niet na. Fake sitemaps creëren rework.

Moeten SEO en development aparte briefs zijn?

Voor een kleine marketing site is één brief met een eerlijk SEO-blok meestal beter. Koop je een groot content program, technical SEO remediation of international hreflang-werk, dan kunnen dat aparte statements of work zijn gelinkt vanuit deze brief zodat ownership helder blijft.

Wie moet de brief schrijven, founder of agency?

De founder (of wie outcomes bezit) moet goals, audience, out of scope en ownership schrijven. Een goede builder kan helpen sitemap, flows en acceptance-taal te verfijnen. Als een agency de hele brief alleen schrijft, lees die als hun sales document tot je de goals in je eigen woorden editeert.

Wat hoort in een change order?

Alles wat pages, flows, integrations, locales of content volume toevoegt voorbij de locked brief, of dat een phase 2-item naar v1 verplaatst. Taste tweaks binnen een goedgekeurde template meestal niet. Twijfel je, vraag “verandert dit de acceptance checklist?” Zo ja, is het een change order-gesprek.

Sluit de loop voordat je uren koopt

Een duidelijke brief maakt een zwakke builder niet sterk. Wel maakt die sterke builders sneller, quotes vergelijkbaar, en launch day saai op de manieren die je wilt. Vul de template, freeze een versie, en behandel amendments als normaal wanneer de business iets nieuws leert.

Wil je hulp om een ruwe brief om te zetten in een scoped marketing site build (pages, SEO baseline, ownership en acceptance inbegrepen), neem contact op via het formulier.