Een Hand kan pagina’s schrijven, content opnieuw ordenen, styling aanpassen en later gewoon verder werken. Het belangrijkste is niet dat je hem de grootst mogelijke technische stack geeft. Het gaat erom dat je een paar systemen met duidelijke rollen neerzet, zodat de website een vaste plek heeft en er een voorspelbare route bestaat van wijziging naar publicatie.
Voor een bedrijfswebsite, portfolio, landingspagina of eenvoudige informatiesite kan een domein met GitHub en Cloudflare al genoeg zijn. Voeg geen database, CMS of extra dienst toe alleen omdat je die ooit misschien nodig hebt.
De minimale stack: domein + GitHub + Cloudflare
Het enige wat Hands niet uit de vergelijking kan halen is eigenaarschap van je domein. Je hebt een domein nodig waar jij controle over hebt. Daarna kun je de rest opdelen in twee simpele verantwoordelijkheden.
Je pagina’s, stijlen, assets en wijzigingsgeschiedenis leven in een repository. Je Hand kan die repository lezen en, binnen de instellingen voor beoordeelde acties, branches en bestanden aanmaken, exacte bestanden bijwerken en via pull requests werken.
Je Hand kan via begrensde Cloudflare-acties werken met Pages, DNS, Workers en bijbehorende website-infrastructuur. Daarmee krijgt de code een publicatieroute en weet je domein waar de site staat.
Als die rollen eenmaal helder zijn, kan een later verzoek weer gewoon over het resultaat gaan:
“Voeg een pagina voor zakelijke klanten toe, werk de navigatie bij en publiceer de nieuwe versie.”
De precieze uitvoering hangt natuurlijk af van de repository, het Cloudflare-account en de connectorrechten die je die Hand geeft. Het nuttige is dat je website niet langer een eenmalige export op iemands laptop is. Hij heeft een bron van waarheid en een herhaalbaar publicatiepad.
Heb je al een website? Gebruik de publieke site als bronmateriaal.
Als je een bestaande publieke website wilt vervangen, hoef je niet altijd vanaf een leeg scherm te beginnen. Firecrawl kan openbare pagina’s zoeken, scrapen en in kaart brengen. Als de Firecrawl-preview beschikbaar is voor jouw Hands-account, kan dat je Hand nuttig bronmateriaal geven voordat de nieuwe site in GitHub wordt opgebouwd.
“Breng de publieke pagina’s van onze huidige site in kaart, behoud de nuttige teksten en informatiestructuur en bouw daarna een schonere statische versie in de nieuwe GitHub-repository.”
Dat is niet hetzelfde als een automatische migratie. Een publieke crawl kan geen privé-databases, ingelogde delen, formulierverwerking, checkoutlogica, serverconfiguratie, redirects of iedere externe integratie achter de oude site zomaar terugbouwen. Zie scrapen als een manier om publieke content en structuur terug te halen en bouw daarna bewust opnieuw wat de nieuwe site echt nodig heeft.
De Hands Firecrawl-koppeling is momenteel een begrensde preview. Beschikbaarheid kan per account verschillen. Is hij niet beschikbaar, lever of exporteer de bestaande content dan op een andere manier; GitHub + Cloudflare blijven de kern van de website-opzet.
Moet een formulier een e-mail versturen? Voeg Resend toe, geen complete backend.
Een statische website wordt net iets minder statisch zodra een bezoeker iets moet insturen. Een contactformulier is een goed voorbeeld. Een geheime mail-API-sleutel hoort niet in de browser, dus een nette opzet gebruikt een kleine server-side endpoint — bijvoorbeeld een Cloudflare Worker of Function — die de invoer controleert en Resend vraagt de e-mail te versturen.
Cloudflare FunctionControleert de invoer server-side. Geen mail-secret in de browser.
ResendVerstuurt de e-mail via de beschermde serverroute.De Resend-koppeling kan transactionele e-mail versturen en ook accountonderdelen beheren zoals domeinen, templates, contacten en webhooks, onder de goedkeuringsinstellingen van de Hand. Voor een websiteformulier wil je nog steeds dat het verzenden server-side gebeurt en dat je geen geheimen in client-side code stopt.
Als je enige extra wens is “stuur deze contactaanvraag naar [email protected]”, dan is dit nog steeds een kleine website. Je hebt één smalle functie toegevoegd, geen groot applicatieplatform.
Voeg Supabase pas toe wanneer de website echt iets moet onthouden.
Veel websites hebben helemaal geen database nodig. Als alle content in de repository staat en de assets met de site meekomen, kunnen GitHub en Cloudflare jarenlang genoeg blijven.
Supabase wordt interessant wanneer je site een applicatie wordt: blijvende records, gebruikersaccounts, dynamische content, applicatielogica of grotere externe opslag kunnen een aparte datalaag rechtvaardigen. De huidige Hands Supabase-koppeling kan projecten vinden, SQL uitvoeren, projectlevenscyclus beheren en Edge Functions deployen. Je website kan daarnaast ontworpen worden om Supabase-diensten te gebruiken waar dat past, maar ga er niet vanuit dat elk Supabase-beheerscherm als Hands-actie beschikbaar is.
- Zes productafbeeldingen? Houd ze gewoon bij de site, tenzij er een echte operationele reden is om dat niet te doen.
- Honderden uploads van klanten? Externe objectopslag begint dan logisch te worden.
- Profielen, inzendingen of gestructureerde records? Dan wordt een database logisch.
- Gebruikers die inloggen? Dan ontwerp je inmiddels een applicatie-architectuur en niet alleen een statische website.
Een praktische volgorde
- Koop of kies het domein dat je wilt gebruiken. Houd eigenaarschap en facturatie onder je eigen controle.
- Maak een GitHub-repository voor de site. Maak die de duurzame bron van waarheid in plaats van een map die iemand af en toe uploadt.
- Koppel GitHub aan de Hand die de website gaat onderhouden. Geef alleen de repositoryrechten en het reviewgedrag waar jij je prettig bij voelt.
- Maak of koppel de relevante Cloudflare-opzet. Pages en DNS vormen meestal de basis; Workers worden nuttig zodra de site server-side gedrag nodig heeft.
- Bouw de kleinste werkende versie en publiceer hem. Controleer dat wijzigingen betrouwbaar van GitHub naar de live site kunnen.
- Voeg pas een extra dienst toe als er een concrete eis verschijnt. Firecrawl voor publieke migratie-input, Resend voor e-mail en Supabase voor blijvende applicatiedata.
Bouw geen architectuur voor hypothetische toekomstige functies. Een simpele site moet simpel blijven. Je Hand kan de stack later uitbreiden zodra een volgende echte eis zich aandient.
Waar elke koppeling echt voor is
Als je de rollen expliciet houdt, blijft de hele opzet makkelijker te begrijpen:
GitHubBroncode, bestandswijzigingen, branches en pull requests via begrensde repository-acties.CloudflarePages, DNS, Workers en geselecteerde infrastructuur via begrensde provideracties.
FirecrawlOptioneel openbare websites uitlezen en begrensd crawlen wanneer de preview beschikbaar is.ResendE-mailbezorging en bijbehorende mailresources; gebruik server-side verwerking voor websiteformulieren.
SupabaseOptionele project- en databaselaag voor sites die echte applicaties zijn geworden.Het doel is niet meer connectors. Het doel is een website met een duidelijke thuisbasis.
De nuttige eindtoestand is heerlijk saai: je domein wijst naar een site die uit GitHub opnieuw opgebouwd kan worden, Cloudflare weet hoe hij hem moet serveren en iedere extra dienst bestaat omdat één concrete eis hem rechtvaardigde. Daarmee geef je je Hand een stabiele omgeving waar hij volgende week, volgende maand of na tien wijzigingen gewoon weer op kan voortbouwen.
Begin met de twee koppelingen die je website een bron en een weg naar buiten geven.
Koppel GitHub en Cloudflare aan de Hand die de site gaat onderhouden. Voeg de rest pas toe wanneer het werk daarom vraagt.