Elk traject volgt dezelfde grondgedachte: eerst zien, dan bouwen — met AI als het gereedschap dat er meestal dagen van maakt in plaats van maanden — dan overdragen, telkens ter plaatse en steeds toegesneden op wat er bij u speelt. Is de klus groter, dan verandert enkel de duur, niet de aanpak: aan hetzelfde dagtarief.
De eerste dag begint met meekijken bij de mensen die het werk elke dag doen: hoe komt een bestelling binnen, waar wordt een Excel bijgewerkt, welke stap kost telkens tijd. Daar hoort ook bij: welke systemen er zijn — een boekhoudpakket, een CRM, een planningstool — en welke data erin zit.
Het gaat vooral om waar het wringt: taken die dubbel gebeuren, informatie die nergens samenkomt, iets dat iedereen "op den duur wel eens moet aanpakken" zonder dat iemand er tijd voor vindt. Dat zijn meestal de plekken waar een klein stuk software het meeste verschil maakt.
Tegen het einde van de eerste dag staat een concreet beeld van wat er ligt, met een eerste inschatting van wat de moeite waard is om te bouwen. Dat wordt dezelfde dag nog met u overlopen.
Niet eerst een technologie kiezen en daarna een probleem zoeken dat erbij past — de keuze steunt op drie dingen: hoeveel tijd of fouten een taak vandaag kost, hoe goed de onderliggende data al aanwezig is, en of een oplossing binnen de tijd van het traject echt af te werken is.
Drie voorbeelden komen daarbij het vaakst terug — niet omdat daar de grens ligt, maar als illustratie van hoe snel dat soort werk meestal opgelost is.
Bestelpunten, veiligheidsvoorraad en een ABC-indeling berekend op basis van uw eigen orderhistoriek — geen glazen bol, wel tijdig een seintje wanneer iets dreigt op te raken.
Vooral voor wie vandaag op buikgevoel of een los Excel-bestand bestelt.
Vraagt wel een basis om op te bouwen: ongeveer een jaar bestelhistoriek en gekende levertijden van uw leveranciers.
Gegevens uit leveranciersfacturen en documenten worden automatisch overgenomen in het systeem dat u al gebruikt, zonder manueel overtypen.
Vooral voor wie dezelfde factuur meermaals per week manueel overtypt.
Opvolgflows binnen het CRM of de mailbox die u al gebruikt, zodat een lead niet stilligt omdat niemand tijd vond om te reageren.
Vooral voor wie leads soms pas na dagen — of nooit — een antwoord stuurt.
Als tijdens het traject blijkt dat iets anders meer oplevert dan vooraf afgesproken, wordt dat met u afgestemd — het doel is dat er iets bruikbaars staat, ook als het oorspronkelijke plan daarvoor wat verschuift.
Een werkend prototype overtuigt sneller dan een document — mensen reageren eerlijker op iets waar ze op kunnen klikken dan op een lijst met vereisten. Daarom begint de bouwfase niet met een specificatie schrijven, maar met iets neerzetten en het u laten proberen. Wat werkt, blijft staan; wat niet klopt, wordt zichtbaar voor het duur wordt om het nog recht te zetten.
Zo goed als elke ontwikkelaar gebruikt intussen AI om code te schrijven — dat op zich is geen onderscheid meer. "Iemand leest alles na voor het live gaat" klinkt als een logisch antwoord, maar is bij software van enige omvang al lang geen werkend vangnet meer, met AI geschreven of niet. Veiligheid komt niet uit het nalezen van elke regel. Ze komt uit het systeem eromheen.
Dat begint bij de fundering: wie bij welke gegevens mag, en wat iemand met een bepaalde rol wel en niet kan doen, wordt vroeg en bewust ontworpen — niet halverwege beslist en zeker niet achteraf rechtgezet. Dat laatste is geen gelikte laag toevoegen, maar de fundering opnieuw leggen. Hoe iets eruitziet — kleur, opmaak, stijl — kan wel nog alle kanten op en wordt bewust laat vastgelegd; hoe het werkt en wie wat mag, niet.
Daarnaast krijgt elke toegang zo weinig rechten als voor die taak nodig is: gaat er toch iets mis, dan blijft de schade beperkt tot dat ene stukje, niet het hele systeem.
Werken is niet hetzelfde als veilig zijn. Code die foutloos draait, kan alsnog toegang toestaan aan wie dat niet zou mogen — een gat dat niemand opmerkt tot het misbruikt wordt. Daarom wordt niet enkel getest of iets doet wat het moet doen, maar apart ook of het weigert wat het niet mag toestaan: dat eerste bewijst het tweede niet.
En wat er toch misloopt, blijft niet onopgemerkt en is terug te draaien — zie verderop hoe fouten zichtbaar worden gemaakt in plaats van stil te blijven liggen.
Die combinatie — snel bouwen, met rechten en een datamodel die bewust vroeg vastliggen, en één iemand die op elk moment weet wat de software doet, hoe ze draait, wat ze aanraakt en hoe ze beveiligd is — is wat dit tempo veilig maakt in plaats van roekeloos.
Bij de oplevering hoort een uitleg voor de mensen die het gaan gebruiken: waar de code of configuratie staat, hoe iets aan te passen is, en wat te doen als er iets stukgaat. Documentatie die u en uw team ook echt zelf begrijpen.
Het doel is dat uw eigen mensen — of uw bestaande IT-partner, als u die heeft — het verder kunnen dragen zonder Kufu erbij te moeten roepen. Wilt u toch verder bouwen, dan kan dat via losse dagen, zonder dat daar een nieuw traject voor nodig is.
De meeste mensen die snel bouwen met AI, kunnen het resultaat niet in productie houden; de meeste mensen die productie kunnen laten draaien, bouwen niet snel. Kufu doet allebei: zeventien jaar ondernemen, en vandaag nog zelf de firmware, het cloudplatform en de app van Veton bouwen en beheren. Software die na een paar maanden stilvalt zonder dat iemand het merkt, is erger dan geen software — het wekt intussen wel de indruk dat het werk nog gebeurt. Daarom is wat er na de overdracht gebeurt geen bijzaak, maar een vast onderdeel van elk traject.
Fouten zijn luid, niet stil. Elk stuk software krijgt een zichtbaar signaal zodra het stopt of iets tegenkomt dat het niet kan verwerken — een e-mail of bericht naar een vaste persoon, in plaats van gewoon zwijgend fout te lopen. Software die stil faalt is erger dan geen software: dan weet u tenminste dat u het zelf nog moet doen.
Het draait op infrastructuur die van u is. Waar mogelijk werkt de software gewoon binnen uw mailbox, CRM, ERP-systeem of een automatiseringsplatform dat u al betaalt.
Heeft het een eigen plek nodig om te draaien, dan draait het in een container — denk aan een verplaatsbare, afgesloten doos met alles erin wat het nodig heeft — op een klein, betaalbaar servertje dat u zelf rechtstreeks betaalt (bijvoorbeeld bij DigitalOcean, meestal enkele tientallen euro's per maand), of op uw eigen server als u die al heeft. Geen duur abonnement bij een grote cloudleverancier waar u vast aan zit, en geen afhankelijkheid van Kufu: omdat het in een container zit, kan het zo verhuizen naar een andere provider, naar uw eigen infrastructuur, of naar wie het daarna beheert. U houdt zelf de toegang en de rekening in handen.
Zo'n servertje vraagt wel af en toe gewoon onderhoud — een update van het besturingssysteem, een beveiligingspatch, een herstart. Dat kan uw eigen IT-persoon of -partner: het is bewust gewone, gangbare technologie, geen nodeloze complexiteit. En het is precies waarvoor Losse dagen ook bedoeld zijn: een dag tegen het vaste dagtarief wanneer het toch eens echt werk vraagt.
Er is een vaste, interne eigenaar. Wie dat is, wordt voor het vertrek met u afgesproken, en de overdrachtsdocumentatie is voor die persoon geschreven: wat de software doet, wat ze activeert, hoe het eruitziet als ze stuk is, en wat de eerste dingen zijn om te controleren.
Dingen verschuiven. Een leverancier wijzigt het formaat van een factuur, een systeem waarop een koppeling steunt wordt bijgewerkt, iemand die de software kende verlaat het bedrijf. Dat hoort bij automatisering, niet bij slecht werk — en het is precies waarvoor Losse dagen bedoeld zijn.
Eén vast aanspreekpunt bij u, die de dagen mee inplant en tijdens het traject bereikbaar is voor vragen — niet noodzakelijk de eigenaar of directie, wel iemand die het werk en de systemen kent.
Toegang tot de systemen en data die relevant zijn: een login voor het boekhoudpakket, een export uit het CRM, of gewoon iemand die over de schouder kan meekijken bij hoe een proces vandaag loopt.
En tijd van de mensen die het werk zelf doen — niet de hele dag, maar wel genoeg om vragen te beantwoorden en het resultaat samen te testen vóór de oplevering.
Niet elk stuk software heeft een AI-model nodig — een deel van het werk is gewone software, zonder dat er data naar een taalmodel gaat. Waar dat wel het geval is, gaat dat nooit via een persoonlijk consumentenaccount voor bedrijfsgegevens, maar altijd via een provider waarmee een verwerkersovereenkomst is afgesloten. Werkt u vandaag al met een AI-tool waarvoor dat niet geregeld is, dan wordt dat eerst met u besproken, voor het traject daarop verder bouwt.
Uw gegevens worden niet gebruikt om modellen te trainen, en blijven binnen de software die voor u gebouwd wordt — niet hergebruikt voor iets anders, ook niet voor een ander traject.
Verwerkt software voor u persoonsgegevens van uw eigen klanten — zoals bij automatische lead- en e-mailopvolging, waar namen, e-mailadressen en gespreksinhoud bij komen kijken — dan is Kufu daarvoor de verwerker, en blijft u de verwerkingsverantwoordelijke. Voor dat werk start, komt er een verwerkersovereenkomst: naast de geheimhoudingsovereenkomst, niet in de plaats ervan.
Toegang tot uw systemen blijft minimaal en tijdelijk: enkel wat nodig is om het traject uit te voeren, niet langer dan de duur ervan. Een geheimhoudingsovereenkomst tekenen is geen probleem.
Een half uur is genoeg om te weten of Kufu iets voor u kan betekenen.