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. De GitHub MCP-koppeling biedt tools om je repository te lezen. Of je Hand bestanden kan wijzigen, hangt af van de server en de rechten van je GitHub-token.
De MCP-koppeling gebruikt een Cloudflare API-token met beperkte rechten. Welke deploy-, DNS-, Workers- of andere Cloudflare-tools werkelijk worden aangeboden, hangt af van de provider-MCP-server en die token en niet van een vaste Hands-actielijst.
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 af van de repository, het Cloudflare-account, de remote MCP-tools die iedere provider aanbiedt en de credentials die je koppelt. 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 is beschikbaar in de MCP-catalogus. De huidige koppeling ondersteunt de beschreven tools voor zoeken, scrapen en mappen. Met een Firecrawl API-sleutel kan dat je Hand nuttig openbaar 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.
Gebruik het wanneer openbaar bronmateriaal echt werk bespaart. De koppeling gebruikt een API-sleutel en beschrijft zoeken, scrapen en mappen; je Firecrawl-abonnement en credits blijven gelden. GitHub + Cloudflare blijven de kern van de website-opzet.
Moet een formulier een e-mail versturen? Voeg een maildienst 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.
Resend is hier de transactionele mailprovider. De architectuur blijft hetzelfde ongeacht de actuele Hands-koppelroute: het formulier stuurt naar een server-side Function of Worker, die Resend aanroept zonder mailcredentials in de browser te plaatsen. Welke Hands-App, Plug-in- of Connectorroute voor Resend beschikbaar is, kan veranderen zonder dat je deze websitearchitectuur hoeft te herschrijven.
Als je enige extra wens is “stuur deze contactaanvraag naar sales@example.com”, 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. Supabase is beschikbaar in de MCP-catalogus en de koppeling gebruikt een personal access token met beperkte rechten. Welke project- of databasetools werkelijk beschikbaar zijn, hangt af van de provider-MCP-server en die token; ga er dus niet vanuit dat elk Supabase-beheerscherm wordt aangeboden.
- 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. Gebruik een providertoken met alleen de repositoryrechten die de opdracht nodig heeft en bekijk welke MCP-tools die verbinding echt aanbiedt.
- Maak of koppel de relevante Cloudflare-opzet. Configureer het publicatiepad dat je wilt en gebruik daarna een afgebakende Cloudflare API-token voor de MCP-koppeling.
- Bouw de kleinste werkende versie en publiceer hem. Controleer dat wijzigingen betrouwbaar van GitHub naar de live site kunnen via de tooling die je werkelijk hebt ingericht.
- Voeg pas een extra dienst toe als er een concrete eis verschijnt. Firecrawl voor publieke migratie-input, een mailprovider zoals Resend voor e-mail of 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:
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.
