The Build vs. Buy Decision: 15 Questions That Give You the Answer

The build vs. buy decision keeps business owners up at night. You're spending $30K, $50K, maybe $100K+ on technology. Make the wrong call and you're stuck with expensive software that doesn't fit, or custom code that becomes a maintenance nightmare.

Here's what nobody tells you: the decision isn't subjective. It's not about what you prefer or what your developer wants to build. There's a framework that gives you the answer based on objective business factors.

We've guided dozens of companies through this decision over 20 years. The ones who follow this framework make choices they don't regret. The ones who wing it? They're the cautionary tales.

The Framework: 15 Questions in 5 Categories

This isn't a quiz where you add up points. Each category reveals something critical about whether building custom or buying SaaS makes sense for your specific situation.

Let's be honest about what you're evaluating.

%%{init: {'theme':'base', 'themeVariables': {
  'primaryColor':'#e3f2fd',
  'primaryTextColor':'#0d47a1',
  'primaryBorderColor':'#1976d2',
  'secondaryColor':'#f3e5f5',
  'secondaryTextColor':'#4a148c',
  'tertiaryColor':'#fff3e0',
  'tertiaryTextColor':'#e65100'
}}}%%
graph TD
    A[Build vs Buy Decision] --> B[Business Criticality]
    A --> C[Customization Needs]
    A --> D[Timeline & Resources]
    A --> E[Team Capability]
    A --> F[Long-term Strategy]

    B --> B1[Core differentiator?]
    B --> B2[Business impact of failure?]
    B --> B3[Competitive advantage?]

    C --> C1[Workflow fit?]
    C --> C2[Integration complexity?]
    C --> C3[Industry-specific needs?]

    D --> D1[Time pressure?]
    D --> D2[Budget reality?]
    D --> D3[Resource availability?]

    E --> E1[Technical capability?]
    E --> E2[Maintenance capacity?]
    E --> E3[Knowledge retention?]

    F --> F1[Vendor lock-in risk?]
    F --> F2[Growth trajectory?]
    F --> F3[Exit strategy?]

    style A fill:#1a202c,stroke:#4a5568,color:#ffffff
    style B fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    style C fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    style D fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    style E fill:#e3f2fd,stroke:#1976d2,color:#0d47a1
    style F fill:#e3f2fd,stroke:#1976d2,color:#0d47a1

Category 1: Business Criticality (Questions 1-3)

Question 1: Is This System Core to Your Business Differentiation?

If this software is how you compete differently, build it. If it's just infrastructure everyone needs, buy it.

Examples that demand custom:

• A logistics company whose routing algorithm is 20% more efficient than competitors
• A consulting firm whose project estimation model is their competitive secret
• A manufacturer whose production scheduling system enables faster turnarounds

Examples where SaaS is fine:

• Email marketing (everyone uses Mailchimp or equivalent)
• Accounting (QuickBooks works for 90% of businesses)
• HR management (BambooHR, Gusto, etc. are commodities)

The real question: If competitors copied your exact software setup, would you lose your advantage?

If yes, build. If no, buy.

Question 2: What's the Business Impact If This System Fails for 24 Hours?

This reveals how critical the system really is, not how critical you think it is.

High-impact scenarios (often justify custom):

• Your order processing system goes down = no revenue
• Manufacturing scheduling fails = production stops
• Customer-facing app crashes = brand damage and lost sales

Lower-impact scenarios (SaaS is often fine):

• Project management tool is unavailable = minor inconvenience
• Internal wiki is down = reference documents inaccessible
• Social media scheduler fails = you post manually for a day

Calculate the actual dollar cost of downtime. If it's over $10K per day, you need control that custom provides.

SaaS vendors have uptime SLAs, but you're one customer among thousands. With custom software, fixing your emergency is the only priority.

Question 3: Does This Create Competitive Advantage or Just Maintain Parity?

Be brutally honest. Most business software is table stakes, not differentiation.

Competitive advantage indicators:

• Customers choose you partly because of this capability
• You can charge more because of what this enables
• Competitors don't have equivalent functionality
• This enables a business model others can't replicate

Table stakes indicators:

• Every competitor has similar functionality
• Customers expect this but don't pay extra for it
• You're just matching industry standard capabilities
• Absence would hurt, but presence doesn't help

The companies that should build custom are the ones where the software IS the business advantage, not just supporting it.

Category 2: Customization Needs (Questions 4-6)

Question 4: Do Off-the-Shelf Tools Actually Fit Your Workflow?

Not "can we make them work with workarounds." Do they actually fit?

Red flags that suggest build:

• Every SaaS demo ends with "we'd need a custom integration for that"
• You're told "just change your process" more than twice
• The workaround involves exporting to Excel, manipulating, then importing back
• Core workflow features are on three different platforms

Green lights for buy:

• 80%+ of features match your needs out of the box
• Customization is configuration, not coding
• Your processes are industry-standard
• Integrations exist for your other tools

When a SaaS company tells you "most customers adapt their workflow," what they mean is "our software doesn't fit and we won't change it."

If you're adapting core business processes to fit software, you're doing it backwards.

Question 5: How Complex Are Your Integration Needs?

Modern business software doesn't exist in isolation. It needs to talk to other systems.

Integration complexity matrix:

Integration Scenario	Complexity	Recommendation
Simple APIs<br/>Standard REST endpoints, well-documented	Low	SaaS works fine
Multiple Systems<br/>3-5 platforms need to sync data	Medium	Zapier/Make for now, custom later
Real-time Requirements<br/>Data must sync instantly across systems	High	Lean toward custom
Complex Transformations<br/>Data structure changes between systems	High	Custom likely needed
Bi-directional Sync<br/>Changes in any system update all others	Very High	Custom strongly recommended

Real example: A 40-person distribution company needed their inventory system to talk to their ordering platform, shipping system, accounting software, and customer portal. Every data change needed to propagate in real-time.

They tried Zapier. It cost $500/month and broke constantly. They built a custom integration layer for $25K. It's been running three years with minimal maintenance.

Question 6: Are Your Requirements Genuinely Industry-Specific?

Some industries have needs generic software can't address. Most think they do but actually don't.

Actually industry-specific (often justifies custom):

• Healthcare: HIPAA compliance requirements that go beyond standard security
• Manufacturing: Production scheduling with your specific machine constraints
• Distribution: Routing logic based on your unique geography and customer requirements
• Professional services: Project costing models specific to your delivery methodology

Think they're unique but aren't (SaaS works):

• "Our approval workflow is complex" - every company thinks theirs is special
• "We need custom reporting" - most BI tools can build any report
• "Our sales process is different" - it's probably not as unique as you think
• "We track metrics that are specific to us" - custom fields exist in most platforms

The test: Can you find three competitors using the same SaaS tool successfully? If yes, your needs aren't that special.

Category 3: Timeline & Resources (Questions 7-9)

Question 7: What's Your Real Timeline?

Not the aspirational "it would be nice to have it by" timeline. The actual business-driven deadline.

Timeline analysis:

Need It By	Reality Check	Recommendation
Next month	Custom is impossible unless it's tiny	Buy SaaS immediately
3 months	Custom is rushed and risky	Buy unless extremely simple build
6 months	Custom is feasible for moderate complexity	Consider both options
12+ months	Custom is viable for complex systems	Build likely makes sense if other factors align

Real scenario: A professional services firm needed project tracking "right now" because they were hemorrhaging money on projects without visibility.

They bought Teamwork. It wasn't perfect, but it was working in two weeks. Later, when they had breathing room, they evaluated whether to switch to custom. By then, Teamwork was good enough.

Time pressure is the biggest reason to buy, even when build would be better long-term.

Question 8: What's Your Honest Budget Reality?

Not what you wish you could spend. What you can actually afford, including maintenance.

Budget framework for a mid-complexity business application:

Custom Development:

• Initial build: $30K-$80K (depending on complexity)
• Annual maintenance: 15-20% of build cost ($5K-$15K)
• Hosting: $200-$1,000/month
• Unexpected fixes: Budget 10% extra
• 5-year total: $100K-$200K

SaaS Platform:

• Year 1: $5K-$15K (lower tier)
• Year 2: $10K-$25K (growth pricing kicks in)
• Year 3: $15K-$35K (per-user costs scale)
• Year 4-5: $20K-$50K each (enterprise tier)
• Integration costs: $5K-$10K total
• 5-year total: $80K-$180K

The crossover is closer than most people think, especially once you factor in SaaS price escalation.

The question isn't which is cheaper. It's which you can afford with your cash flow reality.

Custom requires upfront capital. SaaS spreads costs but you can't stop paying. Which matches your financial situation?

Question 9: Do You Have the Resources to Manage Development?

Building custom software requires someone to oversee it. Not full-time, but someone needs to own it.

Required capacity:

• Someone to define requirements (10-20 hours initially)
• Someone to review progress and provide feedback (2-4 hours weekly during build)
• Someone to test and validate (10-15 hours before launch)
• Someone to coordinate with developers (ongoing relationship)

If you don't have anyone with 5-10 hours per week to dedicate during development, you're not ready to build custom.

The companies that succeed with custom development have an internal champion who owns the project. The ones that fail delegate it completely to developers and hope for the best.

Category 4: Team Capability (Questions 10-12)

Question 10: Can Your Team Maintain Custom Software?

Building it is one thing. Keeping it running is another.

Realistic maintenance needs:

• Security updates: Quarterly (critical)
• Dependency updates: Monthly (important)
• Bug fixes: As needed (urgent when they happen)
• Feature enhancements: Ongoing (as business evolves)
• Performance optimization: Annually (prevents degradation)

Who can handle this:

• In-house developer: Ideal
• Retained development partner: Works well
• Original developer on retainer: Acceptable
• No plan: Disaster waiting to happen

Real story: A 35-person company built a great custom CRM with a contractor. Two years later, the contractor retired. The system still worked but they couldn't add features or fix bugs. They were stuck.

They eventually paid $40K to have another developer reverse-engineer the codebase just to be able to maintain it.

Question 11: Do You Have Technical Judgment in Leadership?

You don't need to code. But someone making decisions needs to understand technology implications.

Technical judgment means:

• Understanding cost/benefit of technical choices
• Spotting when developers are over-engineering
• Knowing when "impossible" means "hard" vs. actually impossible
• Evaluating technical vendor claims critically

You might be in trouble if:

• You accept every developer recommendation without question
• You have no idea if cost estimates are reasonable
• Technical decisions happen in a black box
• You're at the mercy of whoever you hire

You don't need to be technical. But you need someone who can translate between business needs and technical reality.

A non-technical CEO with a technical co-founder or CTO can build custom successfully. A non-technical team outsourcing everything will struggle.

Question 12: What Happens When Your Developer Leaves?

Single developer dependency is a massive risk with custom software.

Risk mitigation strategies:

• Documentation requirements in development contract
• Code must be well-commented and standard architecture
• Knowledge transfer requirements if contractor leaves
• Escrow agreements for critical systems
• Multiple developers review code

Bad signs:

• Only one person understands the system
• No documentation exists
• Code is "clever" rather than clear
• "I'm the only one who can work on this" statements

The best custom software is boring. Standard frameworks, clear code, good documentation. The flashy "cutting-edge" stuff is what leaves you stranded.

Category 5: Long-term Strategy (Questions 13-15)

Question 13: How Much Does Vendor Lock-in Concern You?

With SaaS, you're married to that vendor. Breaking up is expensive and painful.

Vendor lock-in risk factors:

• Proprietary data formats that don't export cleanly
• Workflows built around platform-specific features
• Integrations that only work with that vendor
• Accumulated customization that doesn't transfer
• Training investment that's platform-specific

Real costs of switching:

• Data migration: $5K-$30K
• Process retraining: $10K-$50K in lost productivity
• Integration rebuild: $10K-$40K
• Customization recreation: $20K-$100K
• Parallel running period: 2-3 months of double costs

Some companies accept lock-in because the platform is great. Others discover too late they're hostage to price increases and feature changes they hate.

Custom gives you ownership. SaaS gives you dependency. Neither is automatically better, but know which you're choosing.

Question 14: What's Your 5-Year Growth Trajectory?

How you'll grow dramatically impacts the build vs. buy math.

SaaS pricing typically scales with:

• Number of users (per-seat pricing)
• Data volume (storage/processing limits)
• API calls (usage-based pricing)
• Feature tier (unlock capabilities as you need them)

If you're growing from 20 to 200 employees, your SaaS costs might 10x. Custom costs stay relatively flat.

Growth scenarios:

Growth Path	SaaS Economics	Custom Economics	Winner
Slow & Steady<br/>20-30 employees over 5 years	Manageable cost increases	Upfront cost harder to justify	SaaS
Rapid Scale<br/>20-100+ employees in 3 years	Costs explode with users	Fixed cost advantage	Custom
Uncertain<br/>Might grow fast or stay stable	Flexibility valuable	Risk if growth doesn't happen	SaaS
Already Mid-Size<br/>50-100 employees today	Already expensive	Break-even happens faster	Custom

Question 15: What's Your Exit Strategy?

If you might sell the business in 5 years, that changes the calculation.

How buyers evaluate technology:

Custom software can be:

• An asset: "Proprietary system that enables our margins"
• A liability: "Technical debt we'll need to rebuild"
• Neutral: "Works fine, not differentiated"

SaaS subscriptions are:

• Transparent: Clear ongoing costs
• Standard: Buyers understand them
• Transferable: Easy to continue
• Not an asset: They don't add value

If you're building to sell, custom software either adds significant value (if it's core differentiation) or creates buyer concern (if it's just infrastructure they'll need to maintain).

If exit is the plan, bias toward SaaS unless the custom software IS what makes the business valuable.

The Decision Matrix: Putting It Together

Here's how to use these 15 questions to make your decision:

%%{init: {'theme':'base', 'themeVariables': {
  'primaryColor':'#e3f2fd',
  'primaryTextColor':'#0d47a1',
  'primaryBorderColor':'#1976d2',
  'secondaryColor':'#f3e5f5',
  'secondaryTextColor':'#4a148c',
  'tertiaryColor':'#fff3e0',
  'tertiaryTextColor':'#e65100'
}}}%%
graph TD
    A[Start: Build vs Buy] --> B{Q1-3: Business Critical?}
    B -->|Yes| C{Q4-6: Custom Needs High?}
    B -->|No| Z[Strong Buy Signal]

    C -->|Yes| D{Q7-9: Have Time & Budget?}
    C -->|No| Y[Lean Buy]

    D -->|Yes| E{Q10-12: Team Can Maintain?}
    D -->|No| X[Buy Now, Build Later?]

    E -->|Yes| F{Q13-15: Strategic Fit?}
    E -->|No| W[Partner for Maintenance]

    F -->|Yes| G[Strong Build Signal]
    F -->|Mixed| H[Hybrid Approach]

    style A fill:#1a202c,stroke:#4a5568,color:#ffffff
    style G fill:#2e7d32,stroke:#1b5e20,color:#ffffff
    style Z fill:#f57c00,stroke:#e65100,color:#ffffff
    style H fill:#f3e5f5,stroke:#9c27b0,color:#4a148c

Strong signals to build custom:

• 3+ "business criticality" questions point to custom
• Customization needs are genuinely unique
• You have budget and timeline flexibility
• Technical capability exists or can be acquired
• Strategic factors favor ownership

Strong signals to buy SaaS:

• System isn't core differentiation
• Off-the-shelf tools fit reasonably well
• Time pressure is real
• Budget constraints favor lower upfront costs
• No technical capability and no plans to build it

The middle ground (most companies):

• Mix of factors pointing both directions
• Consider hybrid approaches
• Prototype with SaaS, plan custom for later
• Build core, buy periphery
• Start simple, evolve strategically

Real Examples: Framework in Action

Case 1: Distribution Company - Built Custom

The situation: 50-person wholesale distributor with complex routing needs.

How they scored:

• Business criticality: High (routing efficiency was competitive advantage)
• Customization: High (their geography and customer requirements were unique)
• Timeline: Flexible (9-month project)
• Budget: Available ($60K upfront)
• Team: Operations manager could oversee, hired dev partner
• Strategy: Rapid growth planned, vendor lock-in was concern

Decision: Built custom routing system

Result: System cost $60K to build, $8K/year to maintain. SaaS alternatives would have cost $30K/year and couldn't handle their specific needs. Break-even in 3 years, but real value was enabling service level competitors couldn't match.

Case 2: Professional Services Firm - Bought SaaS

The situation: 25-person consulting firm needed project management.

How they scored:

• Business criticality: Medium (important but not differentiating)
• Customization: Low (workflow pretty standard)
• Timeline: Immediate (projects were already over budget)
• Budget: Preferred spreading costs
• Team: No technical capability
• Strategy: Focused on consulting, not software

Decision: Bought Teamwork

Result: $300/month subscription, working in two weeks. Not perfect, but solving 80% of problems immediately. They revisit annually whether to build custom, but haven't needed to.

Case 3: Manufacturing Company - Hybrid Approach

The situation: 80-person manufacturer with complex production scheduling.

How they scored:

• Business criticality: Mixed (some processes unique, some standard)
• Customization: High for scheduling, low for inventory
• Timeline: Flexible
• Budget: $40K available
• Team: Engineering manager technical enough
• Strategy: Growth-focused, wanted control of core processes

Decision: Built custom scheduling, bought inventory SaaS

Result: Custom scheduling system cost $35K, integrated with $200/month inventory platform. Best of both worlds—control where it mattered, standard tools where they didn't need customization.

Common Decision Mistakes to Avoid

Mistake 1: Letting Developers Decide

Developers want to build. It's more interesting than configuring SaaS. This doesn't mean building is wrong, but the decision shouldn't be purely technical.

Your developer's preference isn't the deciding factor. Business economics are.

Mistake 2: Assuming SaaS Is Always Cheaper

For the first year, yes. Over 5 years? Often no, especially if you're growing.

Run the actual numbers. Factor in:

• Price escalation as you scale
• Per-user costs across all employees
• Integration and customization fees
• Data export costs if you ever leave

Mistake 3: Underestimating Customization Needs

"We'll adapt our process" sounds reasonable until you're forcing square pegs into round holes daily.

If the SaaS demo requires more than two "we'd need to customize that" statements, you're probably underestimating the fit gap.

Mistake 4: Overestimating Your Uniqueness

Most businesses aren't as unique as they think. Your approval workflow probably isn't that special. Your reporting needs are likely standard.

If competitors use SaaS successfully, question whether you really need custom.

Mistake 5: Ignoring Maintenance Reality

Custom software without a maintenance plan is a ticking time bomb.

Before you build, answer:

• Who updates dependencies?
• Who fixes security vulnerabilities?
• Who adds features as business evolves?
• Who helps when something breaks?

If you don't have good answers, you're not ready to build.

When to Reconsider Your Decision

Build vs. buy isn't permanent. Conditions change.

Signals to move from SaaS to custom:

• Monthly costs approaching what annual maintenance would cost
• Spending hours on workarounds because platform doesn't fit
• Hitting feature/user limits that require expensive tier jumps
• Strategic decision to own core business systems
• Integration costs spiraling because platform doesn't connect well

Signals to move from custom to SaaS:

• Maintenance burden exceeding value delivered
• Platform has caught up to your custom features
• Technical team can't keep up with necessary updates
• Business priorities shifted away from this area
• Cost of ongoing development no longer justified

The best answer today might not be the best answer in three years. Revisit the decision as your business evolves.

Working with Thalamus on Build vs. Buy Decisions

We've guided dozens of companies through this framework over 20 years of enterprise development. Sometimes we recommend building custom (and help you build it). Often we recommend SaaS solutions that fit better.

Our business model is 50/50 product development and client services. This means:

• We don't push custom development to drive billable hours
• We have deep experience with both custom and SaaS implementations
• We know the real costs because we've lived both sides
• We can help whether you choose to build or buy

If you're facing a significant build vs. buy decision and want experienced perspective:

• We'll work through this framework with your specific situation
• We'll help you run the real economics for both options
• We'll identify risks and mitigation strategies
• We'll give you honest guidance even if that means less work for us

Because making the right decision beats making the profitable recommendation. Every time.

The Bottom Line

The build vs. buy decision isn't subjective. These 15 questions reveal the objective answer for your business:

1. Business criticality - Is this core to your differentiation?
2. Business impact - What does failure cost?
3. Competitive advantage - Does this enable something competitors can't do?
4. Workflow fit - Do off-the-shelf tools actually match your process?
5. Integration complexity - How hard is connecting this to other systems?
6. Industry specificity - Are your needs genuinely unique?
7. Timeline reality - When do you actually need this working?
8. Budget constraints - What can you afford upfront vs. ongoing?
9. Resource availability - Can you manage development?
10. Maintenance capability - Can you keep it running?
11. Technical judgment - Do you have tech-savvy leadership?
12. Developer dependency - What happens if they leave?
13. Vendor lock-in - How much does dependency concern you?
14. Growth trajectory - How will you scale over 5 years?
15. Exit strategy - Might you sell the business?

Strong signals in 3+ categories toward the same direction gives you your answer. Mixed signals suggest hybrid approaches or staged strategies.

The companies that answer these questions honestly make decisions they don't regret. The ones who skip the analysis? They're the cautionary tales.

What's your honest answer?