Build vs Buy Software: Een fractional CTO-framework voor engineeringbeslissingen

Vorig jaar oktober trok een Series A-founder me een vrijdagmiddagvergadering in met een vraag die urgent voelde: moesten ze hun eigen analytics-pipeline bouwen? Zijn head of growth wilde Mixpanel voor productanalytics, zijn head of finance wilde Looker voor revenue-dashboards, en zijn lead engineer had een halfafgemaakte interne tool die “allebei doet en nog maar één sprint kost.” De totale SaaS-rekening werd geprognosticeerd op €74.000 per jaar. De interne tool zou op papier niets kosten. De founder neigde naar bouwen. Ik stelde hem één vraag: wie staat er straks om 3 uur ‘s nachts op tijdens een productlancering met die pipeline? Het werd stil in de kamer. We tekenden die middag voor Mixpanel én Looker.

Na negentien jaar Rails-systemen bouwen en de afgelopen zes jaar adviseren als fractional CTO heb ik gezien hoe de build vs buy software-beslissing meer roadmaps om zeep heeft geholpen dan bijna welke andere categorie fout dan ook. Engineers willen bouwen omdat bouwen interessant is. Founders willen bouwen omdat vendorrekeningen groot lijken en directe salarissen aanvoelen als investeringen. CFO’s willen kopen omdat SaaS-contracten voorspelbaar zijn. Geen van die instincten is op zichzelf correct. Deze post is het framework dat ik bij elke klant gebruik, in de volgorde waarin ik het ook echt toepas.

Waarom Build vs Buy Software een CTO-beslissing is

Elk “moeten we dit niet zelf bouwen”-gesprek bereikt uiteindelijk een splitsing: de engineers zeggen dat het twee weken werk is, de vendor noemt een bedrag dat duur voelt, en iemand in de kamer zegt “tja, als het maar twee weken is…” Dat is het moment waarop de beslissing fout gaat. De twee-weken-schatting is bijna altijd eerlijk over de eerste versie. Hij is bijna nooit eerlijk over de komende vijf jaar onderhoud, de on-call-rotatie, de security-patches, de compliance-audits, de integraties, de docs en de engineer-uren die zo worden weggetrokken van het eigenlijke product.

Een fractional CTO verdient zijn fee in deze gesprekken. De taak is niet om nee te zeggen tegen bouwen. De taak is om de werkelijke kosten van bouwen zichtbaar te maken, ze te vergelijken met de werkelijke kosten van kopen, en de beslissing terug te leiden naar de strategische vraag: differentieert dit ons, of is het leidingwerk? De meeste bedrijven bouwen het leidingwerk en kopen de differentiator. Dat is precies andersom.

De build vs buy software-vraag duikt op in de voor de hand liggende plekken — analytics, CRM, billing, auth — en in de minder voor de hand liggende: feature flags, search, image processing, e-mail, observability, customer support, document generation, scheduled job orchestration. Stuk voor stuk categorieën waar volwassen vendors bestaan, en stuk voor stuk categorieën waar Rails-teams toch hun eigen versie schrijven en daar binnen achttien maanden spijt van krijgen.

De Vijf Vragen Die Ik Stel Voor Iemand Code Schrijft

Voor ik een team een serieuze build laat starten, moeten ze vijf vragen op papier kunnen beantwoorden. Lukt dat niet helder, dan is het antwoord kopen. Lukt het wel goed, dan is het antwoord waarschijnlijk nog steeds kopen — maar dan hebben we tenminste een echt gesprek.

1. Is dit onze kerndifferentiator? Als een klant ons specifiek boven een concurrent zou kiezen omdat we dit zelf hebben gebouwd, bouw het. Als ze niet zouden merken of er om malen welke vendor we gebruiken, koop het. Stripe heeft geen eigen Rails-applicatieserver gebouwd. Linear heeft geen eigen Postgres gebouwd. Ze bouwden de dingen die hen anders maakten.

2. Wat is de vijfjaars-total-cost-of-ownership? Niet de bouwkosten. De bouwkosten plus onderhoud plus on-call plus security plus de engineers die opstappen omdat ze de interne billing-tool zat zijn. Ik reken jaarlijks 30 procent van de initiële bouwkosten als onderhoudsbodem. Dat is conservatief.

3. Wie is eigenaar als degene die het bouwde vertrekt? Interne tools stapelen tribal knowledge sneller op dan welke andere code in de codebase. Twee jaar na livegang begrijpt nog precies één persoon de retry-logica van de message queue. Die persoon is nu jullie single point of failure, en weet dat.

4. Wat kost de failure mode? Als dit systeem omvalt, wat gebeurt er? Als jullie eigen feature-flag-service om 2 uur ‘s nachts breekt, gaat elk productoppervlak op zwart. Als LaunchDarkly omvalt, worden jullie wakker met een statuspagina en een postmortem die zij schrijven.

5. Begrijpen we het probleem werkelijk? De meeste “we moeten dit bouwen”-pitches komen van iemand die één of twee vendorproducten heeft gebruikt en die ontoereikend vond. Die zes andere niet. Ze kennen de integraties niet, de audit logs niet, de SOC 2-rapporten niet, en het zevende edge case dat de vendor drie jaar geleden al heeft opgelost niet.

Een Echt Voorbeeld: Feature Flags

Twee jaar geleden besloot een Series B fintech-klant zijn eigen feature-flag-systeem in Rails te bouwen. Hun lead engineer had Flipper gebruikt en dacht het beter te kunnen met een eigen Redis-implementatie. De eerste versie stond na drie weken live en zag er strak uit.

class FeatureFlag
  def self.enabled?(name, user)
    return false unless flag = $redis.get("flag:#{name}")
    flag_data = JSON.parse(flag)
    return true if flag_data["enabled_for_all"]
    flag_data["enabled_users"].include?(user.id)
  end

  def self.enable_for(name, user)
    flag_data = JSON.parse($redis.get("flag:#{name}") || "{}")
    flag_data["enabled_users"] ||= []
    flag_data["enabled_users"] << user.id
    $redis.set("flag:#{name}", flag_data.to_json)
  end
end

Zes maanden later was het uitgegroeid tot 400 regels en blijft maar groeien. Ze hadden percentage rollouts nodig, daarna organisatie-rollouts, daarna time-windowed rollouts, daarna geo-targeting, daarna een audit log omdat compliance erom vroeg, daarna een UI omdat PM het zat was om Redis handmatig te bewerken, daarna SDK-clients voor de React-frontend, daarna een feature flag voor het feature-flag-systeem omdat ze doodsbang waren om het aan te raken. Totale investering: circa €180.000 aan engineer-tijd over achttien maanden.

LaunchDarkly had ze €18.000 per jaar gekost en had elk van die capabilities op dag één geleverd. Uiteindelijk zijn ze gemigreerd. Het eigen systeem leeft alleen nog voort als een dependency die ze er niet makkelijk uit krijgen.

De les is niet dat feature flags te moeilijk zijn om te bouwen. Dat zijn ze niet. De les is dat het werkelijke probleem dat ze oplosten was “maak het voor product makkelijk om veilig te shippen,” en dat een vendor tien jaar lang precies dat probleem had opgelost. Bouwen loste 20 procent van het echte probleem op en noemde dat klaar.

Wanneer Bouwen Wél Wint

Kopen is de default in mijn framework, maar het is niet het antwoord op elke vraag. Er zijn scenario’s waarin bouwen overduidelijk correct is, en ik wil daar specifiek over zijn.

De vendor bestaat niet op jullie schaal. Verwerken jullie 50 miljard events per maand en breekt het SaaS-prijsmodel boven het miljard, dan zijn jullie de markt ontgroeid. Dit is zeldzaam en je weet het als het gebeurt.

De integratiekosten domineren de bouwkosten. Soms bestaat de vendor wel, maar is integreren in jullie specifieke datamodel zwaarder dan het feature zelf schrijven. Komt het meest voor bij legacy-systemen met afwijkende datavormen.

Het is écht een competitive moat. Als jullie AI-inference-pipeline, jullie matching-algoritme of jullie fraud-detection-model is waar klanten voor betalen, dan bouwen jullie dat. Laat een vendor nooit eigenaar zijn van jullie moat.

Compliance of dataresidency maakt vendors onmogelijk. Zorg en EU-publieke sector hebben soms residency-eisen waar geen enkele SaaS aan kan voldoen. Dan bouw je, maar bewust, en je staffed daarvoor in.

Je vervangt een vendor om strategische redenen. Soms begin je op een vendor, leer je het probleem grondig kennen, en bouw je daarna een toegesneden versie. Dat is het juiste pad: koop om te leren, bouw om te optimaliseren.

Het Hybride Patroon: Koop de Motor, Bouw de Interface

Het meest robuuste patroon dat ik bij klanten neerzet is hybride. Gebruik vendors voor de motor — het zware infrastructuurwerk — en bouw een dunne Rails-laag eromheen. Jullie klanten zien jullie interface. Jullie team is eigenaar van de klantgerichte logica. De vendor doet de commodity-onderdelen.

class BillingService
  def self.create_subscription(user:, plan:, trial_days: 14)
    stripe_subscription = Stripe::Subscription.create(
      customer: user.stripe_customer_id,
      items: [{ price: plan.stripe_price_id }],
      trial_period_days: trial_days,
      metadata: { user_id: user.id, plan_code: plan.code }
    )

    user.subscriptions.create!(
      stripe_subscription_id: stripe_subscription.id,
      plan: plan,
      status: stripe_subscription.status,
      trial_ends_at: Time.at(stripe_subscription.trial_end || 0)
    )
  end
end

Stripe is eigenaar van het creditcardformulier, de PCI-scope, de bankintegraties, de dunning-logica, de btw-berekeningen en de failed-payment-retries. De Rails-app is eigenaar van het subscription-model, de entitlement-logica, het klantdashboard en de business rules die het bedrijf specifiek maken. Wordt Stripe ooit de verkeerde vendor, dan is het migratie-oppervlak bewust en beperkt.

Dit is ook het patroon dat ik aanraad voor AI-workloads. Anthropic is eigenaar van het model. Jullie Rails-app is eigenaar van de prompt engineering, de gespreksstate, de retrieval-pipeline en de integratie met jullie domeindata. Jullie trainen geen eigen foundation model. Jullie laten ook geen vendor eigenaar zijn van jullie conversation history-schema.

De Build vs Buy Software Decision Matrix

Als ik het framework aan een bestuur presenteer, gebruik ik een eenvoudige matrix met twee assen: strategische waarde voor het bedrijf (laag/hoog) en switching cost (laag/hoog). De vier kwadranten geven duidelijke defaults.

Lage waarde, lage switching cost — koop het goedkoopste. Statuspagina’s, error tracking, marketing-e-mail. De keuze maakt niet veel uit; later wisselen kost weinig.

Lage waarde, hoge switching cost — koop zorgvuldig en onderhandel hard. Billing, CRM, HRIS. Dit zijn commodities, maar ze worden voor altijd ingebed, dus vendorstabiliteit en prijsindexering-clausules tellen.

Hoge waarde, lage switching cost — koop het beste, ook al kost het meer. Customer support, observability, productanalytics. De kwaliteit raakt hoe het team dagelijks werkt, maar je kunt later van vendor wisselen als je ze ontgroeit.

Hoge waarde, hoge switching cost — dit is de build-kandidaat. Jullie kernproduct, jullie differentiërende algoritmes, jullie competitive moat. Bouw bewust, staff goed, en laat het nooit iemands bijproject worden.

De meeste “moeten we dit bouwen”-discussies lossen zich vanzelf op zodra je het ding eerlijk in deze matrix plaatst. De valkuil is dat engineers alles zien als hoge waarde en hoge switching cost, omdat ze het willen bouwen. De taak van de fractional CTO is om de waardeclaim met bewijs onderuit te halen.

Het Kostengesprek Dat Founders Verkeerd Voeren

Ik zag ooit een founder een €30.000-per-jaar SaaS-contract weigeren en €240.000 aan engineering-salaris goedkeuren om het equivalent zelf te bouwen, omdat “salaris een investering is en SaaS een kostenpost.” De boekhouding klopte. De strategie was rampzalig. Hij betaalde acht keer meer voor hetzelfde resultaat, en moest het ook nog voor altijd onderhouden.

De kostenframing die wél werkt:

Directe vendor cost is de SaaS-rekening plus integratietijd. Tel daar de engineer-weken bij op om de vendor goed neer te zetten, en het terugkerende onderhoud voor SDK-upgrades en API-wijzigingen.

Directe build cost is de engineer-weken om de eerste bruikbare versie te shippen, vermenigvuldigd met 1,5 omdat de schatting fout is, plus jaarlijks 30 procent daarvan voor onderhoud, plus de opportunity cost van wat die engineers anders zouden hebben gebouwd.

Indirecte kosten zijn on-call-belasting, security-review-overhead, compliance-audit-werk, wervingsmoeilijkheid (engineers met vendor-skills zijn makkelijker te vinden dan engineers voor je bespoke interne tool), en de cognitieve belasting op het hele team.

Risico-gewogen kosten zijn de kans dat de build faalt vermenigvuldigd met de kosten van die faal. Interne tools falen vaker dan founders toegeven. De meest voorkomende faal is niet catastrofaal — het is een half klaar product dat niemand durft weg te gooien.

Als ik die vier getallen naast elkaar zet, is het “dure” SaaS-contract over vijf jaar meestal twee tot vier keer goedkoper dan de “gratis” interne build. Combineer dit met het technical debt prioritization framework dat je al zou moeten toepassen — interne tools worden technical debt op de dag dat ze live gaan.

Wat Ik Tegen Engineers Zeg Die Willen Bouwen

Het zwaarste gesprek is niet met de founder. Het is met de senior engineer die het ding oprecht wil bouwen, een goed ontwerp in zijn hoofd heeft en technisch in staat is het te leveren. Ze hebben geen ongelijk over of ze het kunnen. Ze hebben ongelijk over of het een goede besteding van hun tijd is.

De framing die wel binnenkomt: elk uur dat je in het interne feature-flag-systeem stopt, is een uur dat je niet stopt in de productfeature die de volgende klant binnenhaalt. Vendors bestaan juist om jouw tijd vrij te maken voor het werk dat alleen jij kunt doen. Leidingwerk bouwen is niet waarvoor we senior engineers hebben aangenomen. We hebben senior engineers aangenomen om product te shippen.

Meestal werkt dat. Werkt het niet, dan laat ik ze op een vrijdag prototypen en kijken we maandag samen naar het prototype met de vijf vragen erbij. Het framework is zijn eigen argument.

FAQ

Wanneer is het wel verstandig om software zelf te bouwen in plaats van te kopen?

Bouw als het systeem een competitive differentiator is, als vendors jullie schaal of compliance-eisen niet aankunnen, of als de integratiekosten van een vendor groter zijn dan de bouwkosten. Voor commodity-infrastructuur — billing, auth, feature flags, analytics, observability — koop je.

Hoe bereken ik de echte kosten van software zelf bouwen?

Begin met de engineer-weken voor versie één, vermenigvuldig met 1,5 voor schattingsglip, tel daar jaarlijks 30 procent bij op voor vijf jaar onderhoud, en voeg de opportunity cost toe (wat hadden die engineers anders voor betalende klanten gebouwd). Vergelijk dat totale bedrag met het vijfjaars-SaaS-contract, niet met dat van het eerste jaar.

Wat is de grootste fout die startups maken bij build vs buy?

Engineering-salarissen behandelen als vaste kosten en SaaS als variabele kosten. Engineeringtijd is de duurste en meest schaarse resource in elke startup. Elk uur aan een interne tool is een uur niet aan het product. De boekhoudkundige framing maakt bouwen gratis; de strategische framing laat zien dat het dat bijna nooit is.

Hoe helpt een fractional CTO bij build vs buy-beslissingen?

Een fractional CTO heeft dezelfde beslissing zien uitspelen bij tientallen bedrijven en kent de long-tail-kosten die interne pleitbezorgers altijd onderschatten. Daarnaast heeft hij de senioriteit om het enthousiasme van een senior engineer te overrulen zonder de politieke kosten die een vaste CTO daarvoor zou betalen. Het framework in deze post is wat zij meebrengen.

Hulp nodig bij het framen van een build vs buy-beslissing voor jullie volgende sprint? TTB Software adviseert startups en scale-ups als fractional CTO-partner en past dit framework toe op Rails-architecturen en vendor-selectie. Wij doen dit al negentien jaar.