Episode 146 · A weekend prototype and a vendor's quote

Build vs buy: what should you own?

Wednesday, 11:00. StayHub's connectivity vendor wants 153,000 € a month to keep syncing rooms from 10,000 hotels, 45,000 € more than today. On Monday, an engineer built a sync with the biggest channel manager over a weekend. Karim asks: why are we paying anyone?

30 min advancedBuild vs buyCore vs context (what differentiates you)Total cost of ownershipIntegration and adaptation cost of bought componentsVendor exit strategyTrade-off thinking

Problem
StayHub's connectivity hub, which brings in rates and availability from ~10,000 hotels, raises its renewal price to €153,000 a month (+€45,000). An engineer built a weekend prototype, and Karim says we can build it ourselves. Which parts, if any, should StayHub write itself?
Why the simple system fails
Building everything burns the roadmap on commodities; buying everything by reflex leaves you with integration glue, per-unit bills that grow faster than revenue, and no way out when a vendor changes terms.
Engineering concept
Build what differentiates you (core), buy what doesn't (context), and compare the full cost of ownership, including integration, lock-in and the cost of leaving.
Technology
Core vs context mapping, 3-year TCO estimates, anti-corruption layers around vendors, exit plans and ADRs.
Trade-offs
Buying trades control and per-unit cost for speed and expertise; building trades speed and focus for control. The answer changes with scale, so write down when to revisit.

The problem

2 min

Wednesday, 11:00. Renewal talks with the hub that syncs rooms from ~10,000 hotels.

Karim · CTO
The hub wants 153,000 € a month, up from 108,000. And Dev synced our biggest channel manager over a weekend. Why pay anyone?
You · Engineer at StayHub
The prototype handles one channel manager. No retries, no certification, no monitoring.
Lina · Senior engineer, your mentor
You lead. What does the prototype actually prove?

The big idea

4 min

Core, context and the weekend prototype

The big idea

Build what differentiates you, buy what doesn't, and compare total cost over years, not the invoice against the weekend.

A restaurant cooks its signature dishes and buys the flour and napkins. It bakes its own bread only once bread is part of why guests come.

How it works

5 min

The decision, step by step

1
Core or context?
is what makes customers choose you; context is what anyone can buy. Fast sync with the top 3 channel managers is becoming core; the 30+ small ones are context.
2
Price 3 years
Total cost () includes build, fees, maintenance, risk and the transition, when you pay for both.
3
Contain the vendor
An : our own ChannelSyncPort with one adapter per vendor, so vendor concepts never spread.
4
Write the exit plan
Before signing, an : data export, notice period, which adapter changes, a revisit trigger.
5
Move one partner at a time
A router sends each hotel to a direct adapter or the hub, so any step can be undone.

Watch a decision being made

4 min

Worked example

You decide on connectivity (Lina checks)

Recommend what to build and what to buy, with three-year numbers and a way back.

1Sort core from context
Top 3 channel managers: 75% of rooms, overbookings, something hotels compare. Tail: context.
Why: Lina: "And where your scale pays for a team."
2Price three options over three years
A. Renew: 153k × 36 ≈ 5.5M €. B. Hybrid: 300k build + 918k hub during build + (55k team + 45k tail) × 30 ≈ 4.2M €. C. Build all ≈ 7.2M €.
Why: The transition, paying both, decides most of the total.

3Contain the vendor

Core code talks only to our interface:

export interface ChannelSyncPort {
  pullAvailability(hotelId: string, from: string, to: string): Promise<Availability[]>;
}
class HubAdapter implements ChannelSyncPort { /* vendor codes stay here */ }

Why: A misbehaving direct adapter means flipping hotels back to the hub: a config change.

4Set the trigger
Revisit when the hub bill exceeds 60k €/month or a 4th channel manager passes 5% of rooms.
Why: Per-unit pricing that's fine today can outgrow a team's cost.

In real life

3 min

Two well-known choices

Dropbox: built its own storage

Publicly described moving most storage from Amazon S3 to its own Magic Pocket
Storage is the product; at its scale owning it cut costs

Build when it's core and scale pays for a team.

Netflix: runs on a cloud it doesn't own

Publicly described moving onto AWS rather than its own data centres
Owns what's core instead: its CDN and recommendations

Buy the commodity, even at huge scale.

What goes wrong

3 min

Comparing the vendor's price with zero

"We already pay the engineers" ignores what they'd build instead.

Instead

Price engineer time fully loaded (~10,000 €/month).

Buying your differentiator

Competitors buy the same thing; your roadmap becomes the vendor's.

Instead

Build the core; buy only commodity pieces behind an adapter.

Treating open source as free

You run it: upgrades, patches, scaling, expertise.

Instead

Count operations time in the TCO.

Trade-offs

3 min

Option	Fits when	Costs
Build	It's core, or per-unit fees exceed a team	Slow start; maintenance forever
Buy (SaaS / API)	It's context and time matters	Per-unit growth; lock-in
Open source, self-run	Ops capacity, control needs	You operate it
Hybrid	Mostly commodity, a slice is yours	Two things to run; the seam

Thursday, 10:00. A different decision: StayHub's new loyalty programme.

Maya · Product manager
A loyalty SaaS is live in 6 weeks. Building is 5 months.
Karim · CTO
Loyalty is why guests come back. If we buy it, competitors buy the same thing.
Maya · Product manager
Guests care about rewards, not whose code runs the points.

Your job as tech lead

4 min

Claude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.

Decisions you own

What is core (top 3 sync) and what is context (the long tail, email sending).
The 3-year numbers you compare, with engineers at ~10,000 € a month fully loaded.
The exit measures for what you keep buying, and when to revisit.

Tell Claude Code

We'll build direct adapters for the top 3 channel managers and keep the hub for the long tail. First the groundwork in `src/connectivity/`. Plan first. Define our own ChannelSyncPort (push rates and availability, receive bookings, acknowledge) and move every hub SDK call behind a HubAdapter; core code must not import the SDK. Add a routing table defaulting every hotel to the hub, and contract tests from recorded hub traffic. No direct adapter yet; no behaviour change. List files importing the SDK before and after.

Check before you accept

The hub SDK appears only inside the HubAdapter.
The interface uses StayHub's terms (rate plan, room type, booking), not the hub's.
Contract tests pass against the HubAdapter before any direct adapter exists.

Red flags

Direct adapters for all 30+ channel managers "while we're at it".
Hub field names and error codes leaking into booking code.
Costs that count the hub fee but not the team and on-call.

Check yourself

2 min

Q1/3Decision

A startup sells an AI revenue-management tool to hotels: it suggests nightly room prices. Which capability is most clearly core and worth building?

How confident are you?

Next episode: availability events will flow through Kafka. Omar has run Kafka before and wants to run it himself; Karim has a managed-service quote.

Finished?

Mark it complete to update your skill map.

Next: Managed vs self-hosted: who carries the pager?

Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Interactive simulation, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.

Technical deep dive

Containing the vendor

Worked example

You decide on connectivity (Lina checks)

The hub's renewal is 153,000 €/month for ~900,000 rooms. Karim wants to build everything after a weekend prototype. Recommend what to build and what to buy, with three-year numbers and a way back.

1Sort core from context
Sync speed and accuracy with the top 3 channel managers (75% of rooms) affects overbookings and is something hotels compare: becoming core. The 30+ small integrations: context.
Why: Core is where owning it changes outcomes. Lina: "And where your scale pays for a team."
2Price three options over three years
A. Renew: 153k × 36 ≈ 5.5M €. B. Hybrid: build 300k + hub during build 918k + (55k team + 45k tail) × 30 ≈ 4.2M €. C. Build all: 2.16M + hub during 18 months 2.75M + 125k × 18 ≈ 7.2M €.
Why: Monthly costs mislead: the transition, while you pay both, decides most of the three-year total.
3Count the work the weekend skipped
Certification with each partner, rate limits, retries with idempotency, nightly reconciliation, monitoring, on-call, and keeping up with API versions.
Why: The first version is the cheap part. Integration work is often larger than the demo suggests.
4Contain the vendor
All sync goes through ChannelSyncPort; the hub and each direct integration are adapters; a router picks per hotel.
Why: It makes the migration gradual and reversible, and keeps the next re-decision a one-adapter change.
5Write the exit plan and trigger
Before signing the tail contract: daily full export, notice ≤ 6 months, only the hub adapter changes. Revisit when the hub bill exceeds 60k €/month or a 4th channel manager passes 5% of rooms.
Why: Per-unit pricing that's fine today can outgrow a team's cost. The trigger makes sure someone checks.

Cost line	A. Renew all	B. Hybrid	C. Build everything
Build	0	~300k € (5 eng × 6 months)	~2.16M € (12 eng × 18 months)
Hub during transition	n/a	~918k € (6 months)	~2.75M € (18 months)
Running cost after	153k €/month × 36	~100k €/month × 30	~125k €/month × 18
3-year total	~5.5M €	~4.2M €	~7.2M €
Main risk	Price rises again; slow sync	Two paths to run	18-month build; long-tail certifications

Illustrative numbers. The shape is what matters: transition costs dominate a three-year view.

Interactive simulation

Visual diagram

Guest / hotel staff

Auth (bought)

Booking + pricing core (built)

Integration adapters (built)

Payments (bought)

Hotel search (open source, self-run)

Channel manager (bought)

Your data (owned)

Click a component

A hotel booking platform with its build/buy boundaries. Click a component, or follow the walkthrough.

Analogy

A famous pasta restaurantYour software

A famous pasta restaurantFresh pasta made by hand dailyYour softwareCore: build it yourself
A famous pasta restaurantElectricity and card terminalsYour softwareContext: buy it
A famous pasta restaurantBought bread, house garlic butterYour softwareHybrid: buy plus a thin custom layer
A famous pasta restaurantA second bakery's number in the drawerYour softwareYour exit strategy

Where the analogy breaks: switching bakeries takes a phone call. Switching a payment or login provider can take months, because your code and data are tangled up with it. That's why the exit plan has to be built in from day one.

Check your understanding

Q1/3Design

You are about to sign with a channel-manager vendor. Which measures make leaving it later realistic? (Select all that apply.)

Select all that apply.

How confident are you?

Practice ladder

Step 1 · Trace

When does bought auth stop being cheaper?

Estimation Warm-up

StayHub's partner extranet uses a bought auth service at 0.01 € per monthly active user (MAU) per month. Alternatives over 3 years:

Self-run open source: ~15k € to set up, ~7k € infrastructure, ~0.15 engineer (~54k €) of maintenance. Total ~76k €, roughly flat with users.
Bought: ~10k € integration + 0.01 € × MAU × 36 months + ~18k € maintenance.

Trace the bought total at 200,000 MAU and at 2,000,000 MAU. Where's the break-even?

Step 2 · Complete

Finish the exit plan

Design Practice

Before signing the long-tail contract with the hub, complete the exit plan.

# Exit plan: connectivity hub (long tail)
Data we must be able to export: ___
Format and frequency: ___
Contract notice period: ___
Code that changes if we leave: ___
Rough migration cost: ___
Revisit when: ___

Step 3 · Solve

Buy or build the eval platform?

Decision Practice

The AI team wants an evaluation platform for the concierge, booking agent and extraction pipelines: golden sets, scoring runs, dashboards per prompt version.

Buy: an LLM-eval SaaS, ~4,000 €/month, live in 2 weeks; content must leave the EU (US hosting).
Build: on StayHub's existing traces and warehouse, ~2 engineers × 3 months, then ~0.3 engineer to maintain.
Evals decide which prompts and models ship; the golden sets contain redacted guest conversations.

Apply core vs context and TCO, and recommend.

Step 4 · Decide

Payments: build the orchestration?

Decision Stretch

StayHub pays hotels and charges guests through a payment provider. Product wants three new things: deposits for group bookings, split payments (guest pays part now, part at the hotel), and pay-later for long stays.

The provider offers a "marketplace payments" add-on that covers some of this, configurable but rigid.
Building the orchestration (rules for when and how much to charge, on top of the provider's charges and refunds) is ~4 months for 3 engineers.
Card processing, fraud and PCI compliance stay with the provider either way.

Write a short decision: "We chose X over Y because…, accepting the risk of…".

Explain it yourself

A founder asks: "Why don't we just build our own auth and payments? We have good engineers." Answer in your own words.

0 words