Build vs Buy: when we write our own code

Every software company faces the same question several times a week: do we build this or use something that already exists? Getting it wrong in either direction is expensive. Building what's already solved eats time that should go into the product. Buying what's central to the product hands your edge to another company.

When we use what exists

• When the problem is generic. Authentication, queues, databases, observability: solved problems, with mature, audited tools.
• When the cost of maintaining exceeds the cost of paying. Our own code isn't free; it needs tests, updates and someone awake when it breaks.
• When the tool is replaceable. If we can switch vendors without rewriting the product, the risk is low.

When we build

• When it's the core of the product. If the component is the reason the customer chooses the product, it has to be ours.
• When the alternative compromises privacy. If using a service means sending sensitive data somewhere we can't audit, we build.
• When the available quality isn't enough. Sometimes the tool exists but doesn't handle the real-world case with the precision required.

The rule that sticks

Build vs buy decisions are recorded with context, the alternatives considered and the reasoning. When the context changes, the decision is revisited — with no attachment to what was already written.