Chat met Jurre

Besturingssysteem

Software laten bouwen of kopen: hoe je die keuze maakt

Jurre Grimberg· 7 min

Het begint bijna altijd hetzelfde. Er is een spreadsheet die te belangrijk is geworden, of een tool die tachtig procent doet en waar de laatste twintig procent met de hand omheen wordt gewerkt. Iemand zegt: kunnen we hier niet gewoon iets voor laten bouwen?

Soms is dat het beste geld dat je uitgeeft. Vaker is het een project van negen maanden dat eindigt in iets dat werkt, dat niemand gebruikt, en dat je nu zelf moet onderhouden. Het verschil zit niet in het budget of in de bouwer. Het zit in de vraag die eraan voorafgaat.

De drie routes

Er zijn er maar drie, en de meeste mensen bekijken er twee.

KopenAanpassenBouwen
Wat het isEen bestaand product afnemen zoals het isEen bestaand fundament dat jouw kant op wordt uitgebreidVanaf nul, alleen voor jou
WanneerJe proces lijkt op dat van anderenJe proces lijkt op dat van anderen, met een paar eigen stappen die er echt toe doenJe proces is je onderscheid, en het bestaat nergens
Live inDagenWekenMaanden
Orde van grootteHonderden per maandTienduizenden eenmalig, plus abonnementVanaf een ton
Wat er misgaatJe buigt je proces naar de tool en niemand weet meer waaromJe vraagt zoveel aanpassingen dat je alsnog aan het bouwen bentJe bouwt wat je in maand één dacht nodig te hebben
Wie het onderhoudtDe leverancierDe leverancierJij

Die middelste kolom is de kolom die het vaakst wordt overgeslagen, en het is meestal het goede antwoord. Een fundament dat al staat, met daarop de vier of vijf dingen die van jou zijn. Je betaalt voor het verschil in plaats van voor het geheel, en je erft elke verbetering die er verder aan gebeurt.

De vier vragen die de keuze maken

Loop ze in deze volgorde langs. Bij de eerste "nee" heb je je antwoord al.

1. Is dit proces je onderscheid, of is het gewoon werk?

Facturatie, verlofaanvragen, urenregistratie: dat is werk. Daar is een product voor, en dat product is beter dan wat jij laat bouwen, omdat er duizend bedrijven op hebben meegekeken. Bouw alleen wat je van je concurrent onderscheidt. Als je het antwoord niet in één zin kunt geven, is het antwoord nee.

2. Kun je opschrijven wat het moet doen, zonder het over schermen te hebben?

Wie begint met "en dan wil ik een knop hier" heeft nog geen probleem, maar een idee. Kun je in tien regels de beslissing beschrijven die het systeem moet ondersteunen, wie hem neemt en waar het nu misgaat, dan is het scherp genoeg om te bouwen.

3. Gebruikt iemand het als het er is?

Dit is de vraag die de meeste maatwerkprojecten sloopt en die niemand stelt. Software die niemand opent, is duurder dan geen software. Wijs iemand aan die er dagelijks in gaat werken, en laat die persoon meebeslissen over de scope. Kun je die persoon niet aanwijzen, bouw dan niet.

4. Wie onderhoudt het over twee jaar?

Maatwerk gaat niet stuk op de oplevering. Het gaat stuk als de browser verandert, de koppeling wegvalt of de bouwer een ander bedrijf begint. Als je daar geen antwoord op hebt, koop je iets dat over twee jaar een probleem is.

Waar het geld bij maatwerk echt heen gaat

De bouw is de post die je offreert. De rest is de post die je vergeet. Onderstaande verhouding is wat wij in de praktijk zien over de eerste drie jaar.

PostAandeel van de totale kostenZit meestal in de offerte
Bouwen van de eerste versieongeveer 40%ja
Aanpassen nadat mensen het gebruikenongeveer 25%nee
Onderhoud, hosting en beveiligingongeveer 20%nee
Onboarding en de leercurve van je teamongeveer 15%nee

Wat er in de praktijk gebeurt: je tekent voor de eerste regel en je begroot niet voor de andere drie. Dan komt er na een half jaar een verzoek dat "toch niet zo groot is", en dan nog een. Vraag je bouwer daarom niet alleen wat het kost, maar wat het per jaar kost om het te laten leven.

Als je toch bouwt: vijf regels

Begin met een conceptfase die je apart afrekent. Prototype, datamodel, backlog, schatting. Aan het eind beslis je of je doorgaat, zonder verplichting. Wie die stap overslaat om tijd te winnen, betaalt hem later terug met rente.

Werk in sprints van twee weken met iets werkends aan het eind. Niet een demo, maar iets waar je iemand in kunt laten klikken. Een project dat pas na drie maanden iets laat zien, laat na drie maanden het verkeerde zien.

Zet de scope vast en de wensen op een lijst. Elk verzoek dat tijdens de bouw binnenkomt gaat naar die lijst, niet naar de sprint. Aan het eind van elke sprint kijk je samen wat er alsnog in moet. Zo blijft het bespreekbaar zonder dat het uitloopt.

Spreek af wie de code heeft. Niet omdat je verwacht dat het misgaat, maar omdat die afspraak achteraf maken de duurste discussie is die er bestaat.

Reken op onderhoud vanaf dag één. Zet een bedrag per maand in je begroting, ook als er die maand niets gebeurt. Software zonder onderhoudsbudget wordt vanzelf software die niemand meer aanraakt.

Kort samengevat

Bouw wat je onderscheidt en koop de rest. Kun je niet in één zin zeggen wat dit systeem doet dat een bestaand product niet doet, dan is de eerlijke conclusie dat je een product moet kopen en je proces moet opruimen. Dat is een saaier antwoord en het is meestal het goede.

En zit je ertussenin, met een proces dat grotendeels normaal is en op drie punten echt van jou, kijk dan naar de middelste kolom voor je aan de rechter begint.

Veelgestelde vragen

Als het proces je onderscheidt van je concurrent, je in tien regels kunt opschrijven welke beslissing het systeem moet ondersteunen, je iemand kunt aanwijzen die er dagelijks in gaat werken, en je weet wie het over twee jaar onderhoudt. Ontbreekt een van die vier, dan is kopen of aanpassen bijna altijd beter.

Klaar om dit voor jouw bedrijf te bouwen?

Start met een gratis audit. Eerlijk beeld van strategie, executie en mensen.

Start de audit

Gerelateerde inzichten