De theorie achter Product Printer
Software is geen ambacht meer. Het is een techniek.
Zeventig jaar lang werd software gebouwd zoals meubels in een werkplaats — één vakman, één stuk, alles met de hand. Dat tijdperk is net voorbij. Als code schrijven goedkoop wordt, verschuift de waarde naar het plan, de onderdelen en de productielijn. Daarom bouwen wij als een fabriek.
Van ambacht naar techniek
De kosten van code schrijven zijn ingestort
AI-agents schrijven vandaag het grootste deel van de code. Het dure middenstuk van elk softwareproject — de implementatie uittypen — werd bijna van de ene op de andere dag het goedkoopste deel. Ons doel: wat een team een kwartaal kostte, levert een begeleide productielijn in een week.
De meeste software is een opgelost probleem
Inloggen, facturatie, multi-tenancy, talen, monitoring: elke bedrijfsapplicatie heeft ze nodig en geen ervan verdient het opnieuw uitgevonden te worden. Het zijn standaardonderdelen — catalogusartikelen, geen ontwerpwerk.
Wat schaars blijft, is het probleem zelf
Een fietsenwinkel, een verhuurvloot, een zorgdienst begrijpen — en het juiste specificeren. Daar horen mensen thuis. Alles na een goede specificatie kan worden geïndustrialiseerd.
Een ambacht wordt een techniek zodra de stappen opgeschreven, herhaald en gecontroleerd kunnen worden. Software is die lijn net gepasseerd — en zodra iets techniek is, wint de fabriek van de werkplaats.
De lijn, station voor station
Van de eerste training tot draaiende software, station voor station. Elk station is gemarkeerd: Live draait vandaag; Komt bouwen we als volgende.
01Live
Het begint met training
Vóór de lijn komen mensen: adviseurs leren mkb’ers te adviseren over AI en trainen daarna de teams van hun klanten met een white-label cursus waarvan de laatste stap een nieuw project of nieuwe requirements wordt.
Meer weten02Live
Requirements eerst
Niets wordt gebouwd op basis van een vage briefing. Een gesprek wordt requirements, elk met zijn acceptatiecriteria, en de lijn bouwt alleen wat is geaccepteerd.
03Live
Een doorlopende lijn
Zodra zijn requirements zijn geaccepteerd, gaat een workstep zonder klik naar een coding-agent: één build tegelijk per project, op volgorde. Elke workstep verlaat de lijn als pull request.
04Live
Poorten bij elke wijziging
Elke pull request doorloopt de CI en de security-scans van het project, daarna een AI-securityreview die bij twijfel blokkeert: geen oordeel, geen merge, en de merge is vastgepind op precies de beoordeelde versie. Een bewaker op de main-branch weigert alles te deployen wat om de poorten heen ging.
05Live
Bewijs per criterium
Elk acceptatiecriterium krijgt zijn eigen testrun van CI, geregistreerd nadat de laatste wijziging van de vereiste is samengevoegd, en een vereiste telt pas als geverifieerd wanneer ze allemaal slagen. Een criterium dat door een persoon wordt gecontroleerd, toont “Menselijke controle in afwachting” totdat het wordt goedgekeurd. Het woord van de agent telt nooit.
06Live
Eerst de test, van rood naar groen
De test voor elk acceptatiecriterium wordt eerst geschreven, in een eigen commit, en moet falen in CI voordat de code hem laat slagen. Voordat een wijziging wordt samengevoegd, controleert de gate dat de test van elk criterium van rood naar groen ging en onderweg niet is gewijzigd; de vereiste koppelt beide runs.
07Live
Een herstellus
Wijzen de CI of de securityreview een wijziging af, dan gaan de bevindingen terug naar dezelfde agentsessie, die ze in dezelfde pull request herstelt, en elke poort draait opnieuw. Standaard hoogstens twee herstelpogingen; daarna neemt een mens het over.
08Live
Standaardonderdelen
Elke app start vanuit het fabriekssjabloon, met de opgeloste problemen er al in: inloggen, tenants en rollen, juridische pagina’s, layout. Eén keer gebouwd, in productie gehard, nooit opnieuw gebouwd.
09Live
De fabrieksbibliotheek bij elke stap
Wordt een workstep-plan goedgekeurd, dan krijgt elke workstep de standaardonderdelen die het ontwerp koos. Worksteps die de database of andere gevoelige delen raken, worden gebouwd met de security- en databaserichtlijnen van de bibliotheek, en het buildverslag vermeldt welke en waarom.
10Live
Van release naar live
Een gepubliceerde release zet een gehoste app in productie: eerst de databasemigraties, op volgorde, met stop bij de eerste fout; dan de build. De release toont pas Live als het live-adres hem serveert.
11Live
Een eerlijke stand
Tot alles binnen de scope is gereleased, toont een project ‘In aanbouw — 3 van 6 worksteps geleverd’, en pas daarna ‘Live’. Een nieuwe app toont bezoekers ‘Binnenkort’ en zijn ingelogde gebruikers de bouwstappen; een pagina ‘Wat er in de app zit’ toont de meegeleverde onderdelen, wat is gebouwd en wat nog komt.
12Live
Alles vastgelegd
Elke buildjob, elke release-deploy en elke wijziging die de main-branch buiten de poorten om bereikte, wordt vastgelegd. Onze operatoracties gaan naar een auditlog waaraan alleen kan worden toegevoegd.
13Live
Beperkte sleutels, EU-hosting
Voor apps die wij hosten, krijgt elke build een kortlevend token voor die ene repository, gewist zodra de build klaar is. Uw modelsleutels blijven bij uw PP Orchestrator. Cloud-instanties draaien in Duitsland (EU).
‘Live’ betekent: geleverd in een release van Product Printer en draaiend op onze beheerde instanties. Een station gaat pas van ‘Komt’ naar ‘Live’ als zijn release daar draait.
Het tijdperk van de werkplaats was mooi. Het tijdperk van de fabriek is betaalbaar.
— Cut the noise.
Kom met uw probleem →