Een website mag je elke twee jaar weggooien, een webapplicatie niet

Er is een advies dat je overal leest: bouw je website zo dat hij over vijf jaar nog werkt. Ik snap waar het vandaan komt, maar het gooit twee heel verschillende dingen op één hoop. Een website en een webapplicatie zijn niet hetzelfde soort ding, en de regels die voor de een gelden zijn voor de ander vaak verkeerd advies.

Laat ik meteen zeggen welke kant ik op wil. Een website mag je best elke twee jaar opnieuw bouwen. Een webapplicatie moet je zo opzetten dat je hem na vijf jaar niet opnieuw hoeft te bouwen. Dat lijkt tegenstrijdig, tot je kijkt naar wat die twee eigenlijk doen.

Een website is een etalage

Een website is grotendeels presentatie. Tekst, beeld, een paar formulieren, een structuur die mensen door je verhaal leidt. De architectuur daarachter is eenvoudig, en als het goed is gebouwd is het ook weinig werk om hem te vervangen. De inhoud is het waardevolle deel, en die inhoud verhuist mee.

Daarom is het geen ramp om er om de zoveel jaar iets nieuws neer te zetten. Je bedrijf verandert, je aanbod scherpt aan, wat je twee jaar geleden op je homepage zette klopt niet meer helemaal. Een verse etalage is dan gewoon nuttig. Het wordt pas een probleem als die verbouwing telkens duizenden euro’s kost en maanden duurt, en dat is meestal een teken dat de site technisch te zwaar was voor wat hij moest doen.

Waar ik wel op let bij een website is eigendom. Domein, hosting, code en content moeten van jou zijn, en je moet er zelf bij kunnen. Dat heeft niets met levensduur te maken en alles met vrijheid om te kunnen vertrekken.

Een webapplicatie is iets anders

Software waar mensen in werken groeit. Er komt functionaliteit bij, er komen gebruikers bij, er komen koppelingen bij die je bij de start niet had bedacht. Alles wat je in het begin verkeerd neerzet, draag je jarenlang mee en het wordt elk jaar duurder om aan te passen.

Dat is precies waar het bij veel projecten misgaat. Men bouwt een applicatie alsof het een website is, snel en zonder veel structuur, en na drie of vier jaar is elke wijziging een risico geworden. Op dat moment hoor je iemand zeggen dat het tijd is om alles opnieuw te bouwen. Dat had voorkomen kunnen worden, en niet door slimmer te zijn, maar door aan het begin een paar saaie beslissingen goed te nemen.

Hoe dat er bij ons uitziet

Ik bouw en draai Altrady, een platform voor cryptohandel, en Coinray, de marktdata-API die eronder ligt. Altrady gebruikt de API’s van Coinray, en dat is geen toeval maar de belangrijkste architectuurkeuze die we ooit hebben gemaakt.

Door de marktdatalaag in Coinray te scheiden van de bedrijfslogica in Altrady, waar de bots en de handelsautomatisering draaien, heeft Altrady te maken met één API-contract. Eén. Daarbinnen werken we met de eenvoudige ordertypes die beurzen nu eenmaal aanbieden, en daarmee bouwen we de complexere automatisering zelf op.

Dat klinkt abstract, dus hier is wat het in de praktijk oplevert. Coinray biedt één uniforme API naar alle beurzen toe, en omdat we aan de beurskant maar een beperkt aantal dingen nodig hebben, past het overgrote deel van de beurzen gewoon binnen dat contract. Een nieuwe beurs toevoegen is daardoor veel minder werk dan je zou verwachten, en het blijft schaalbaar naarmate er meer bij komen. Verdwijnt er een beurs, dan hoeft er in Altrady niets te veranderen en valt de applicatie er ook niet over om.

Vergelijk dat met de variant waarin elke beurs rechtstreeks in de applicatie is geknoopt. Dan is elke toevoeging maatwerk, elke verandering aan de kant van een beurs een storing, en elke verwijdering een verbouwing. Dat is het soort applicatie waarvan na vijf jaar wordt gezegd dat hij niet meer te onderhouden is.

Wat je scheidt aan het begin, hoef je later niet uit elkaar te trekken terwijl het draait.

Wat ik zelf anders zou doen

Architectuur is niet het enige dat je jarenlang meedraagt. Er is een beslissing uit de begintijd van Altrady die me meer moeite heeft gekost dan welke technische keuze ook.

Altrady is ontstaan uit een probleem dat bestaande gebruikers hadden. Ik kende die mensen, ik kende het probleem, en ik heb ze de oplossing gegeven. Dat werkte, want zij hoefden niet overtuigd te worden van iets wat ze dagelijks voelden.

Jaren later komt er een heel andere groep binnen. Nieuwe gebruikers die dat probleem nog niet kennen, of niet weten dat ze het hebben. Die openen de applicatie en zien een oplossing zonder de vraag waar hij bij hoort. We hebben daarna veel tijd moeten steken in onboarding om dat recht te trekken, en dat had ik vanaf het begin mee moeten nemen.

De les die ik eruit haal, en die volgens mij breder geldt dan software: los het probleem op voor de groep die je nu hebt, maar richt je product niet zo in dat de veel grotere groep die je nog niet kent zich er buitengesloten voelt. Die tweede groep is degene die je groei bepaalt.

Wat dit voor jou betekent

Als je een website laat maken, maak je vooral geen dure fouten door hem klein en eenvoudig te houden. Opnieuw bouwen is geen falen, het is onderhoud van je etalage.

Als je een applicatie laat bouwen waar je bedrijf op gaat draaien, zijn het de scheidingen die je aan het begin aanbrengt die bepalen wat er over vijf jaar mogelijk is. Dat is een gesprek dat je beter vooraf voert dan achteraf, want achteraf heet het een migratie.

Twijfel je in welke categorie jouw plan valt, dat is vaker onduidelijk dan mensen denken. Leg het eens voor. Ik zeg je eerlijk of het iets is dat je over twee jaar rustig kunt vervangen, of iets waar je nu beter even over na kunt denken.