Build vs. Buy – The “Commodity” Calculation

The “Not Invented Here” Trap #

The most expensive sentence in software engineering is: “We can build this ourselves in a weekend.” Engineers love to build. It’s fun. Building a custom Authentication system feels productive. Building a custom Feature Flagging tool feels clever.

The Logic Check: You are not factoring in the Total Cost of Ownership (TCO). Building the V1 is cheap (1 week). maintaining it for 5 years, patching security holes, updating it for new frameworks, and onboarding new devs to your proprietary spaghetti code is expensive (Millions). Code is a liability. The goal of an Architect is to solve the problem with the minimum amount of proprietary code.

The Core Logic: Wardley Maps (Genesis vs. Commodity) #

To decide, you need a strategy framework. The best one is Wardley Mapping. It classifies every component of your system into four phases:

1. Genesis: Brand new, undefined. (e.g., AI in 2020). Build.
2. Custom Built: We know what we want, but no standard exists. Build.
3. Product (Rental): Standardized tools exist (e.g., Jira, Salesforce). Buy.
4. Commodity (Utility): Invisible infrastructure (e.g., AWS EC2, Electricity). Buy.

The Rule: Only Build things that differentiate you from your competitors. Buy everything else.

• Does a custom “Login Page” make a customer choose your app over a competitor? No. (Buy Auth0/Clerk).
• Does a “Recommendation Engine” make a customer stay? Yes. (Build it).

Architecture Diagram: The Value Chain #

Visualize your stack. The lower down the stack you go, the more you should “Buy.”

graph TD
    User["User Value"] --> Core["Core Domain (Unique IP)"]
    User --> Support["Supporting Domain (Generic)"]
    
    %% ================= BUILD (High Value) =================
    subgraph Build ["Your Code (Build)"]
        Core --> Recs["Matching Algorithm"]
        Core --> Pricing["Dynamic Pricing Engine"]
    end
    
    %% ================= BUY (Outsource) =================
    subgraph Buy ["Vendor Code (Buy/Rent)"]
        Support --> Auth["Authentication (Auth0)"]
        Support --> Billing["Billing (Stripe)"]
        Support --> Search["Search (Algolia)"]
    end
    
    %% ================= UTILITY (Infrastructure) =================
    subgraph Utility ["Utility (Commodity)"]
        Auth --> Cloud["AWS / Azure"]
        Billing --> Cloud
        Recs --> Cloud
    end
    
    %% Note Definition
    NoteNode["Note: Focus 90% of your engineering hours <br/> on the 'Your Code' box."]
    
    %% Connect the note to the 'Your Code' section
    Pricing -.-> NoteNode

The Decision Matrix: The “Commodity” Score #

Before writing a line of code, run the feature through this matrix.

Real-World Case Study: Uber vs. Google Maps #

This is a masterclass in strategic shifting.

• Phase 1 (Startup): Uber Bought Google Maps.
  • Logic: Uber’s core value was “Booking a ride.” They needed a map, but they didn’t have the cash/time to map the entire planet. Using Google Maps was the only way to launch.
• Phase 2 (Scale): Uber Built their own Mapping Tech.
  • Logic: As they grew, “ETA Accuracy” became their core differentiator. Google Maps wasn’t precise enough for “Pick up on the left side of the street.” Also, Google increased the API price (Vendor Lock-in).
  • Shift: Maps moved from a “Commodity” to a “Core Domain” for Uber, so they insourced it.

The Lesson: “Buy” is not permanent. You Buy to move fast. You Build later if (and only if) that component becomes your strategic advantage.

Conclusion #

Opportunity Cost is the only metric that matters. If your Senior Engineer is spending 2 weeks debugging a custom generic “File Uploader,” that is 2 weeks they are not working on the feature that brings in revenue. Don’t be a hero. Be a business partner. Buy the boring stuff.