Build it, buy it, or partner up?

Hi Everyone,

Build, buy, or partner?

It's one of the most important decisions a growing company makes, and it keeps coming back.

Although AI has made building technology cheaper and faster, it doesn't mean you should consider all three options.

Answer these 5 questions to make a more informed decision.

1. Does this give us an edge that competitors can't easily copy?

This is the first filter. If the capability is what makes your product or service different, you want to own it. If it's not a core differentiator, let someone else handle it.

• Build if 70%+ of the features you need are unique to your business
• Buy if 70%+ are standard (billing, authentication, analytics almost always land here)
• Partner if you need someone else's distribution, infrastructure, or specialized expertise to deliver it well

2. What does this actually cost over three years?

Year-one comparisons are misleading. Model the full cost over 3-5 years before you commit.

• Build looks expensive upfront (eg, 3-5x the year one "buy" cost), but economics typically improve quickly in subsequent years
• Buy looks cheap in year one ($40-80K), but integration and customization can pile up fast (as well as those sneaky thresholds where annual rates skyrocket as usage volumes increase)
• Partner usually has the lowest upfront cost, but watch for revenue-share arrangements that eat into your margins as you grow

3. How much engineering time will this eat?

This is where build decisions go wrong most often. The project starts as a quarter of one engineer's time and slowly becomes two people's full-time job, lasting multiple quarters. Of course, there are a lot of dependencies to consider, but here are some quick rules of thumb to help:

• Build only if it won't take more than 30% of your engineering team's capacity for a single quarter
• If a system is non-core and requires more than half an engineer to maintain long-term, you should buy a solution or partner rather than maintain it internally.

4. How hard would it be to walk away?

Before signing with a vendor or partner, evaluate the exit risk. Consider how portable your data is, how mature the APIs are, whether alternatives exist, and how tightly the solution will integrate with your systems.

• Vendor risk: primarily technical lock-in. Poor data portability, proprietary formats, or deep integrations can turn leaving into a multi-month migration that consumes significant engineering time.
• Partner risk: primarily strategic dependency. If a partner controls distribution or a key part of your customer experience, switching might be technically easy but commercially expensive.

5. How fast do we need this working?

If building would delay your go-to-market by several months, you may want to buy or partner now and revisit the decision later when you have revenue and a clearer picture of what you need.

• Buy gets you to production fastest, typically 2 to 12 weeks
• Partner can be similarly fast when the integration is API-based
• Build often takes anywhere from 3 to 18 months for comparable results

Don't treat this as a one-time choice

The best teams buy or partner first to get to market fast, then build the pieces that truly differentiate them on top of that foundation, and reassess every 12 to 24 months as costs and needs shift.

A 2026 Retool survey of 817 companies found that 35% had already replaced at least one SaaS tool with a custom build. The reverse move is just as valid when maintenance is eating capacity you could use elsewhere.

Try this today

Pick the next build, buy, or partner decision on your desk. Have the person proposing it answer these five questions with specific numbers. If two or more come back as "we don't know yet," the proposal needs more work.

Go deeper

👉 AgilesoftLabs: Build vs Buy Software — CTO Decision Guide 2026 – a five-test framework with weighted scoring for each dimension

👉 Fivetran: How Okta saved 1,000 engineering hours – what happened when Okta stopped building data pipelines in-house

👉 CTO Executive Insights: Build vs Buy at Series A – practical thresholds for earlier-stage companies, including the 30% engineering capacity cap

Coming up on Monday

On Monday, we'll share a step-by-step process for talking to recent customers and turning their answers into a clear set of priorities.

Have a great weekend, Everyone!

P.S. What's the last thing your company built that you wish you'd bought or partnered on instead, or the other way around? We're curious which direction the regret usually goes.