Custom Software · Verdieping
Maatwerk of platform: het build-vs-buy-beslissingsraster
Wanneer maatwerksoftware bouwen en wanneer een platform kopen: een beslissingsraster op basis van procesfit, total cost of ownership, lock-in, data-eigendom en time-to-value.
ARCHITECTUUR · BUILD-VS-BUY
Erin · Te realiseren capabilities
Eruit · Build / Buy / Compose
Core vs commodity (waardekaart)
Ontleedt het systeem in zijn capaciteiten en plaatst elk op de core/commodity-as: scheidt wat u in de markt onderscheidt — en eigen code verdient — van wat commodity is geworden en simpelweg bij de goedkoopste aanbieder wordt gekocht.
Fit met het proces
Meet hoe propriëtair uw workflow is: een generiek proces met gevestigde sectorstandaarden duwt naar het platform, terwijl een workflow die deel is van uw voordeel naar maatwerk duwt, want hier kosten de workarounds die een platform oplegt meer dan code op maat.
TCO over 5 jaar
Berekent de vijfjaarskosten inclusief onderhoud, integratie en training — niet alleen licentie of initiële offerte — want het grootste deel van de softwarekosten valt na de go-live, en dat is wat het verdict omslaat.
Lock-in & exitrechten
Weegt de uitstapkosten af voordat u instapt: contracten, dataportabiliteit en hard bedrade integraties bepalen of u bij verlenging onderhandelingsmacht hebt of zonder komt te zitten, tegenover een leverancier die dat weet.
Data-eigenaarschap
Controleert of de data die u onderscheidt van u blijft, exporteerbaar in open standaarden en onafhankelijk van de leverancier: één enkel niet-exporteerbaar item kan de beslissing omslaan, want een in gijzelaar veranderde asset weegt zwaarder dan welke catalogusprijsbesparing dan ook.
Time-to-value
Balanceert de urgentie van de waarde tegen de duurzaamheid van het voordeel: een beproefde, al beschikbare oplossing brengt u nu in beweging, terwijl een structurele differentiator een langere, volgehouden implementatie rechtvaardigt.
De signalen dat uw build-vs-buy-lijn op de verkeerde plek is getrokken
De vraag is nooit „maatwerk of platform”. Ze is: welke capaciteit verdient eigen code, en welke is een commodity om te kopen. Deze symptomen betekenen dat de lijn op de verkeerde plek is getrokken.
- U past een standaardplatform aan totdat het niet meer op zichzelf lijkt: elke release van de leverancier breekt uw configuratie, en „kant-en-klaar” is een permanent ontwikkelproject geworden.
- U hebt een commodity vanaf nul gebouwd — authenticatie, betalingen, notificaties — en engineeringcapaciteit besteed aan problemen die de markt al heeft opgelost, in plaats van aan uw concurrentievoordeel.
- De data die u onderscheidt zit bij een leverancier in een propriëtair formaat zonder export naar open standaarden: het is geen asset meer, het is een gijzelaar.
- Niemand heeft ooit het vijfjaarscijfer berekend : de beslissing werd genomen op een licentieprijs of een ontwikkelofferte, met voorbijgaan aan onderhoud, integratie en training die de levenscyclus domineren.
- Van leverancier wisselen is ondenkbaar : meerjarige contracten, niet-overdraagbare data en hard bedrade integraties hebben de uitstapkosten verhoogd tot een niveau dat u bij verlenging elke onderhandelingsmacht ontneemt.
Voor CTO's, COO's en operationeel leidinggevenden die moeten beslissen waar ze engineeringcapaciteit investeren en waar ze op de markt leunen, met criteria die standhouden voor de board.
Koop de commodity, bouw wat u onderscheidt
De meest duurzame operationele regel is niet financieel maar strategisch: plaats elke capaciteit op de waardekaart en beslis op basis van waar ze staat, niet op basis van de voorkeuren van wie de code schrijft. Een discipline geformaliseerd door Wardley Mapping.
Core vs commodity, geen persoonlijke smaak
Een capaciteit die u in de markt onderscheidt en snel evolueert verdient eigen code. Een capaciteit die commodity is geworden — dezelfde voor u en uw concurrenten — is een kostenpost: u koopt bij de goedkoopste aanbieder en gaat verder. Een commodity bouwen is engineeringcapaciteit verbranden aan een opgelost probleem.
De procesfit is de echte scheidslijn
Is uw workflow generiek en heeft de sector gevestigde standaarden, dan wint een platform op snelheid. Is de workflow propriëtair en deel van uw voordeel, dan dwingt het platform workarounds af die, opgeteld, meer kosten dan code op maat. Een platform buigt u naar zijn model; maatwerk buigt de software naar het uwe.
Configureren is niet gratis
Tussen kopen en bouwen ligt een derde weg — configureren en integreren — maar die is niet neutraal. Een complex platform inpassen in een specifieke workflow, met datamigratie en training, brengt reële kosten met zich mee nog vóór de eerste transactie. De val is overpersonalisatie: begin bij de aanbevolen opzet en itereer op gebruiksdata, herschrijf niet alles op dag één.
Compose: het beste van beide, met discipline
De volwassen aanpak is hybride: marktcapaciteiten voor de standaardfuncties, verbonden via gedocumenteerde API's, en interne engineeringcapaciteit geconcentreerd op wat u echt onderscheidt. Dit is de composable-logica (microservices, API-first, cloud-native, headless): vervangbare componenten die veranderen zonder alles wat eraan gekoppeld is te laten instorten.
De beslissing moet structureel zijn, niet emotioneel
Het in kaart brengen van capaciteiten maakt de keuze leesbaar: u ziet waar elk component op de as van genese naar commodity staat, waarvan het afhangt en waarheen de evolutie duwt. De build-vs-buy-lijn houdt op een afdelingsvoorkeur te zijn en wordt een verdedigbare architectuurbeslissing.
Hoe wij de lijn trekken, capaciteit voor capaciteit
We beslissen niet „maatwerk of platform” voor het hele systeem. We ontleden het systeem in capaciteiten en halen elk door dezelfde gates. Het resultaat is een kaart, geen mening.
We ontleden het systeem in zijn capaciteiten en plaatsen elk op de core/commodity-as: wat u onderscheidt, wat standaard is geworden. Dit scheidt wat eigen code waard is van wat u simpelweg koopt.
Voor elke capaciteit testen we hoe propriëtair uw workflow is. 60-70% standaard met beheersbare uitzonderingen: configureren. Workflow die deel is van het voordeel: bouwen. Generieke workflow: kopen.
We berekenen de vijfjaarskosten inclusief onderhoud, integratie en training — niet alleen licentie of initiële offerte. Parallel meten we de uitstapkosten: dataportabiliteit, exportrechten, afhankelijkheid van integraties.
Elke capaciteit krijgt een verdict — build, buy of compose — en haar plaats in de architectuur. Commodity's gaan achter gedocumenteerde API's; de differentiator wordt eigen code, met de data onder uw controle.
Van capaciteitskaart naar een verdedigbaar beslissingsraster in weken, niet in een kwartaal aan studies.
Build, Buy of Compose: de beslissingsgates
Elke capaciteit loopt door vijf hefbomen. Het is geen puntentotaal: één enkele hefboom kan de beslissing omslaan (propriëtaire, niet-exporteerbare data weegt zwaarder dan welke catalogusprijsbesparing dan ook).
| Beslissingshefboom | Duwt naar BUY / platform | Duwt naar BUILD / maatwerk |
|---|---|---|
| Positie op de kaart | Commodity-capaciteit, identiek aan de concurrenten | Core-capaciteit die u onderscheidt en snel evolueert |
| Procesfit | Generieke workflow, gevestigde sectorstandaarden | Propriëtaire workflow; het platform dwingt kostbare workarounds af |
| 5-jaars-TCO | Onderhoud en risico gedragen door de leverancier | Volume en gebruiksduur amortiseren de ontwikkelkosten |
| Lock-in & uitstap | Export naar open standaarden, uitstap uit gemak, API-integraties | Kritieke data moet eigen blijven, onafhankelijk van de leverancier |
| Time-to-value | Waarde nu nodig; beproefde oplossing al beschikbaar | Het voordeel rechtvaardigt een langere, volgehouden implementatie |
De vier assets die het raster veiligstelt
Een degelijke build-vs-buy-beslissing optimaliseert niet alleen de kosten. Ze beschermt wat, eenmaal verloren, niet terug te kopen is.
Data-eigendom
De data die u onderscheidt blijft van u, exporteerbaar in standaardformaten en onafhankelijk van de leverancier. Geen gijzelaar in een propriëtaire silo, maar een verhandelbare asset die u macht geeft bij verlenging.
Goed besteedde engineeringcapaciteit
Elk ontwikkeluur gaat naar uw concurrentievoordeel, niet naar een commodity die de markt al heeft opgelost. Maatwerk waar het telt, markt waar het niet telt.
Uitstaprechten
Dataportabiliteit, gedocumenteerde API-integraties en geen propriëtaire bedrading houden de overstapkosten laag. De mogelijkheid om te vertrekken is wat u op eerlijke voorwaarden houdt.
Composable-architectuur
Vervangbare capaciteiten verbonden via API's: één component verandert zonder dat de rest instort. Het systeem blijft in de tijd levend, geen monoliet om opnieuw te bouwen.
Bouw wat u onderscheidt, koop wat u deelt met uw concurrenten.
De vragen die we krijgen voordat we beslissen
Is maatwerk altijd duurder dan een platform?
Niet over de levenscyclus. Het grootste deel van de softwarekosten valt na de go-live — onderhoud, integratie, training. Bij een commodity wint het platform omdat het die kosten afwentelt op de leverancier. Bij een core-capaciteit met hoog volume en lange gebruiksduur amortiseert maatwerk terwijl de prijs van een platform in de tijd stijgt. Het antwoord ligt in de vijfjaars-TCO, niet in de instapprijs.
Kan ik nu kopen en later bouwen?
Ja, en vaak is dat de juiste zet — zolang u niet in de val loopt. Kopen om snel te starten is zinvol als de data exporteerbaar blijft in open standaarden en integraties via gedocumenteerde API's lopen. Houdt de leverancier uw data in een propriëtair formaat, dan wordt „later” een kostbare migratie die u nooit zult uitvoeren. Portabiliteit onderhandel je bij de ondertekening, niet bij de scheiding.
Hoe vermijden we iets te bouwen dat de markt beter doet?
Door elke capaciteit in kaart te brengen voordat er code wordt geschreven. Is een functie standaard geworden — dezelfde voor u en uw concurrenten —, dan is haar bouwen verbrande engineeringcapaciteit. Eigen code is gereserveerd voor wat u onderscheidt en evolueert; al het overige wordt gekocht of via API's samengesteld. Die discipline scheidt een investering van een uitgave.
Cases
Van probleem naar resultaat — geanonimiseerd.
Het uit vorm gebogen platform
Probleem Een retailer had een standaard-e-commerceplatform aangepast totdat het niet meer op zichzelf leek: elke release van de leverancier brak de configuratie en „kant-en-klaar” was een permanent ontwikkelproject geworden, met de pricing-engine — hun echte differentiator — vastgeklemd in beperkingen die ze niet beheersten.
Methode We brachten de capaciteiten in kaart op de core/commodity-as: catalogus, checkout en betalingen behouden op het platform als commodity's achter gedocumenteerde API's; de pricing- en promotie-engine, deel van het concurrentievoordeel, geëxtraheerd als eigen service composable bedraad.
Resultaat Releases van de leverancier braken het systeem niet meer, de engineeringcapaciteit ging terug naar pricing in plaats van workarounds, en de logica die hen onderscheidt werd hun eigen code — vervangbaar zonder de rest te laten instorten.
De data in gijzeling
Probleem Een financiëledienstverlener bewaarde de klantdata die haar onderscheidde bij een leverancier, in propriëtair formaat zonder export naar open standaarden: wisselen was ondenkbaar en bij verlenging had de leverancier alle onderhandelingsmacht, want uitstap was feitelijk afgesloten.
Methode We pasten de lock-in- en data-eigendomsgates toe: exportrechten naar standaardformaten heronderhandeld bij de contractbreuk, kritieke integraties verplaatst naar gedocumenteerde API's en de onderscheidende data terug onder interne controle gebracht, met de commodity-functies waar ze waren.
Resultaat De uitstapkosten daalden tot het punt waarop de onderhandelingsmacht bij verlenging werd hersteld, de data werd weer een verhandelbare asset in plaats van een gijzelaar, en de mogelijkheid om te vertrekken is wat hen op eerlijke voorwaarden hield.
De vanaf nul gebouwde commodity
Probleem Een logistieke operator had vanaf nul commodity-capaciteiten gebouwd — authenticatie, notificaties, gebruikersbeheer — en engineeringcapaciteit verbrand aan problemen die de markt al had opgelost, terwijl de routeplanning, hun echte voordeel, onderbelegd bleef.
Methode We haalden elke capaciteit door de waardekaart en de vijfjaars-TCO: het maatwerk op de commodity's afgevoerd ten gunste van marktdiensten achter API's, en de ontwikkelaars geconcentreerd op route-optimalisatie, waar volume en gebruiksduur de code op maat amortiseren.
Resultaat Elk ontwikkeluur ging terug naar de differentiator, het onderhoud van de commodity's verschoof naar de leveranciers, en de architectuur werd composable — vervangbare componenten die veranderen zonder het hele blok opnieuw te bouwen.
Verdiep verder