Hvordan træffer du build-versus-buy beslutninger?

Question

Accepted Answer

**Build vs. buy** spørger, om du skal udvikle noget internt eller vedtage et eksisterende produkt eller en service. Instinktet til at bygge er stærkt og ofte forkert, og de reelle omkostninger ved at bygge omfatter år med vedligeholdelse, ikke blot første version. Beslutningen afhænger af, om det er *kernen* i din virksomhed.

## En beslutningsramme

```text
LEAN BUY when:                     LEAN BUILD when:
- It's NOT your core differentiator  - It IS your core value/differentiator
- A mature solution exists           - No good solution fits your needs
- Speed-to-market matters            - You need deep control/customization
- You lack expertise to maintain it  - Long-term cost of buying is prohibitive
- TCO of buying < building+upkeep     - Vendor lock-in is an unacceptable risk
```

## Et konkret eksempel

Byg ikke dit eget auth-system, identitet er vanskelig, sikkerhedskritisk og ikke din differentiator; køb/integrer en påvist udbyder. *Byg* din kernerekommendationsmotor, hvis anbefalinger er det, der gør dit produkt særligt. Byg det, der gør dig til *dig*; køb resten.

## Tæl de sande omkostninger

Teams undervurderer kronisk byggeri: første version er 20% af livscyklusomkostningerne. Vedligeholdelse, sikkerhedsopdateringer, edge cases og on-call overstiger det langt. Tæl den samlede ejeromkostning over år, ikke demoen du kan levere i en sprint.

## En fælde

"Ikke opfundet her" fører til genopbygning af løste problemer; blind indkøb fører til vendor lock-in og værktøjer, der ikke passer. Beslut dig bevidst, sag for sag.

## Hvorfor det betyder noget

At bygge det forkerte internt dræner år af ingeniørindsats ind i ikke-differentieret arbejde.

At få dette rigtigt koncentrerer dit knappe ingeniørarbejde på det, der faktisk får virksomheden til at vinde.