Overview

You're comparing two options: buy an AI recruiting tool for $100K/year, or have your IT department build a resume screening system. Your IT leader says: "We can build it for $200K one-time."

Which is cheaper? It depends on what you count. Most companies get this wrong, pick the "cheaper" option, and regret it years later.

This lesson teaches you total cost of ownership (TCO), the real cost of building vs. buying. You'll learn what costs to include and which hidden costs blindside you. You'll build a model you can use Monday morning. And you'll understand when to buy and when to build.

Why This Matters for HR Leaders

The build-vs-buy decision looks like a math problem but it's actually a strategic choice:

Buy (SaaS vendor):
- Pros: Predictable costs, vendor manages maintenance and updates, faster implementation
- Cons: Vendor lock-in, less customization, recurring cost, dependency on vendor

Build (in-house):
- Pros: Control, customization, one-time cost (in theory), intellectual property
- Cons: Ongoing maintenance, need internal expertise, slower to implement, hidden costs

The mistake most companies make: comparing Year 1 build costs ($200K) to Year 1 SaaS costs ($100K). Buying looks cheaper. But then in Year 2, you're still paying the SaaS vendor ($100K), plus you have to maintain the in-house build (which costs money). By Year 3-4, the in-house build is costing $50-75K/year in maintenance while you're still paying the vendor. Now the SaaS vendor looks more expensive.

Getting this wrong is expensive. Build it and regret it. Buy it and feel locked in. TCO analysis prevents both mistakes.

The TCO Framework: What to Count

Scenario 1: Buy (SaaS Vendor)

Year 1 Costs:

Category
Amount
Notes

Software license
$100,000
Annual SaaS fee

Implementation/integration
$50,000
Vendor setup, ATS integration, data migration

Training & change management
$15,000
Vendor training, internal training, communication

Internal project management (0.25 FTE)
$20,000
Your PM overseeing project

Year 1 Total
$185,000

Year 2-3 Costs (recurring annually):

Category
Amount
Notes

Software license
$112,000
10% annual increase

Support & maintenance
$15,000
Premium support, vendor updates

Internal PM & governance (0.1 FTE)
$8,000
Ongoing management, vendor relationship

Annual Cost (Year 2+)
$135,000

3-Year Total Cost:
Year 1 + Year 2 + Year 3 = $185K + $135K + $135K = $455,000

5-Year Total Cost:
$185K + ($135K × 4) = $725,000

Scenario 2: Build (In-House)

This is where most companies underestimate costs.

Year 1 Costs (Development Phase):

Category
Amount
Notes

Engineering time (1 FTE for 6 months, $120K salary)
$60,000
Your data engineer building the system

Data scientist time (0.5 FTE for 6 months, $150K salary)
$37,500
Model development and training

Infrastructure (AWS, cloud storage)
$15,000
Servers, database, storage

Tools & libraries
$5,000
Licenses for development tools

Testing & QA
$8,000
Manual testing, production readiness

Documentation
$3,000
Internal documentation

Project management (0.25 FTE)
$20,000
Overseeing project

Year 1 Total
$148,500

"Wait," you think, "that's cheaper than buying!"

But Year 1 is only development. The system isn't in production yet.

Year 2 Costs (Production + Maintenance):

Category
Amount
Notes

Engineering time (0.5 FTE for ongoing support, $120K)
$60,000
Maintaining system, fixing bugs, updates

Data science time (0.2 FTE for model retraining, $150K)
$30,000
Retraining model, accuracy monitoring

Infrastructure (AWS)
$20,000
More expensive at scale than Year 1

On-call support
$10,000
Someone available if system breaks

Tools & licenses
$5,000
Keeping up with updates

Year 2 Total
$125,000

Year 3 Costs (Ongoing Maintenance):
Similar to Year 2: ~$125,000

But wait, there are hidden costs in Year 2-3:

• What happens if your engineer leaves? You need to hire/train replacement ($30-40K onboarding cost)
  - Model accuracy degrades over time (model drift), your data scientist needs 0.5 FTE to retrain (already counted above, but often forgotten)
  - You want to add features (bias detection, interview summary), that's additional engineering time ($20-30K)
  - System breaks at 3am and your on-call engineer needs to fix it (already counted as on-call cost, but impacts morale/burnout)

3-Year Total Cost (Build):
$148.5K + $125K + $125K = $398,500

5-Year Total Cost (Build):
$148.5K + ($125K × 4) = $648,500

Comparing TCO: Buy vs. Build

Metric
Buy (SaaS)
Build (In-House)

Year 1 Cost
$185K
$148.5K

Year 3 Total
$455K
$398.5K

Year 5 Total
$725K
$648.5K

Maintenance Burden
Vendor's responsibility
Your responsibility

Scalability
Vendor handles
You handle (more cost)

Time to Deployment
3-4 months
6-9 months

Customization
Limited
Full

Risk of Person Leaving
Low (vendor manages)
High (lose engineer)

Model Updates/Retraining
Vendor's responsibility
Your responsibility

On pure cost, they're nearly equivalent by Year 5. So the decision isn't "which is cheaper" but "which fits our constraints?"

When to Buy

Buy if:

• 
  You need fast time-to-market. SaaS is live in 3-4 months. Build is 6-9 months.
• 
  You don't have data science expertise. Building requires a skilled data scientist. Buying avoids this dependency.
• 
  You want predictable costs. SaaS costs are known. Build costs are often underestimated.
• 
  You want vendor support. If something breaks, vendor fixes it. Build means you're on-call.
• 
  You want automatic updates. Vendor maintains and improves the model. Build requires you to retrain.
• 
  Risk tolerance is low. You can't afford a key engineer leaving mid-project.
• 
  The use case is common. If many vendors offer this (recruiting AI), buy from the best vendor. No need to reinvent.

Example: Buy Decision

A company needs resume screening ASAP. They have 50 open requisitions. Time-to-hire is their top metric. They don't have a data scientist. They want something live in 3 months.

Decision: BUY. Time-to-market and lack of internal expertise make buying the right call. The cost difference between buy and build is minimal, but buying gets them live in 3 months vs. 9 months.

When to Build

Build if:

• 
  The use case is unique to your company. You have proprietary data or logic that vendors don't support.
• 
  You have strong data science/engineering talent. You can actually build and maintain this.
• 
  Long-term control is critical. You need to own the system; vendor dependency is unacceptable.
• 
  Cost is the primary constraint, and you have engineering capacity. Over 5 years, build might be cheaper AND you're not paying recurring fees.
• 
  You need deep customization. Vendor can't adapt; you need to build from scratch.
• 
  This is a core capability. You want to build expertise and IP in this area.
• 
  Vendor market is immature. There's no good vendor option, so you build the best solution.

Example: Build Decision

A company has unique recruiting logic: they hire from a specific talent pool with unusual requirements. No vendor's resume screening works for their profiles. They have a strong data engineering team. They want to build a system that learns from their hiring success.

Decision: BUILD. Unique requirements + strong engineering + long-term strategic importance make building the right call.

The Hybrid Approach: Buy-and-Build

Some companies do both:

• Buy the base tool. Use a SaaS recruiting AI tool as the foundation.
  - Build custom layers. On top of the SaaS tool, build custom logic specific to your company.

Example: Buy Workable (ATS with some AI), build custom resume screening on top that learns from your hiring data.

Cost: Buy ($100K/year) + Build custom layer ($50K Year 1, $20K/year Year 2+) = Hybrid cost.

Benefit: You get vendor support for the base platform, but also custom capabilities.

Risk: Complexity. You're now dependent on both vendor and your engineering team.

The Build-vs-Buy Decision Matrix

Use this to decide systematically:

Criterion
Score (1-5)
Buy-Friendly
Build-Friendly

Time urgency
[1-5]
5 = need it ASAP
1 = can wait

Internal expertise
[1-5]
1 = don't have skills
5 = have strong team

Customization needs
[1-5]
1 = standard needs
5 = unique requirements

Cost constraint
[1-5]
5 = budget-focused
1 = budget-flexible

Long-term control
[1-5]
1 = okay with vendor
5 = need to own

Vendor maturity
[1-5]
5 = good vendors exist
1 = no good vendors

Scalability expectation
[1-5]
3-4 = vendor handles
1 = you can handle

Risk tolerance
[1-5]
5 = low risk tolerance
1 = high risk tolerance

Scoring:
- Average score 3.5-5: BUY
- Average score 2.5-3.5: HYBRID or EVALUATE CLOSELY
- Average score 1-2.5: BUILD

The Negotiation: Vendor Economics

If you decide to buy, negotiate TCO:

Multi-Year Discounts
Vendor: "Year 1 is $100K. Year 2 is $110K."
You: "If we commit to 3 years, what's the discount?"
Typical: 10-15% discount for 3-year commitment.

Usage-Based Pricing
Some vendors charge per user or per transaction.
Negotiate caps: "We'll pay per user, but max cost is $100K/year regardless of growth."

Implementation Included
Negotiate: "Implementation should be included in Year 1, not charged separately."
Vendor usually agrees if you're a big customer or committing to multi-year deal.

Price Increase Caps
Negotiate: "Annual increases capped at CPI, not whatever you want."
Typical cap: CPI + 2%.

Exit Terms
Negotiate: "What's our obligation if we want to leave? Can we get data out?"
Important: You want easy exit if the tool doesn't work.

CALLOUT BOX: The Hidden Costs Nobody Budgets For

When calculating TCO, don't forget:

Buy (SaaS): - On-call support (someone managing vendor relationship)
- Data quality work (cleaning data for the tool)
- Training (not just initial, but ongoing for new hires)
- Migration costs (if you switch vendors later)

Build:
- Key person risk (if engineer leaves, project stalls)
- Model retraining (ongoing cost, easy to forget)
- Infrastructure cost scaling (more users = more cloud cost)
- Burnout/morale (on-call support can burn out team)

Case Study: A Build Decision That Should Have Been a Buy

A financial services company decided to build predictive attrition in-house. Cost estimate: $150K (seemed cheaper than $100K/year SaaS).

Year 1: Built system, deployed. Cost: $150K. Great!

Year 2: Model performance degraded (model drift). Data scientist needed to retrain. Cost: $80K. Plus 2 weeks of CEO/CHRO time analyzing model. Not in budget.

Year 3: Engineer left. Replacement hired and trained. Cost: $40K in onboarding. System development stopped for 3 months.

Year 4: Model was 2 years old, barely maintained. Accuracy had declined 15%. Team decided to either rebuild or switch to vendor.

Decision: Switch to vendor (2-year contract, $100K/year).

Total cost:
- Build Years 1-4: $150K + $80K + $40K + $30K = $300K
- Vendor Years 5-6: $100K × 2 = $200K
- Total: $500K over 6 years

Vendor-only cost (hypothetical):
- Vendor Years 1-6: $100K × 6 = $600K
- Plus 1 engineer (0.1 FTE) to manage vendor relationship: $12K/year × 6 = $72K
- Total: $672K over 6 years

Outcome: Build was $172K cheaper, but the company:
- Lost 3 months of functionality when engineer left
- Had outdated model for 2 years
- Needed to rebuild/migrate anyway

Lesson: Pure cost isn't the only factor. Reliability, maintenance burden, and risk matter.

Deliverable: Your Build-vs-Buy Analysis

Create a 3-page document:

Page 1: TCO Comparison
- Buy 5-year cost: $X
- Build 5-year cost: $Y
- Difference: $Z

Page 2: Decision Matrix Scoring
- Your scores on the 8 criteria
- Recommendation (Buy/Build/Hybrid) based on average

Page 3: Risk & Justification
- Why this decision (not just cost)
- Key risks and mitigation
- Success metrics for the chosen path

What to Do Monday Morning

• 
  Build the TCO model for your specific initiative. Use your actual vendor quote (for Buy) and internal cost estimates (for Build).
• 
  Include realistic hidden costs. On-call support, training, maintenance. These add up.
• 
  Score yourself on the decision matrix. Be honest.
• 
  Run the numbers with both Finance and IT. Don't do this solo.
• 
  Negotiate if buying. Multi-year discounts, implementation included, price caps. These discussions happen before you sign.
• 
  Document the decision. Why you chose buy or build. What assumptions you made. This is your reference point later.

Key Takeaways

• TCO includes more than the obvious cost. Implementation, maintenance, support, training, count them all.
  - 5-year costs for buy and build are often similar. The decision isn't primarily cost; it's strategic fit.
  - Time-to-market and risk tolerance drive the decision more than cost. Need it fast? Buy. Have engineering capacity and patience? Build.
  - Vendor lock-in is real, but not always bad. The tradeoff for lock-in is predictability and support.
  - Build requires strong engineering talent. If you don't have it or you can't afford to lose key people, buy.
  - Hybrid (buy + build custom on top) is viable but more complex. Evaluate carefully whether the complexity is worth the benefit.

FAQ

Q: Our CFO says "build is always cheaper." How do we convince them otherwise?

A: Show a realistic 5-year model that includes maintenance, engineer time, infrastructure scaling. Most companies find build and buy are similar by Year 5. But buy gives you faster deployment and less risk.

Q: What if we build and it fails? Can we switch to a vendor?

A: Yes, but it's painful. You'll have a year of "stranded" build investment. Plan exit costs into your build decision.

Q: Is there a threshold where build is clearly better (e.g., cost savings >50%)?

A: Rarely. The only time build is clearly better is when you have strong engineering, unique requirements, and long-term strategic importance. Cost savings alone don't justify build.

Q: We want to build because we want to own the IP. Is that realistic?

A: You can own the code, but the IP (the model, the data) is only as valuable as the team that maintains it. If your data scientist leaves, the IP becomes worthless quickly.

Q: Should we build a POC and then decide?

A: That's reasonable for uncertain use cases. "Build a 2-week POC ($10K), prove the concept works, then decide buy vs. build for production." But POC costs are separate from the full build decision.

What's Next

You've made your build-vs-buy decision. Now you need to actually execute it. That requires change management, getting your team to adopt and use these new tools. That's Chapter 4.

Your financial decision tells you what to buy or build. Your change management tells you how to make it work.