Van prototype naar live

Wat is de klif?

De klif, in het Engels de technical cliff, is het gat tussen een prototype dat werkt en een project dat leeft. Je AI-tool heeft je in een middag verder gebracht dan je eerder in een maand kwam, en precies daar houdt de begeleiding op. Wat er dan mist is geen functionaliteit maar een lijst: niemand vertelt je welke tien dingen je moet regelen voordat je iets aan een vreemde durft te laten zien.

Het is een kennisprobleem, niet een vaardigheidsprobleem. In de woorden die het scherpst beschrijven wat er gebeurt: niet ik mis een functie, maar ik weet niet wat ik niet weet. Daarom voelt de klif zo persoonlijk. Je kunt niet zoeken naar iets waarvan je de naam niet kent.

De uitweg is banaal: de lijst opschrijven en hem aflopen. Dat is wat de acht secties hierna doen. Ze staan in de volgorde waarin je ze tegenkomt, en elke sectie eindigt bij de kleinste versie die goed genoeg is om live te gaan. Perfectie is hier het echte risico: een project dat maanden bijna klaar is, is minder waard dan een project dat vandaag draait en volgende week beter wordt.

• De klif is een informatieprobleem: je mist een lijst, geen talent.
• Werk in de volgorde waarin je de problemen tegenkomt, niet in de volgorde van moeilijkheid.
• Kies per stap de kleinste versie die goed genoeg is, en ga live.

Welke hosting kies je voor een AI-gebouwd project?

Hosting is de plek waar je project draait zodra jouw laptop dicht is. Voor een AI-gebouwd project bepaalt één vraag bijna alles: is het een site die als bestanden geleverd kan worden, of moet er een server meedenken? Een statische site (alleen pagina's, geen inlog, geen database) kun je bijna gratis en bijna overal kwijt. Zodra er accounts, opslag of betalingen bij komen, heb je een omgeving nodig die code uitvoert.

De drie vormen die je in de praktijk tegenkomt: een statische host die je bestanden uitlevert, een platform-as-a-service die jouw code voor je draait en bij elke wijziging opnieuw uitrolt, en een eigen server waar je alles zelf inricht. Voor een eerste live project is de tweede vorm bijna altijd de juiste: je houdt controle over je code zonder dat je een besturingssysteem hoeft te beheren.

Let bij het kiezen op vier dingen, in deze volgorde: kun je je eigen domein koppelen, krijg je automatisch HTTPS, kun je omgevingsvariabelen instellen zonder ze in je code te zetten, en kun je weg zonder alles te herbouwen. Dat laatste is de belangrijkste en wordt het vaakst vergeten. Een host die je code als gewone code behandelt, kun je verlaten. Een host die je in een eigen formaat opsluit, niet.

• Statische site zonder inlog: een statische host is genoeg.
• Accounts, opslag of betalingen: kies een omgeving die je code uitvoert.
• Vier eisen: eigen domein, automatisch HTTPS, omgevingsvariabelen, en een uitweg.
• Reken op maandkosten, niet op eenmalige kosten, en kijk wat er gebeurt als je gratis laag vol raakt.

Hoe koppel je een domein, in gewone taal?

Een domein is een naam die naar een adres wijst. Je koopt de naam bij een registrar en je vertelt daarna aan het internet waar de bijbehorende server staat. Dat vertellen gebeurt met DNS-records, en je hebt er in de praktijk twee soorten voor nodig: een record dat je naam aan een adres knoopt, en records voor e-mail als je vanaf je eigen domein wilt mailen.

Voor de site zelf heb je twee records nodig. Een A-record, of AAAA voor het nieuwere IPv6, dat je kale domeinnaam aan een adres knoopt. En een CNAME die een subdomein zoals www naar een andere naam laat verwijzen. Veel hosts geven je exact op wat je moet invullen; die instructie is leidend boven elke algemene uitleg, ook boven deze.

Drie dingen die bijna iedereen de eerste keer verrast. Ten eerste: een wijziging is niet direct overal zichtbaar, want DNS wordt gecachet, en de wachttijd staat in het TTL-veld. Reken op minuten tot uren, niet op seconden. Ten tweede: kies één canonieke vorm, met of zonder www, en laat de andere daar naartoe doorverwijzen; twee vormen die beide werken kost je vindbaarheid en verwart je bezoekers. Ten derde: regel HTTPS voordat je de link deelt, want een browser die waarschuwt dat je site onveilig is, kost meer vertrouwen dan een dag uitstel.

• A-record voor de kale naam, CNAME voor subdomeinen zoals www.
• Volg de instructie van je host boven algemene uitleg.
• Kies één canonieke vorm en verwijs de andere door in één stap.
• Wacht op de TTL voordat je concludeert dat het niet werkt.

Wat doe je met je database?

Een prototype bewaart gegevens vaak op een plek die verdwijnt: in het geheugen, in een bestand naast de code, of in de browser van degene die het bekijkt. Dat werkt precies zolang niemand het serieus gebruikt. De eerste keer dat je host je project herstart en de gegevens weg zijn, is de les geleerd. Een echte database is daarom geen luxe maar de grens tussen demo en product.

Voor een eerste live project heb je zelden iets exotisch nodig. Een beheerde relationele database is de veilige standaardkeuze: je krijgt hem geleverd, er zit een back-up bij, en je kunt hem verlaten omdat het formaat niet van één aanbieder is. Beheerd betekent hier dat iemand anders de updates en de back-ups doet; dat is de moeite waard, want zelf een database bijhouden is werk dat nooit ophoudt.

Drie dingen die je meteen goed moet doen, omdat ze later duur worden. Zet een back-up aan en herstel er één keer echt uit, want een back-up die je nooit hebt teruggezet is een aanname. Houd je schema in code via migraties, zodat je kunt zien wat er wanneer veranderde. En bewaar geen gegevens die je niet nodig hebt: elk veld dat je niet opslaat, kan niet uitlekken en hoeft niet opgeruimd te worden.

• Bewaar niets blijvends in het geheugen of in een bestand naast de code.
• Kies beheerd en in een formaat dat je kunt meenemen.
• Back-up aan, en één keer een echte herstelproef.
• Schema in migraties, en sla alleen op wat je echt gebruikt.

Waar laat je omgevingsvariabelen en geheimen?

Een geheim is elke waarde waarmee iemand anders zich als jou kan voordoen: een API-sleutel, een databasewachtwoord, een tokensleutel. AI-tools zetten die waarden vaak gemakshalve in de code, en zolang je alleen zelf kijkt merkt niemand het. Zodra je code in een repository staat of je project publiek is, is elk geheim in de code een geheim dat weg is.

De werkwijze is simpel en overal hetzelfde. Geheimen horen in omgevingsvariabelen die je bij je host instelt, niet in bestanden die je meelevert. Lokaal gebruik je een .env-bestand dat je uitsluit van versiebeheer, met ernaast een .env.example die alleen de namen bevat zodat een ander weet welke waarden nodig zijn. En je maakt onderscheid tussen sleutels die in de browser mogen staan en sleutels die alleen op de server mogen bestaan; een sleutel die in de browser terechtkomt, is publiek, ongeacht hoe hij heet.

Twee handelingen die je vandaag nog kunt doen. Zoek je project door op wat op een sleutel lijkt, ook in oude commits, want versiebeheer vergeet niets. En als er ooit een sleutel gelekt is, wissel hem: verwijderen uit de code is niet genoeg, want de oude waarde blijft geldig tot je hem intrekt.

• Geheimen in omgevingsvariabelen bij de host, nooit in de code.
• .env uit versiebeheer, .env.example met alleen de namen erin.
• Wat in de browser komt, is publiek; scheid client- en serversleutels.
• Een gelekte sleutel wissel je, niet verwijder je.

Welke beveiligingschecks doe je vóór livegang?

Beveiliging klinkt als een specialisme, en op grote schaal is het dat ook. Voor een eerste live project gaat het om een korte lijst basisdingen die de meeste ellende voorkomen. De vuistregel: alles wat van buiten binnenkomt is verdacht tot je het hebt gecontroleerd, en alles wat naar buiten gaat mag niet meer prijsgeven dan nodig.

De checks die er het meest toe doen, in de volgorde van opbrengst. Zet HTTPS aan en dwing hem af, zodat niemand nog over de onbeveiligde variant binnenkomt. Controleer of je invoervelden hun inhoud valideren op de server en niet alleen in de browser, want de browsercontrole is een gebruiksgemak en geen slot. Zorg dat foutmeldingen naar bezoekers niets technisch prijsgeven: een stacktrace op een publieke pagina is een routekaart. Zet rate limiting op formulieren en inlogpogingen. En controleer of gegevens van de ene gebruiker nooit bij de andere kunnen belanden door een id in de URL te veranderen; dat is de fout die het vaakst voorkomt en het meest kost.

basestep bevat hiervoor een gezondheidscheck van achttien punten in vijf gebieden, die je zelf aflegt en zelf afvinkt. Het platform controleert je site niet automatisch en zet niets voor je live: het geeft je de lijst en de uitleg, jij doet de handeling.

• HTTPS aan en afgedwongen, geen onbeveiligde ingang.
• Validatie op de server, niet alleen in de browser.
• Nette foutpagina's zonder technische details.
• Rate limiting op formulieren en inlogpogingen.
• Controleer of een id in de URL geen andermans gegevens opent.

De achttien punten staan in de gezondheidscheck, met per punt wat je moet doen en waarom.

Wat is het minimum aan toegankelijkheid en vindbaarheid?

Toegankelijkheid en vindbaarheid lijken twee onderwerpen en zijn in de praktijk hetzelfde werk. Een pagina die een schermlezer kan volgen, kan een zoekmachine ook volgen. Beide lezen je pagina als structuur, niet als plaatje, en beide struikelen over dezelfde dingen.

Het minimum dat het meeste oplevert. Geef elke pagina één h1 en gebruik de kopniveaus in volgorde, zonder er een over te slaan. Geef elke afbeelding een alt-tekst die zegt wat er te zien is, of een lege alt als de afbeelding puur decoratief is. Zorg dat je hele site met het toetsenbord te gebruiken is en dat je ziet waar de focus staat. Controleer het contrast tussen tekst en achtergrond. En geef elke pagina een eigen title en een eigen beschrijving die klopt met wat er op staat. Wat basestep.io zelf op deze punten heeft nagelopen, staat in de toegankelijkheidsverklaring.

Voor vindbaarheid komen daar drie technische dingen bij die je één keer doet. Een sitemap.xml zodat een zoekmachine je pagina's kan vinden. Een robots.txt die niet per ongeluk je hele site blokkeert. En een canonieke URL per pagina, zodat dezelfde inhoud niet op twee adressen staat. Dat laatste is dezelfde keuze als bij je domein in stap 3, en het is dezelfde fout als je hem daar liet liggen.

• Eén h1 per pagina, kopniveaus in volgorde.
• Alt-teksten die iets zeggen, lege alt bij decoratie.
• Bruikbaar met het toetsenbord, met zichtbare focus.
• Contrast gecontroleerd, eigen title en beschrijving per pagina.
• Sitemap, robots.txt en één canonieke URL per pagina.

Welke juridische minimums gelden er?

Zodra je project publiek staat, gelden er informatieplichten, en zodra je persoonsgegevens verwerkt, gelden er meer. Dit is geen juridisch advies en geen volledige lijst; het is de korte versie van wat je hoe dan ook tegenkomt in Nederland, zodat je weet waar je naar moet vragen.

Drie dingen die vrijwel altijd gelden. Ten eerste: wie je bent moet vindbaar zijn. Voor een dienst van de informatiemaatschappij vraagt artikel 3:15d van het Burgerlijk Wetboek dat je identiteit, adres, contactgegevens en KVK-nummer eenvoudig en permanent toegankelijk zijn. Ten tweede: verzamel je persoonsgegevens, ook alleen een e-mailadres voor een wachtlijst, dan heb je een privacyverklaring nodig. Die zegt wat je bewaart, waarom, hoe lang, en met wie je het deelt. De informatieplicht van artikel 13 AVG geldt vanaf de eerste inschrijving. Ten derde: zet je iets in de browser van je bezoeker dat niet strikt nodig is voor de dienst, zoals analytics, dan heb je daarvoor toestemming nodig (artikel 11.7a Telecommunicatiewet). Meet je niets, dan heb je ook geen banner nodig, en dat is de eenvoudigste route.

Ga je verkopen, dan komt er meer bij: algemene voorwaarden die je aan je klant ter beschikking stelt op een manier waarop hij ze kan opslaan, en bij consumenten een herroepingsrecht. Laat die teksten door een jurist toetsen voordat je de eerste euro ontvangt. Ze zijn goedkoper dan het geschil waarin je ze mist.

• Je identiteit en KVK-nummer permanent vindbaar op de site.
• Privacyverklaring zodra je één e-mailadres verzamelt.
• Geen niet-noodzakelijke opslag in de browser zonder toestemming; niets meten is de simpelste weg.
• Ga je verkopen: voorwaarden en herroepingsrecht, getoetst voordat je verkoopt.

Dit is algemene uitleg, geen juridisch advies. Voor jouw situatie raadpleeg je een jurist.

Wat komt er na livegang?

Live gaan is de helft. Een project dat draait, vervalt stilletjes als niemand ernaar kijkt: certificaten verlopen, afhankelijkheden verouderen, formulieren stoppen met werken zonder dat iemand het merkt. De tweede helft is een klein ritme in plaats van een groot plan.

Het minimale ritme dat werkt. Controleer maandelijks of je site nog draait, of je formulieren nog aankomen en of je back-ups nog gemaakt worden; dat laatste door er één te openen. Werk je afhankelijkheden bij op een vast moment, want een halfjaar niets doen maakt van elke update een verbouwing. Meet één ding dat je echt gebruikt in plaats van een dashboard vol getallen waar je niets mee doet. En schrijf op wat je veranderde, al is het in drie regels per week: het is de enige manier om over een half jaar te weten waarom iets zo is.

En dan de stap die de meeste mensen overvalt: het moment dat je project geld gaat verdienen. Dan komt er een administratie bij, met btw, facturen die aan eisen moeten voldoen, en een bewaarplicht. Dat is precies de reden dat basestep bestaat: het pad loopt door van eerste prompt tot je eerste aangifte, met een belastingmotor die elke rubriek uitlegt tot aan de wetsverwijzing. Jij dient zelf in en begrijpt precies wat je doet.

• Maandelijks: draait het, komen formulieren aan, werkt de back-up.
• Afhankelijkheden op een vast moment bijwerken.
• Meet één ding dat je gebruikt.
• Houd bij wat je veranderde.
• Verdien je geld: regel de administratie voordat het kwartaal om is.

Dit is algemene uitleg, geen fiscaal of juridisch advies. basestep rekent en legt uit; jij dient zelf in. Twijfel je over jouw situatie, raadpleeg dan een adviseur.