Software laten maken: zo verloopt het traject van idee tot livegang

Datum
16 september 2026
Auteur
Isatis Group
Categorie
Tips
Leestijd
8 min lezen

Software laten maken begint bij een goede voorbereiding. Zo verloopt het traject van offerte tot bouw, livegang en beheer, plus de drie samenwerkingsvormen.

Het idee bestaat vaak al maanden: een portaal voor klanten, een app voor monteurs of een systeem dat drie spreadsheets vervangt. De stap daarna is lastiger. Software laten maken doe je als organisatie hooguit een paar keer, en bij de eerste keer is het traject onbekend terrein.

Software laten maken betekent dat een gespecialiseerde partij een applicatie voor jouw organisatie ontwerpt, bouwt en daarna meestal ook beheert. Jij brengt de kennis van je processen in en neemt de beslissingen; de partner levert het team en het vakmanschap. Het traject loopt van voorbereiding en offerte via de bouw naar livegang en beheer.

In dit artikel lopen we dat hele traject door: wat je zelf voorbereidt, hoe je een partij kiest, wat er tijdens de bouw van jou wordt gevraagd en uit welke drie samenwerkingsvormen je kunt kiezen. Na het lezen weet je wat je te wachten staat en waar jouw eigen inzet het verschil maakt.

Eerst de afweging: maatwerk of een standaardpakket

Voordat je een partij benadert, controleer je eerst of er al een pakket bestaat dat jouw proces goed ondersteunt. Voor boekhouding, urenregistratie en personeelszaken is kopen vrijwel altijd sneller en voordeliger dan bouwen. Maatwerk komt in beeld zodra het proces jouw organisatie onderscheidt, pakketten steeds net tekortschieten of meerdere systemen slim moeten samenwerken.

Op onze pagina over maatwerksoftware laten ontwikkelen lees je wanneer bouwen loont en wanneer een pakket volstaat. Maak die afweging eerlijk, want een passend pakket bespaart je maanden. De rest van dit artikel gaat over de route waarin je kiest voor bouwen.

Software laten maken begint bij je eigen voorbereiding

De voorbereiding is het meest onderschatte deel van het traject. Een technisch document hoef je niet te schrijven; één A4 met vier onderdelen maakt elk gesprek dat volgt scherper en elke offerte beter vergelijkbaar.

  • Het probleem. Beschrijf wat er vandaag misgaat en wat dat kost aan tijd, fouten of klanten. Hoe concreter, hoe beter: "elke ritwijziging kost een telefoontje" zegt meer dan "de communicatie kan beter".
  • Het doel. Maak het meetbaar: minder telefoontjes per dag, een kortere doorlooptijd per order of minder fouten per week. Dit getal bepaalt later of het project geslaagd is.
  • De gebruikers. Benoem wie er straks dagelijks mee werkt en betrek een paar van hen al bij de voorbereiding. Zij kennen de uitzonderingen die in geen enkel proceshandboek staan.
  • Het systeemlandschap. Som de systemen op waarmee de software moet samenwerken, zoals je ERP of je boekhoudpakket, en noteer wie daar binnen je organisatie de kennis van heeft.

Karin, operationeel manager bij een transportbedrijf met 70 chauffeurs, zette deze vier punten op één A4 voordat ze bureaus benaderde. Het probleem: ritwijzigingen bereiken chauffeurs te laat, met gemiddeld twaalf telefoontjes per dag als gevolg. Het doel: elke wijziging binnen een minuut op de telefoon van de chauffeur. De gebruikers: vier planners en 70 chauffeurs. Het landschap: een planningspakket en het boekhoudsysteem. De drie offertes die ze later ontving, waren daardoor voor het eerst echt vergelijkbaar, omdat elk bureau van dezelfde uitgangspunten vertrok.

Bepaal tot slot wat er buiten de eerste versie mag blijven. Een kleine eerste versie die één kernproces oplost, leert je meer dan een compleet pakket van eisen. In wat is een MVP lees je hoe je die scope bepaalt.

Een partij kiezen om je software te laten ontwikkelen

Met je A4 op zak maak je een shortlist van drie bureaus. Let daarbij vooral op continuïteit: wie bouwt de software, wie beheert hem straks, wie is eigenaar van de code en hoe wordt kennis binnen het team gedeeld. De negen vragen die het verschil blootleggen tussen een goede presentatie en een goede partner, vind je in hoe je een softwarebedrijf kiest.

Daarna volgt het offertetraject, en dat is meer dan een prijs opvragen. Een serieuze partij begint met een verkennend gesprek over je probleem, je doel en je systemen. Vaak volgt een tweede sessie waarin het bureau doorvraagt bij de mensen die het werk dagelijks doen. Pas daarna komt er een voorstel, soms met een klein betaald vooronderzoek als de opgave complex is.

Een goede offerte beschrijft de aannames, de scope per fase, wat erbuiten valt en wat beheer na de livegang kost. Staat er alleen een totaalbedrag en een opleverdatum, dan heb je te weinig houvast om te vergelijken. Welke factoren dat bedrag bepalen, lees je in wat maatwerksoftware kost. Reken op enkele weken tussen het eerste gesprek en een offerte die je serieus kunt beoordelen; een voorstel dat een dag na het eerste gesprek in je mailbox ligt, is zelden doordacht.

Jouw rol tijdens de bouw

Na de handtekening begint de bouw, meestal in korte cycli van twee tot drie weken volgens de werkwijze die bekendstaat als agile softwareontwikkeling. Elke cyclus eindigt met een demo van werkende software. Het bureau doet het bouwwerk, en toch bepaalt jouw inzet voor een groot deel het resultaat. Drie dingen worden van je gevraagd.

  • Beslissingen nemen. Wijs één productowner aan: iemand uit je eigen organisatie die de prioriteiten bepaalt en knopen doorhakt. Elke vraag die dagen blijft liggen, vertraagt het team of dwingt het tot aannames.
  • Testen met echte gebruikers. Woon elke demo bij en laat de mensen die er straks dagelijks mee werken elke versie proberen. Zij zien binnen een kwartier wat er in de praktijk wringt.
  • Een vast feedbackritme. Reserveer een vast aantal uren per week voor het project en houd die vrij, ook als het druk is. Feedback die pas na drie cycli komt, is drie keer zo duur om te verwerken.

Ruben, hoofd binnendienst bij een technische groothandel met 45 medewerkers, reserveerde tijdens de bouw van zijn orderportaal elke week vier uur voor het project. Bij de demo in week zes ontdekten twee van zijn medewerkers dat deelleveringen ontbraken in het bestelproces. Dat scenario stond in geen enkel document, omdat iedereen het intern als vanzelfsprekend beschouwde. Het herstel kostte nu drie dagen; na de livegang had het boze klanten en een spoedklus opgeleverd.

Livegang en beheer

De livegang is een project op zich. Plan naast de techniek ook de organisatie: wie leidt de gebruikers op, hoe komen de gegevens uit de oude systemen over en bij wie kunnen collega's in de eerste weken terecht met vragen. Een rustige start werkt vaak het best: eerst één afdeling of regio, daarna de rest. Zo blijven kinderziektes klein en beheersbaar.

Na de livegang begint de langste fase van het traject. Software heeft beveiligingsupdates, monitoring en doorontwikkeling nodig, en gebruikers krijgen nieuwe wensen zodra ze er dagelijks mee werken. Maak daarom vóór de start afspraken over het beheer: wie lost storingen op en binnen welke termijn. Vraag ook wie dat beheer uitvoert. Bij ons zijn dat dezelfde engineers die de software bouwden, zodat de kennis van jouw applicatie behouden blijft.

Drie manieren om software te laten maken

Software laten maken kan in drie samenwerkingsvormen. Welke past, hangt af van je plan en van de kennis die je zelf in huis hebt.

  1. Het project uitbesteden. De partner is verantwoordelijk voor ontwerp, bouw en beheer; jij stuurt via je productowner op prioriteiten. Deze vorm past als je geen eigen ontwikkelaars hebt en één partij verantwoordelijk wilt maken voor het resultaat.
  2. Een developer inhuren. Je huurt één of enkele ontwikkelaars in die onder jouw aansturing werken, bijvoorbeeld om je eigen IT afdeling tijdelijk te versterken. Jij houdt de regie en de kennis blijft in huis. Op onze pagina over een softwareontwikkelaar inhuren lees je hoe dat werkt met engineers in vaste dienst in plaats van freelancers.
  3. Je team uitbreiden. Je hebt al een ontwikkelteam en voegt daar voor langere tijd engineers aan toe die volledig meedraaien in jouw sprints, overleggen en tools. Zo groeit je capaciteit binnen weken in plaats van na maanden werven.

De vormen zijn goed te combineren. Veel organisaties besteden de bouw uit en houden daarna een klein vast team aan voor beheer en doorontwikkeling, of starten met één ingehuurde developer en breiden uit zodra het werk groeit.

Wij ondersteunen alle drie de vormen met één team van 30+ engineers in Nijmegen en Sarajevo, dat in jouw tijdzone en volgens jouw werkwijze werkt. In ruim dertig jaar en 100+ projecten voor zorg, onderwijs, industrie, overheid en energie hebben we geleerd dat de samenwerkingsvorm minder bepalend is dan de mensen: wie bouwt, wie blijft en wie zich eigenaar voelt van het resultaat. We werken volgens ISO 9001 en ISO 27001.

Veelgestelde vragen

Wat kost het om software te laten maken?

De prijs hangt af van de omvang van de applicatie, het aantal koppelingen met bestaande systemen, de complexiteit van de bedrijfsregels, de kwaliteitseisen en het beheer na de livegang. Een bedrag zonder die opgave is een gok. Vraag daarom een offerte met aannames en een scope per fase, zodat je voorstellen echt kunt vergelijken.

Hoe lang duurt het om software te laten ontwikkelen?

Een goed afgebakende eerste versie staat vaak binnen enkele weken tot een paar maanden bij de eerste gebruikers. Daarna groeit de software in cycli van twee tot drie weken verder. De doorlooptijd hangt vooral af van de scope van de eerste versie en van het aantal koppelingen met bestaande systemen.

Wat moet ik zelf regelen als ik software laat maken?

Drie dingen: een productowner die beslissingen neemt, gebruikers die elke versie testen en een vast feedbackritme van enkele uren per week. Zorg daarnaast voor een voorbereiding op één A4 met je probleem, je doel, je gebruikers en je systeemlandschap.

Kan ik beter een project uitbesteden of een developer inhuren?

Uitbesteden past als je geen eigen ontwikkelteam hebt en één partij verantwoordelijk wilt maken voor het resultaat. Een developer inhuren past als je zelf de regie voert en vooral extra capaciteit zoekt. Twijfel je, begin dan klein met een uitbesteed project en bepaal daarna hoe je verder wilt.

Samengevat

Software laten maken is goed te overzien zodra je het traject kent. De kern in vijf punten:

  • Controleer eerst of een standaardpakket volstaat; maatwerk loont bij processen die jouw organisatie onderscheiden.
  • Bereid één A4 voor met je probleem, je doel, je gebruikers en je systeemlandschap.
  • Vergelijk offertes op aannames en scope, en kies op continuïteit in plaats van op de laagste prijs.
  • Reken tijdens de bouw op een eigen rol: beslissen, testen en een vast feedbackritme.
  • Regel het beheer vóór de livegang en kies de samenwerkingsvorm die bij je organisatie past.

De volgende stap is een gesprek over jouw idee. Plan een vrijblijvend gesprek en we laten je zien hoe het traject er voor jouw opgave uitziet, ook als ons advies is om eerst klein te beginnen of bij een standaardpakket te blijven.

Deel dit artikel

Jack van Poll

Jack van Poll

Co-Founder, Isatis

Schrijft over nearshore engineering,
softwarepartnerschappen en teams die blijven.

Neem contact op

Lees verder.

Alle artikelen