Iedereen die het vak kent, kent het project: een nieuwe ontwikkelaar begint, "even lokaal draaien" kost drie dagen, de README verwijst naar een collega die vorig jaar vertrok en de enige werkende configuratie staat op één laptop. De misvatting is dat dit er nu eenmaal bij hoort bij maatwerk. Dat hoort het niet. Hoe lang het duurt voordat iemand die het project nooit zag zijn eerste wijziging kan maken, de time-to-first-commit, is een kwaliteitsmaat, en wij sturen erop bij alles wat we bouwen.
Dit is een opdrachtgeversprobleem
Time-to-first-commit klinkt als comfort voor ontwikkelaars, maar de rekening ligt bij de opdrachtgever:
- De bus factor — als één persoon het project kan draaien, heb je geen leverancier maar een gijzeling met goede bedoelingen. Vakantie, ziekte of vertrek van die ene persoon is dan meteen jouw risico.
- Elke wisseling kost dagen — inwerktijd is betaalde tijd die niet aan je product wordt besteed, bij ons én bij elke partij na ons.
- Incidenten wachten niet — een storing oplossen begint met het project kunnen draaien. Elke dag opzettijd zit vóór de eerste regel van de fix.
- Een second opinion wordt onmogelijk — wie een offerte bij een ander wil, ontdekt dat "het project overdragen" zelf een project is.
Wat wij opleveren zodat dag één ook echt dag één is
- Eén beschreven route omhoog — de omgeving wordt opgebouwd uit wat er in de repository staat, met één commando of één kort, kloppend stappenplan. Geen mondelinge overlevering, geen "vraag even aan…".
- Seed-data — een ontwikkeldatabase met realistische, geanonimiseerde vulling. Een lege applicatie oogt werkend en verbergt alles; met echte aantallen en randgevallen zie je meteen wat er speelt.
- Configuratie zonder geheugenwerk — instellingen staan expliciet in het project, met een voorbeeldconfiguratie in de repository en secrets op een afgesproken plek. Niets leeft alleen in iemands hoofd of shell-history.
- Documentatie die niet kán verouderen — de omgevingsbeschrijving is niet een document óver het project maar een onderdeel ván het project: dezelfde beschrijving waarmee de ontwikkelaar lokaal start, gebruikt ook de uitrol. Documentatie die dagelijks wordt uitgevoerd, blijft vanzelf waar.
De verse machine liegt niet
De enige eerlijke meting is een machine zonder voorgeschiedenis. Op de laptop van de bouwer werkt het altijd; daar staan de vergeten afhankelijkheden immers al jaren. Daarom is onze CI-pijplijn meer dan een testloper: elke wijziging wordt gebouwd en getest op een omgeving die van nul opkomt. Als de pijplijn het project zonder voorkennis kan draaien, kan een nieuwe ontwikkelaar het ook; en als de pijplijn ergens handwerk nodig zou hebben, is dat precies de plek waar het project stiekem op geheugen draait.
Wat je ervan merkt
Weinig, en dat is het punt. Doorontwikkeling stokt niet op wie er toevallig beschikbaar is, een spoedfix begint bij de fix in plaats van bij de opzet, en als je ooit met een andere partij verder wilt, krijg je een project mee dat overdraagbaar ís in plaats van een doos met onderdelen. Net als error tracking is dit geen extraatje op de offerte, maar de standaardvorm van wat wij opleveren.
Benieuwd hoe jouw project ervoor staat?
Een eerlijke eerste toets kost een middag: zet iemand die het project niet kent achter een verse machine en klok hoe ver hij komt. Valt dat tegen, of wil je dat wat wij bouwen of overnemen hier vanaf dag één aan voldoet: neem contact op, dan kijken we waar de opzettijd nu in gaat zitten.