Build vs Buy

• Core differentiator : something customers choose you for and competitors cannot easily copy, worth building (fraud model, scoring algorithm).
• Commodity infrastructure : a solved problem many vendors provide equally well, worth buying (email, blob storage, message queue).
• Total cost of ownership (TCO) : the full cost including initial build, ongoing maintenance, security patches, scaling, and on-call burden.
• Vendor lock-in : the cost and difficulty of switching from a third-party service once deeply integrated.
• Data sovereignty : regulatory requirement to keep sensitive data within specific jurisdictions, which can restrict vendor choice.

What is the core differentiator vs commodity question?

The first and most important question is whether the capability is a core differentiator or commodity infrastructure. Build differentiators, buy commodities.

package com.bank.design;

public class BuildBuyDecision {
    public String decide(String capability) {
        return switch (capability) {
            case "fraud_detection_model" -> "BUILD (competitive edge, proprietary data)";
            case "email_sending" -> "BUY (solved commodity, no edge)";
            case "core_ledger" -> "BUILD (regulated, sovereign, critical)";
            case "message_queue" -> "BUY (Kafka/SQS, commodity infra)";
            case "blob_storage" -> "BUY (S3, commodity, cheap)";
            default -> "Evaluate per capability";
        };
    }
}

What is total cost of ownership?

TCO goes far beyond initial development. Building includes ongoing maintenance, upgrades, security patches, scaling work, and the on-call burden. Buying includes license or usage fees but offloads most operational weight to the vendor.

package com.bank.design;

public class TcoComparison {
    public static void main(String[] args) {
        System.out.println("Build TCO: dev + maintenance + patches + scaling + on-call");
        System.out.println("Buy TCO:   license fees + integration + migration risk");
        System.out.println("Hidden cost of build: opportunity cost of engineers");
    }
}

What are the risk factors?

Vendor lock-in makes switching costly. Data sovereignty means sensitive banking data may not leave certain jurisdictions. Team expertise determines whether you can not only build it but maintain it for years.

Why is "we can build it better" expensive?

Even if the team could build a marginally better message queue, every hour maintaining it is an hour not spent on banking features. The opportunity cost compounds for years.

When should you build despite higher TCO?

Build when the capability is a genuine competitive advantage, when regulatory or sovereignty requirements prohibit third-party data handling, or when no vendor meets your specific technical requirements.

When should you buy despite risk?

Buy when the capability is commodity, when time to market is critical, when the team lacks expertise to build and maintain, or when the vendor TCO is clearly lower.

How do you manage lock-in risk?

Prefer vendors with open standards and portable data formats. Design with an abstraction layer so you can swap the implementation later.

package com.bank.design;

public interface NotificationSender {
    void send(String to, String message);
}
// Swap implementation from SendGrid to AWS SES without changing callers

What should a senior engineer know?

The decision is not permanent: buy to get to market, then selectively build later if a commodity becomes a bottleneck or differentiator. Judge honestly by TCO and opportunity cost, not by engineering ego.