Een applicatie op maat is zelden ingewikkeld op zichzelf. Wat ze lastig maakt is dat ze past bij hoe een organisatie echt werkt, ook op de plekken waar dat niet logisch is. Hieronder staat hoe zo iets in elkaar zit en welke keuzes het dragen.
Zelden omdat een pakket lelijk is. Wel wanneer je proces net anders loopt dan dat van de rest, en wanneer dat verschil is waar je klanten voor komen. In een kringwinkel is dat dat elk stuk uniek is. Bij een organisatie met veel vestigingen is dat dat elke vestiging net iets anders werkt. Dwing je zo iets in een pakket, dan betaal je het terug in handwerk, in exports, en in een schaduwadministratie in een spreadsheet.
Het omgekeerde komt ook voor, en dan zeg ik het. Wie een webshop wil, moet geen webshop laten bouwen. Wie een boekhouding wil, al helemaal niet. Maatwerk hoort te zitten op het stuk dat van jou is, en aan te sluiten op standaardpakketten voor al de rest. Dat is dan ook waar de meeste van mijn opdrachten over gaan: niet alles zelf bouwen, maar het eigen stuk bouwen en de rest eraan knopen.
Zes lagen die in bijna elk project terugkomen, van het model onderaan tot de uitrol bovenaan.
De tabellen en de begrippen in de code heten zoals het in jouw huis heet: een vestiging, een dossier, een rit. Dat leest niet alleen prettiger, het voorkomt ook de vertaalfouten die ontstaan wanneer iemand later iets moet aanpassen.
Een mail versturen, een pdf maken, een export ophalen: dat hoort in een wachtrij en niet in het scherm van de gebruiker. Een taak die mislukt, probeert het opnieuw; een taak die blijft mislukken, komt op een lijst en niet in de vergetelheid.
De meeste maatwerkapplicaties worden de hele dag door dezelfde vijf mensen gebruikt. Dan telt snelheid van bediening zwaarder dan mooi: toetsenbord, korte paden, en een lijst die onthoudt waar je gefilterd stond.
Een duw op de knop zet de site in onderhoud, brengt de bestanden over, draait de migraties en zet hem weer open. Herhaalbaar, dus ook terug te draaien, en niemand hoeft te onthouden in welke volgorde het moest.
Btw-validatie, Cloudflare Turnstile, een rechtenmodel, een gebruikersnaamgenerator: wat in twee projecten hetzelfde bleek, staat op Packagist. Een composer require in plaats van een map die je meeneemt.
Niet wat een stuk code doet, dat staat er al, maar waarom het zo staat. Welke afweging eronder zat, welke weg eerst geprobeerd werd, wat er breekt als je het omdraait. Dat is het enige wat een opvolger niet kan afleiden.
Vijf uitgangspunten, waarvan de laatste de enige is waar ik niet van afwijk.
Is er een pakket dat doet wat jij doet, koop het. Maatwerk verdient zichzelf terug wanneer je proces net anders is dan dat van iedereen en dat verschil je bestaansreden is. Is het verschil enkel gewoonte, dan bouw je een duurdere versie van iets dat bestaat, en dat zeg ik dan ook.
Schermen worden herbouwd, frameworks wisselen, maar de gegevens blijven. Een model dat klopt, met sleutels die verwijzen naar wat ze beweren, is de investering die het langst meegaat. Een model dat van bij het begin scheef staat, sleep je jaren mee in de vorm van uitzonderingen.
Bijna elke applicatie die traag is, is dat door de databank: een query per rij in een lijst, een ontbrekende index, of een lijst die alles ophaalt om er tien te tonen. Dat is meestal op een namiddag te vinden en te herstellen, en het scheelt meer dan welke zwaardere server ook.
De vraag is niet of ik het kan onderhouden maar of iemand anders het kan overnemen. Dat betekent de gebaande weg van het framework volgen waar het kan, en afwijken enkel waar het moet, met een uitleg erbij. Slimme constructies zijn leuk om te schrijven en duur om te erven.
De server, het domein, de repository, de accounts bij leveranciers: die staan van bij de start op jouw naam, en ik krijg toegang. Stopt de samenwerking, dan is dat een toegang intrekken en geen verhuizing. Dat hoort geregeld te zijn voor er iets gebouwd wordt, en niet erna.
Het eerste gesprek duurt hooguit een uur en kost niets. Daarna volgt een voorstel met een prijs en een termijn, of de vaststelling dat je beter af bent met iets dat al bestaat. Dat tweede antwoord komt vaker dan je zou denken. Stuur gerust een bericht.
Wat er zoal uit kwam staat bij het portfolio en de case studies, de losse pakketten bij de Laravel packages, en de laag eromheen bij het designsysteem en de koppelingen.