Choosing Technology: Build vs Buy Decisions for FDE Projects

Every design meeting produces the same two questions: "which technology do we use?" and "do we build this or buy it?" Both are judgment calls with real consequences. This tutorial gives you a repeatable framework for choosing technology and a scorecard for the build-vs-buy decision.

Table of Contents

• Why Technology Choices Matter
• The Selection Criteria
• Boring Technology Is a Feature
• Comparing Candidates: The Decision Matrix
• What Is a Build vs Buy Decision?
• The True Cost of Building
• The True Cost of Buying
• A Build vs Buy Scorecard
• Working Example: Build or Buy a Notification Service?

Why Technology Choices Matter

A technology choice is a commitment with a long tail. Pick a framework, database, or platform and you inherit its ecosystem, its quirks, its upgrade schedule, and its failure modes — for the life of the solution.

The choice matters in three places:

• Delivery speed — familiar, well-documented tools ship faster.
• Maintenance cost — someone pays for every upgrade, patch, and breaking change.
• Hiring and handover — when you leave, can anyone else run it?

In FDE work there's a fourth: the customer's environment. The best tool in the world is useless if the customer's IT team can't host it, secure it, or support it.

The Selection Criteria

Run every candidate technology through the same checklist:

Note: "fit" comes first deliberately. A mediocre tool that fits the problem beats an excellent tool you have to bend the problem around.

Boring Technology Is a Feature

"Boring technology" means technology whose failure modes are well known: it's been around, it's widely used, and surprises are rare. Postgres is boring. The database released last month is not.

The argument isn't against new tools — it's about spending your innovation budget. Every project gets a limited amount of novelty it can absorb. Spend it on the part that makes the solution special, not on the plumbing.

Innovation budget: 1 risky choice per project (roughly)

Spend it on:   the novel matching algorithm that solves the customer's problem
Don't spend:   an unfamiliar database, a new language, AND a new deployment model

Best Practice: default to what the team already runs in production. Familiarity is an underrated selection criterion — the fastest stack is the one you've debugged before.

Comparing Candidates: The Decision Matrix

When two or more options survive the checklist, score them in a matrix. Weight the criteria by what matters for this project:

Score 1–3 per cell, multiply by weight, sum. The numbers don't need to be perfect — the value is that the matrix forces you to name why you prefer one option, and the weights make the trade-offs explicit.

Note: if two options score within a couple of points, they're effectively tied — pick the more boring one and move on. Long debates over near-ties are how projects lose weeks.

What Is a Build vs Buy Decision?

Build vs buy is the question of whether to write a capability yourself or adopt something that already exists — a SaaS product, an open-source library, a managed service, or a platform feature.

It applies at every scale:

• Component level: write a PDF generator, or use a library?
• Service level: build an email service, or use SendGrid?
• System level: build a CRM, or deploy the customer onto Salesforce?

The instinct of many engineers is to build. The instinct of many managers is to buy. Both instincts are wrong sometimes — the answer comes from comparing the full costs, which are rarely what they look like.

The True Cost of Building

Building looks free because the first version is cheap. The real bill arrives later:

What building actually costs:
  ✓ First version          (the part everyone estimates)
  ✓ Bug fixes              (forever)
  ✓ Security patches       (forever, urgently)
  ✓ Upgrades & migrations  (every major release)
  ✓ Monitoring & on-call   (it's 2am and it's yours)
  ✓ Documentation          (or nobody else can touch it)
  ✓ Feature requests       (every stakeholder, forever)

A rule of thumb from the industry: maintenance costs 2–3× the original build over the system's life. If the first version takes two weeks, budget a month-plus of ongoing attention.

The True Cost of Buying

Buying looks expensive because the invoice is visible. But it has hidden costs too:

• Subscription fees that grow with usage and renew forever.
• Integration work — connecting it to the rest of the solution is still your job.
• Customization limits — when it doesn't do the thing, you can't just add the thing.
• Vendor dependency — price changes, feature removals, shutdowns, outages.
• Data lock-in — how hard is it to get your data out later?

Buying trades build risk for dependency risk. Neither is zero.

A Build vs Buy Scorecard

Answer these five questions and the decision usually makes itself:

The strongest signal is the first row: never build what is commodity, always consider building what is the differentiator. A logistics company's competitive edge is its routing logic, not its password-reset email.

Working Example: Build or Buy a Notification Service?

The delivery solution needs to send SMS and email notifications to drivers and customers. Running the scorecard:

Decision: buy — use a managed SMS/email provider behind a thin wrapper.

# Thin wrapper: keeps the vendor swappable
def send_notification(channel: str, to: str, template: str, data: dict):
    if channel == "sms":
        return sms_provider.send(to, render(template, data))
    if channel == "email":
        return email_provider.send(to, render(template, data))
    raise ValueError(f"Unknown channel: {channel}")

The wrapper is the quiet hero: the rest of the code never mentions Twilio or SendGrid, so switching vendors later is a one-file change. Buy the product, but own the interface.