Strategy • Engineering

Build vs Buy: A Decision Framework for Non-Technical Founders

Most founders get this decision wrong, and it costs them six months of runway. Here is a practical framework for knowing when to build custom software and when to reach for something off the shelf.

Mike Tempest • 10 min read • 25 March 2026

Every startup founder faces this decision dozens of times in their first two years. Should we build this ourselves, or should we use an existing tool? It sounds straightforward. In practice, it is one of the most consequential technical decisions you will make, and most founders get it wrong in predictable ways.

Technical founders tend to default to building. They see an off-the-shelf tool and immediately spot the limitations, the missing features, the ways it does not quite fit their use case. So they build their own version. Six months later, they have a bespoke authentication system that nobody wanted to maintain, a custom analytics pipeline that is always slightly broken, and an engineering team that has spent half its time on infrastructure instead of the product.

Non-technical founders tend to default to buying. They see building as slow, expensive, and risky. So they stitch together a dozen SaaS tools with Zapier and hope for the best. Six months later, they have a fragile integration layer that breaks every time a vendor updates their API, no real technical differentiation, and a growing sense that their product is just a thin wrapper around other people's software.

Both instincts are understandable. Both are expensive when applied without a framework. The goal is not to always build or always buy. It is to make the right call for each decision, based on whether the capability in question is core to your competitive advantage or commodity infrastructure that someone else has already solved.

The Real Cost of Building (It Is Not What You Think)

Development time is typically 20 to 30 percent of the total cost. Maintenance is the rest.

When your engineering team says "we can build that in two months," they are telling you the truth about initial development. What they are not telling you, because most engineers do not think about it this way, is the full cost of ownership.

Ongoing maintenance

Every custom system needs bug fixes, security patches, dependency updates, and performance tuning. A payment integration you build in-house needs to stay current with PCI compliance requirements. A custom authentication system needs to keep up with evolving security standards. This is not occasional work. It is a permanent tax on your engineering team's capacity, typically consuming 15 to 25 percent of the original build effort every year.

Opportunity cost

Every sprint your team spends building commodity infrastructure is a sprint they are not spending on your actual product. This is the cost that founders most consistently underestimate. If you have four engineers and two of them spend three months building a custom CRM integration, that is six person-months of product development you did not do. What features would you have shipped instead? What customer problems would you have solved? That is the real price.

Knowledge concentration risk

Custom systems create knowledge silos. The engineer who built your bespoke queue system is the only one who truly understands it. When they leave, and in startups people do leave, you inherit a system that nobody else can confidently modify. This is not a hypothetical risk. It happens constantly, and it creates a maintenance burden that compounds over time.

Hiring friction

Standard tools have standard documentation and a talent pool of people who know how to use them. Custom systems have neither. Every new hire needs to learn your bespoke solution from scratch, which slows onboarding and makes your team less productive during the ramp-up period. This cost is invisible but real, particularly when you are building your first engineering team and choosing your tech stack.

When to Build: Three Conditions That Justify Custom Software

Build when the capability is your competitive advantage, not when your engineers find existing tools annoying.

It is your core differentiator

If the capability is the reason customers choose you over alternatives, you should own it. Your recommendation algorithm, your pricing engine, your unique workflow automation, the thing that makes your product distinctly yours. This is where custom software creates genuine competitive advantage. If a competitor could replicate your value proposition by subscribing to the same SaaS tools you use, you have not built anything defensible.

No adequate solution exists

Sometimes there genuinely is no off-the-shelf solution that meets your requirements. This is more common in regulated industries where compliance requirements create unique constraints, or in novel technical domains where the market has not caught up yet. But be honest about this. "No solution does exactly what we want" is different from "no solution exists." The former is usually a customisation problem, not a build-from-scratch problem.

Vendor dependency would be an existential risk

If a single vendor's pricing change, API deprecation, or acquisition could threaten your business, that is a signal to own the capability yourself. This is not about avoiding all vendor relationships. It is about identifying the few capabilities where dependency would be dangerous. For most startups, this list is much shorter than their engineering team thinks it is.

When to Buy: The Commodity Test

If ten other companies have already solved this problem well, you do not need to solve it again.

The simplest test for whether to buy: if the capability you need is a solved problem with multiple mature solutions, buy it. Your competitive advantage does not come from having a slightly better authentication system or a marginally faster email delivery pipeline. It comes from the thing only you can build.

Almost always buy

+ Authentication (Auth0, Clerk, Firebase Auth)
+ Payment processing (Stripe, Adyen)
+ Email delivery (Postmark, SendGrid)
+ Error monitoring (Sentry, Datadog)
+ Analytics (Amplitude, Mixpanel, PostHog)
+ CRM (HubSpot, Salesforce)
+ Hosting and infrastructure (AWS, GCP, Vercel)

Almost always build

+ Your core product logic
+ Proprietary algorithms or models
+ Unique workflow automations
+ Domain-specific data pipelines
+ Custom integrations central to your value prop
+ Competitive moat features

The grey zone: payment processing

Payment processing is a good example of the nuance involved. For most startups, Stripe is the obvious answer. But if you are a fintech where payments are your core product, or if you operate in markets where Stripe's coverage is limited, or if your margin structure means Stripe's fees are a significant cost, building custom payment infrastructure may be justified. The answer depends on whether payments are commodity plumbing or a core differentiator for your specific business.

The Five-Question Framework

Run every build vs buy decision through these five questions. If you answer honestly, the right choice usually becomes obvious.

Is this our core differentiator?

Would a customer choose us over a competitor because of this capability? If the answer is no, it is probably commodity infrastructure. Buy it and move on. If the answer is yes, it deserves custom development and your best engineers' attention.

Does a good enough solution already exist?

Not a perfect solution. A good enough one. Engineers are trained to spot the gaps in existing tools and will always find reasons why the off-the-shelf option is not quite right. The question is whether those gaps matter to your customers or just bother your engineers. "Good enough" shipped today beats "perfect" shipped in six months.

Do we have the capacity to build and maintain this?

Building is not a one-off cost. Can your team absorb the ongoing maintenance, security updates, and bug fixes alongside your product roadmap? If you have a team of four engineers and two of them will spend the next quarter on this, that is half your product velocity gone. Be realistic about what your team can sustain.

What is the true total cost of each option?

For buying: subscription costs over three years, integration development time, potential migration costs if you outgrow the tool. For building: initial development, ongoing maintenance (multiply the build estimate by three for year-one total cost), infrastructure costs, and the opportunity cost of engineering time not spent on product. Most teams dramatically underestimate the build cost and overestimate the buy cost.

What else could the team build with that time?

This is the question that changes the most decisions. If you did not build this, what would your team ship instead? If the answer is "features that directly drive revenue or retention," the opportunity cost of building commodity infrastructure is very high. Your team's time is your scarcest resource, especially pre-Series A. Spend it on what only you can build.

The Hybrid Approach: Buy the Platform, Build the Differentiator

The best startups do not pick one or the other. They do both, deliberately.

The most effective approach is not pure build or pure buy. It is a deliberate hybrid where you buy everything that is not your core differentiator and build only the capabilities that create competitive advantage.

Think of it as layers. The bottom layer is commodity infrastructure: hosting, databases, authentication, monitoring. Buy all of this. The middle layer is business tooling: CRM, email marketing, analytics, customer support. Buy most of this, with some light customisation. The top layer is your core product: the unique value you deliver to customers. Build this, and build it well.

This approach has a compounding benefit. By not wasting engineering time on solved problems, you ship your core product faster. By shipping faster, you learn faster. By learning faster, you iterate your differentiator more effectively. The startups that try to build everything from scratch do not end up with a better product. They end up with a product that shipped six months later and an engineering team that is exhausted from maintaining infrastructure instead of innovating.

A practical example:

Consider a fintech startup building an AI-powered lending platform. The core differentiator is the credit risk model and the automated underwriting workflow. That is what you build. Everything else, authentication (Auth0), payments (Stripe), document storage (S3), email notifications (Postmark), error tracking (Sentry), you buy. Your engineering team spends 80 percent of its time on the thing that makes your product special and 20 percent on integration and customisation. That is a healthy ratio. If the split is closer to 50/50, you are building too much commodity infrastructure.

Where a Fractional CTO Adds Value

Build vs buy decisions are where non-technical founders are most vulnerable to bad advice. Your engineering team has an inherent bias towards building: it is more interesting, it gives them more control, and it adds to their portfolio. Vendors have an inherent bias towards you buying their product. Neither perspective is objective.

A Fractional CPTO brings something neither your team nor your vendors can provide: pattern recognition from dozens of companies. They have seen which build decisions created genuine competitive advantage and which became expensive maintenance burdens. They have evaluated hundreds of vendor solutions and know which ones deliver on their promises and which ones do not.

More importantly, they can model the true total cost of each option and challenge assumptions on both sides. When your engineers say "we need to build this," a good fractional CTO asks "why, specifically, and what is the maintenance commitment?" When a vendor says "our solution handles everything," a good fractional CTO asks "what about these three edge cases that matter for your specific business?"

This objectivity is particularly valuable in the first 12 months after funding, when the decisions you make about your technology roadmap set the trajectory for everything that follows. Getting three or four build-vs-buy calls wrong in that window can cost you a year of engineering velocity, which for a seed-stage startup is often the difference between raising a Series A and running out of runway.

The Bottom Line

Build vs buy is not a philosophical debate. It is a resource allocation decision that should be made pragmatically, based on whether the capability in question is your competitive advantage or commodity infrastructure. Most startups would benefit from building less and buying more, then redirecting the freed-up engineering time towards their core product.

The five-question framework makes these decisions more systematic and less driven by instinct or ego. Run every significant technical decision through it. Be honest about the answers, especially about maintenance costs and opportunity costs. And when in doubt, remember: your customers do not care whether you built your authentication system from scratch. They care whether your product solves their problem better than the alternatives.

Build what makes you unique. Buy everything else. And invest the time you save into shipping the product only you can build.

StrategyEngineering

Struggling with build vs buy decisions?

I work with funded startups as a Fractional CPTO, helping founders make the technology decisions that protect their runway and accelerate their product. Start with a free strategy day.

Book a Free Day Get in Touch

Frequently Asked Questions

How do I decide whether to build or buy software for my startup?

Ask five questions: Is this our core differentiator? Does a good enough solution already exist? Do we have the engineering capacity to build and maintain it? What is the true total cost of ownership for each option? And what is the opportunity cost of building this instead of something else? If the functionality is core to your competitive advantage and no existing solution fits, build. If it is commodity infrastructure that others have already solved well, buy.

What are the hidden costs of building custom software?

The initial development cost is typically 20 to 30 percent of the total cost of ownership. Ongoing maintenance, bug fixes, security patches, infrastructure, on-call support, documentation, and onboarding new engineers to the codebase all add up. Most founders underestimate these costs by a factor of three to five. A feature that takes two months to build may require two to three years of continuous maintenance.

When should a startup definitely buy instead of build?

Authentication, payment processing, email delivery, analytics, CRM, error monitoring, and hosting infrastructure are almost always better bought than built. These are solved problems with mature, well-maintained solutions. Building your own version diverts engineering time from your actual product and typically produces an inferior result. The exception is when you operate in a regulated environment with specific compliance requirements that no off-the-shelf solution meets.

What is the hybrid approach to build vs buy?

The hybrid approach means buying the platform and building the differentiator. Use off-the-shelf tools for everything that is not your core product, then build custom software only for the features that make your product uniquely valuable. For example, use Stripe for payments, Auth0 for authentication, and Datadog for monitoring, but build your core recommendation engine, pricing algorithm, or workflow automation from scratch. This gives you speed where it does not matter and control where it does.

How can a fractional CTO help with build vs buy decisions?

A fractional CTO brings pattern recognition from multiple companies across different stages and industries. They have seen which build decisions paid off and which became maintenance nightmares. They can objectively evaluate your technical team's capacity, assess vendor solutions without bias, and model the true total cost of ownership for each option. This experience is particularly valuable for non-technical founders who may not have the context to challenge their engineering team's natural preference for building.

Mike Tempest

Fractional CPTO

Mike works with funded startups as a Fractional CPTO, helping non-technical founders make better technology decisions. As Head of Engineering, he scaled RefME from 0 to 2M users, and as CTO turned Risika profitable in 18 months through business-first engineering.

Learn more about Mike