ITonFire Platform

Probleem

Elke opdrachtgever stelt op enig moment dezelfde vraag, meestal niet hardop: wat als jij er straks niet meer bent? Dat is een terechte vraag. Maatwerksoftware in een kernproces is nu eenmaal een afhankelijkheid, en het verschil zit erin of die afhankelijkheid bij een persoon ligt of bij iets wat overdraagbaar is.

Op mijn eigen platform kan ik dat niet op iemand anders afschuiven. Deze site en de interne tools waarmee ik mijn werk doe, draaien er allebei op. Als ik hier kortetermijnkeuzes maak, heb ik daar zelf jarenlang last van.

Aanpak

Ik werk met duidelijke kaders en een vaste set bouwblokken. Dat klinkt saai en dat is het ook, maar het is precies waarom ik er maanden later nog snel iets in kan wijzigen zonder eerst te moeten uitzoeken hoe het ook alweer in elkaar zat.

Wat ik bewust niet doe, zegt net zoveel. Geen framework van het moment, want gereedschap kies ik op levensduur en niet op nieuwswaarde. Geen eigen abstractielagen waar de standaard prima volstaat, want elke eigen laag is weer een handleiding die iemand anders moet lezen. En geen vendor lock-in.

Dezelfde uitgangspunten gebruik ik bij opdrachtgevers. Broncode en eigenaarschap liggen daar bij hen, vanaf dag één. In de documentatie staat waarom iets zo gebouwd is, niet alleen hoe het werkt. En omdat ik in werkende stappen oplever, kun je op elk moment stoppen met iets bruikbaars in handen.

Resultaat

Ik kan sneller itereren op content en tooling zonder ruis in de codebase, en het platform kan meegroeien zonder dat de complexiteit zich opstapelt.

Belangrijker vind ik wat het over mijn werk zegt. Je koopt bij mij geen code. Je koopt iets waar over vijf jaar nog iemand mee verder moet kunnen, misschien wel zonder mij. Hoe ik mijn eigen fundament heb neergezet, is de eerlijkste indicatie van hoe ik dat bij jou zou doen.