Voor een prototype is een hostingplatform dat aan je repository hangt bijna altijd het juiste antwoord: je koppelt de code, het platform bouwt en publiceert, en je hebt een adres dat je kunt delen. Een eigen server ga je pas beheren als je iets draait dat daar niet in past. Het moeilijke deel zit niet in het online zetten, maar in het online houden.
Een prototype hosten is makkelijk. Een prototype gehost houden is het echte werk.
Om code voor anderen bereikbaar te maken heb je drie dingen nodig: iets dat hem draait, een openbaar adres en een certificaat. Een platform waar je je repository aan koppelt regelt die drie in één handeling. Voor een demo die je wilt laten zien en testen is dat genoeg.
Het verzakken komt daarna. Er zit verschil tussen "het staat online" en "het staat er over een paar maanden nog, met werkende data en zonder verlopen certificaat". Lukt het live zetten zelf niet, dan is een prototype dat lokaal werkt maar niet live de pagina die je zoekt. Gaat je vraag over software die echte productie-belasting moet dragen, lees dan van prototype naar productie.
Vier onderdelen, en ze wonen niet op dezelfde plek.
Er is code in een repository, een bouwstap die daar een draaiende applicatie van maakt, omgevingsvariabelen zoals sleutels en het databaseadres, en eventueel data uit de demo. Dat derde onderdeel raakt zoek. Omgevingsvariabelen horen bewust niet in de repository, anders staan je sleutels in de versiegeschiedenis. Ze bestaan alleen waar iemand ze heeft ingetypt: de laptop van de bouwer en het dashboard van de hosting. Vraag bij oplevering om een lijst van die variabelen.
Leg vast op wiens naam de hosting, het domein en de gekoppelde diensten staan. Staan ze in het account van de bouwer, dan ben je afhankelijk van iemand die volgende maand misschien niet meer meekijkt. Wat je verder hoort te krijgen staat in wat krijg je na een dag bouwen.
Drie soorten plek, met oplopende vrijheid en oplopend beheer.
Je koppelt je repository en vanaf dan wordt elke wijziging automatisch gebouwd en uitgerold. Je krijgt een adres met certificaat en kunt terug naar een vorige versie als iets sneuvelt. De prijs is dat je binnen hun model werkt: welke taalversies ze ondersteunen en wat het plan toestaat.
Je huurt een virtuele machine en zet daar zelf alles op: de applicatie, een webserver, het certificaat, de database, back-ups en toezicht. Dat geeft ruimte voor wat een platform niet aankan, zoals processen die lang doorlopen. En het beheer komt volledig bij jou te liggen.
Is je prototype een klikbare voorkant zonder serverkant, waar niets wordt opgeslagen, dan hoeft er niets te draaien. De bestanden gaan op statische hosting. Dit is de goedkoopste vorm en die waar het minst aan kapot kan.
De applicatie kun je opnieuw uitrollen. Data die weg is, is weg.
Op de meeste platformen is de schijf waarop je applicatie draait vluchtig. Wat de applicatie naar een bestand schrijft verdwijnt bij de volgende uitrol of herstart. Render zegt dat met zoveel woorden over zijn gratis plan, en het geldt breder. Een databasebestand naast je code werkt dus prima op je laptop en verdampt op een platform. De database hoort een aparte dienst te zijn, met een eigen adres dat je als omgevingsvariabele meegeeft.
Dat vraagt aandacht op twee punten. Back-ups zitten er niet vanzelf bij en zijn op gratis plannen vaak niet beschikbaar, zoals Supabase beschrijft in zijn documentatie over live gaan. En houdbaarheid: sommige aanbieders pauzeren een gratis database na een periode zonder verkeer, andere geven hem een vaste levensduur en verwijderen hem daarna definitief.
Vijf manieren waarop een prototype verzakt zonder dat iemand iets heeft aangeraakt.
Het adres van je host werkt prima om te testen. Om iets voor te leggen wil je je eigen naam.
Een domein registreer je bij een registrar, en dat hoeft niet je hostingpartij te zijn. Zorg dat de registratie op jouw bedrijf staat, niet in het account van de bouwer. Een subdomein van een domein dat je al hebt is vaak handiger dan een nieuwe registratie.
Je geeft bij het platform op welk domein bij deze applicatie hoort. De host laat dan zien welke DNS-records hij verwacht. Doe het in deze volgorde, anders wijst een record naar niets.
Voor het kale domein meestal een A-record met een IP-adres, voor een subdomein als demo of app een CNAME naar je host. Wijzigingen moeten worden opgepikt, dus geef het tijd voordat je iets kapot verklaart.
Wijzen de records naar je host, dan vraagt een platform meestal automatisch een certificaat aan. Controleer of de onbeveiligde variant doorverwijst en of met en zonder www op dezelfde plek uitkomen.
Voor het toetsen van een idee is de eenvoudigste hosting bijna altijd genoeg.
Deze keuze weegt in deze fase minder zwaar dan hij lijkt. Zolang je een idee toetst, kijken er een handvol mensen mee. Vrijwel elk platform trekt dat, en overstappen blijft te doen zolang code en data van jou zijn. Wat een prototype aankan staat in hoeveel gebruikers kan een prototype aan.
De keuze telt wel zodra er echte gebruikers en echte data bij komen. Dan wil je back-ups die je hebt uitgeprobeerd, een plan waar je gebruik binnen past, iemand die merkt dat het stilligt, en zicht op de maandlasten. Dat laatste is een optelsom van kleine posten, en welke staat in de terugkerende kosten van een eigen app.
Wat wij doen zit bewust vóór dat moment. In één werkdag leveren we een klikbaar prototype op een bereikbaar adres, zodat je het kunt voorleggen. We bouwen geen productieplatform en nemen geen beheer over.
Op een hostingplatform waar je je repository aan koppelt. Het bouwt de applicatie, zet hem op een adres met certificaat en rolt elke wijziging die je pusht automatisch opnieuw uit.
Dat verschilt per aanbieder en per plan, en tarieven veranderen. Kijk op de prijspagina van de partij die je overweegt. Reken op een optelsom: hosting, database, domein, e-mail en monitoring.
Vaak wel, met beperkingen. Gratis plannen leggen een applicatie in slaap bij weinig verkeer, de schijf is vluchtig, gratis databases worden gepauzeerd of opgeruimd en back-ups ontbreken vaak. Sommige staan geen commercieel gebruik toe.
Waarschijnlijk staat het op een plan dat de applicatie stillegt bij weinig verkeer. De eerste bezoeker wacht dan tot hij opstart. Niet stuk dus, alleen stilgelegd. Open hem zelf even voordat je de link deelt.
Niet vanzelfsprekend. Wat de applicatie naar de schijf schrijft verdwijnt bij de volgende uitrol of herstart, dus data hoort in een aparte database. Gratis databases kennen vaak een pauze bij inactiviteit of een vaste levensduur.
Als je iets draait dat niet in het model van een platform past: processen die lang doorlopen, software die je zelf wilt installeren, of eisen over waar data staat. Je krijgt er terugkerend beheer bij.
Deze pagina gaat over waar je een werkend prototype neerzet en hoe je het bereikbaar houdt. Van prototype naar productie gaat over de bredere vraag of software klaar is voor echte gebruikers: authenticatie, beveiliging, testen en onderhoud.
Stuur ons je idee. Wij leveren in één werkdag een klikbaar prototype op een adres dat je kunt delen, zodat je de flow kunt voorleggen voordat je in hosting en onderhoud investeert.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.