Hoe Divtag werkt: van probleem naar werkende software
Maatwerksoftware laten bouwen roept één grote vraag op: hoe werkt dat eigenlijk? Bij Divtag beginnen we altijd bij het probleem, niet bij de technologie. Dit is wat je als MKB-directeur of operations manager op elk moment van het traject kunt verwachten.
In dit artikel:
Veel MKB-bedrijven lopen op een gegeven moment vast in hun eigen processen. Medewerkers voeren gegevens dubbel in, offertes kosten uren, systemen praten niet met elkaar en de Excel-sheets worden onbeheersbaar. De vraag is dan niet of er een softwareoplossing nodig is, maar welke, en hoe je daar op een verstandige manier bij uitkomt. Hieronder leggen we stap voor stap uit hoe een traject bij Divtag verloopt, en wat je op elk moment kunt verwachten.
Wat gebeurt er tijdens de intake bij Divtag?
Een goed softwaretraject begint niet met een technisch voorstel. Het begint met een gesprek over je bedrijf. In de intake stellen we eenvoudige, directe vragen: waar loopt het mis, wat kost de meeste tijd, welke fouten worden het vaakst gemaakt, en wat zou er veranderen als dit probleem was opgelost? De intake duurt doorgaans één tot twee uur en levert een concreet beeld op van waar de pijn zit.
Voor jou als directeur of operations manager betekent dat: geen presentatie die je over je heen krijgt, maar een gesprek waarbij jij het woord voert. Wij luisteren, stellen door en proberen te begrijpen wat er werkelijk speelt, ook als dat iets anders blijkt te zijn dan wat je zelf dacht mee te brengen.
Dat lijkt vanzelfsprekend, maar het is in de praktijk zeldzaam. Veel softwarebedrijven beginnen bij de oplossing. Wij beginnen bij het probleem.
Hoe ziet de analyse en probleemomschrijving eruit?
Na de intake leggen we terug wat we hebben gehoord. We beschrijven het probleem in gewone taal, inclusief de impact: hoeveel tijd verlies je nu, welke risico’s zijn er, wat is de wenselijke situatie? Die probleemomschrijving — doorgaans één tot twee pagina’s in heldere taal — wordt de basis van alles wat volgt.
We kijken ook naar de context: welke systemen zijn er al, welke koppelingen zijn nodig, en welke wettelijke of praktische beperkingen spelen mee? Pas als dat helder is, praten we over een oplossing.
Jij leest de probleemomschrijving en geeft aan of die klopt. Dat is geen formaliteit: als we het probleem verkeerd begrijpen, bouw je de verkeerde software. Dat willen we allebei vermijden.
Stap 3: snel een werkend prototype
We bouwen iteratief. Dat betekent dat we niet eerst maanden stil zitten om een perfecte specificatie op te schrijven en daarna in één keer alles te bouwen. We starten zo snel mogelijk met een werkend prototype van de kern van de oplossing. In de meeste gevallen is dat prototype er binnen drie tot zes weken.
Een prototype is geen mooi mockup. Het is echte, werkende software, zij het nog beperkt. Jij kunt ermee klikken, ermee testen en er feedback op geven. Dat maakt het gesprek concreet. Wat op papier logisch leek, voelt in de praktijk soms toch anders. Liever dat ontdekken na drie weken dan na zes maanden.
Kernpunt: door vroeg iets werkends te laten zien, bespaar je als klant tijd, geld en teleurstellingen. Aanpassen in een vroeg stadium kost een fractie van wat het kost als je diep in het traject zit.
Stap 4: iteratieve bouw en feedback
Na het prototype bouwen we in korte cycli, ook wel sprints genoemd. Een sprint duurt doorgaans één tot twee weken, en per cyclus voegen we een afgerond stuk functionaliteit toe. Aan het einde van elke sprint laten we zien wat er is gebouwd, bespreek je wat goed gaat en wat anders moet, en bepalen we samen wat de volgende stap is.
Dit heeft een praktisch gevolg: je ziet de software groeien. Je hoeft niet te vertrouwen op een belofte over een eindresultaat dat je pas over drie maanden ziet. Dat maakt het makkelijker om bij te sturen, en het maakt ons eerlijker: wij kunnen niet zes weken wegblijken en dan verschijnen met iets wat niet klopt.
We bouwen in Laravel, Vue en Inertia. Dat zijn solide, breed gedragen technologieën die goed onderhoudbaar zijn. Geen exotische keuzes die je later aan één leverancier binden.
Hoe dit eruitziet in de praktijk
Stel je bent operations manager bij een logistiek bedrijf en het planningsproces loopt via e-mail en een gedeeld Excel-bestand. In de analyse stellen we vast dat de kern van het probleem zit in de statuszichtbaarheid: niemand weet precies waar een zending is zonder iemand te bellen. In de eerste sprint bouwen we een eenvoudig statusoverzicht waar medewerkers updates in kunnen zetten. Dat is al bruikbaar, al is het systeem nog verre van compleet. In de volgende sprint voegen we notificaties toe, daarna koppelingen met bestaande systemen. Zo groeit de oplossing stap voor stap, en houd je op elk moment het overzicht.
Hoe verloopt de lancering en kennisoverdracht?
Als de software klaar is voor gebruik, begeleiden we de lancering. Dat is meer dan een knop omzetten. We zorgen dat de software stabiel staat, dat gebruikers weten hoe het werkt en dat er een plan is voor als er toch iets misgaat in de eerste weken. Standaard reserveren we minimaal één week voor de begeleiding rondom go-live.
Kennisoverdracht is een onderdeel dat soms wordt overgeslagen, maar dat voor jou als klant bepalend is voor hoe snel de software zijn waarde bewijst. We leggen uit hoe de software werkt, wat de beheerder moet weten en waar de grenzen van het systeem liggen. Geen dikke handleiding die niemand leest, maar gerichte uitleg aan de mensen die ermee werken.
Stap 6: doorontwikkeling en beheer
Software is geen product dat je oplevert en vergeet. Na de lancering monitoren we de prestaties, lossen we bugs op en kijken we samen met je naar hoe de software meegroeit met je bedrijf. Processen veranderen, bedrijven groeien, wetgeving wijzigt. De software moet daarin mee.
In de praktijk werken veel van onze klanten langdurig met ons samen. Niet omdat dat in het contract staat, maar omdat het logisch is: wij kennen de software, kennen het bedrijf en kunnen snel schakelen als er iets moet veranderen.
Dat is wat maatwerksoftware pas echt waardevol maakt: niet het eindproduct bij de lancering, maar het vermogen om mee te bewegen. Standaard software kan dat per definitie niet in dezelfde mate.
Veelgestelde vragen over de Divtag-werkwijze (FAQ)
Hoe lang duurt een gemiddeld softwaretraject bij Divtag?
Wat kost maatwerksoftware laten bouwen?
Wat als ik niet precies weet wat ik nodig heb?
Kunnen jullie ook bestaande software uitbreiden of integreren?
Hoe is de samenwerking na de lancering geregeld?
Plan een vrijblijvend kennismakingsgesprek