A founder I worked with spent four months building a custom analytics dashboard. Their developers were good. The dashboard looked great. Users mostly ignored it.
Six months later they replaced it with Mixpanel. Two weeks of integration work. Users actually started using it because it did things they hadn't thought to build.
Four months of engineering time. Gone. Not because the team was bad, but because the decision was wrong from the start.
Build vs buy is probably the most consequential technical decision you make as a SaaS founder. It's also the one most founders make on instinct instead of framework.
Why founders default to build
It feels like the right call. You're a software company. You build things. Buying tools feels like admitting defeat, or adding dependency, or giving margin away.
There's also the "we'll need custom functionality anyway" rationalization. It shows up early in almost every build decision. "Stripe doesn't do exactly what we want." "Auth0 doesn't support our edge case." "If we build it ourselves, we can make it exactly right."
Nine times out of ten, that rationalization is wrong. The edge case turns out to be minor. The custom functionality request comes from one customer. And by the time you realize it, you've spent 300 engineer-hours building the worse version of something a vendor has already spent 10 years perfecting.
The actual cost of building
The mistake is treating build vs buy as a cost comparison between your dev time and the vendor's monthly fee.
That's not how to think about it.
When you build something yourself, you're not just paying for the initial development. You're paying for:
Ongoing maintenance. Every feature you build is a feature you now own. Bugs need fixing. Edge cases need handling. When Node upgrades, your custom auth system might break. When your email provider changes their API, your custom notification system needs updating.
Opportunity cost. Those four months of dashboard development weren't free. They were four months your engineers weren't working on the core product features that would have made customers stay.
The expertise gap. A team of two engineers built your auth system in three weeks. Auth0 has 200 engineers who have been building auth systems for a decade. Your version is not going to be as good. It's also not going to be as secure.
Scaling surprise. Your home-built email queuing system worked fine at 100 customers. At 5,000 it fell over at 2am on a Tuesday. You can't always predict where homegrown systems break.
The real question isn't "build vs buy cost this month." It's "what's the total cost of ownership over three years, including all the time we don't spend on core product?"
The actual cost of buying
This side has its own traps.
Vendor lock-in is real. If your entire user management is inside Clerk, and Clerk raises prices 3x or gets acquired, you're in a tough spot. The migration cost is high enough that you'll probably just pay the new price.
Integration overhead adds up. Every SaaS tool you add is another system to integrate, monitor, and debug. When something breaks, you're now diagnosing: is it our code or their system? Third-party status pages become part of your on-call routine.
Pricing that doesn't scale with you. Many B2B SaaS tools charge per seat or per API call in ways that work fine at 50 customers and get painful at 5,000. That $99/month analytics tool becomes $2,000/month, and you still don't own it.
And sometimes the tool genuinely doesn't do what you need. If your product has genuinely novel workflow logic, there may not be a tool for it. That's the legitimate case for building.
The decision framework
I use five questions with every founder before making this call.
1. Is this in your core differentiation?
Your SaaS product has a reason people pay for it. It does something better than alternatives. That thing, whatever it is, should almost always be built.
Everything else is infrastructure. Auth is infrastructure. Email is infrastructure. Logging is infrastructure. Payments are infrastructure. These exist so you can build the actual product. Buying them is buying time to build the thing that matters.
If the feature you're considering building is in your core differentiation, build it. If it's infrastructure, buy it.
2. How well-solved is this problem?
If there are three established vendors with tens of thousands of customers and a decade of product iteration, you are not going to build the better version in a sprint. The problem is well-solved. Buy.
If there are no good tools, or the existing tools are clearly inadequate for your use case, build. But be honest with yourself. "The existing tools don't have our exact UI" is not the same as "the existing tools don't solve the problem."
3. What's the maintenance burden?
Some builds are one-time. You build a data pipeline, it runs, you rarely touch it. Others are ongoing maintenance sinks. Anything involving security, compliance, or external integrations tends to become a permanent maintenance tax.
Ask: in 18 months, how much ongoing engineering time will this require? If the answer is more than the vendor's annual fee, buy.
4. What are the real scaling implications?
"We'll build it now and replace it later" is sometimes the right call. But it requires being honest about when "later" is and what "replace it" actually costs.
If you're pre-product-market-fit, buying almost always makes more sense. Your constraints will change. Build what you understand now, buy the rest.
If you're post-PMF and scaling, think harder about the tools you're adding. Vendor pricing curves can surprise you.
5. Do you have the expertise to build it well?
Your team is good at your core product. Are they good at the thing you're about to build?
A team of product engineers is not automatically a team of infrastructure engineers, security engineers, or data engineers. Building auth is a security engineering problem. Building analytics is a data engineering problem. Building a payment system is a compliance problem. Wrong expertise, wrong decision.
Where founders get this wrong most often
Auth and user management. Building your own authentication is almost never the right call. Clerk, Auth0, Supabase Auth all handle the security edge cases you haven't thought of yet. SAML, MFA, passwordless, session management, brute force protection. The surface area is huge and the downside of getting it wrong is catastrophic. Buy.
Email. Transactional email is a deliverability problem as much as a technical problem. Your IP reputation, your bounce handling, your SPF/DKIM setup. Sendgrid and Postmark exist because this is genuinely hard and the stakes are high (emails that don't arrive mean customers who don't convert). Buy.
Search. Full-text search feels like a simple database query. It isn't. Relevance tuning, typo tolerance, faceting, indexing performance. Algolia and Typesense have solved this. Buy, unless search is your product.
Payments. Stripe is one of the best pieces of software ever built. It handles fraud, chargebacks, SCA compliance, international currencies, subscription logic, webhooks. Building any of this is a multi-year engineering commitment with legal liability attached. Buy.
Analytics. This is the one founders most often build themselves. It feels natural because you already have the data. But analytics is hard: data modeling, query performance at scale, visualization, cohort logic. Mixpanel, Amplitude, or PostHog give you this out of the box. Unless analytics is your differentiator, buy.
The legitimate cases for building
There are real situations where building is the right answer.
Your product IS the tool. If you're building a payment tool, you build your own payment logic. If you're building an email marketing platform, you build the email delivery. The whole point is that you're doing this better than what exists.
Compliance requirements. Sometimes regulations mean you can't send data to a third party. Healthcare, certain financial products, some government contracts. When data sovereignty isn't optional, you build.
The tool genuinely doesn't exist. Sometimes your workflow is novel enough that nothing on the market handles it. This is rarer than founders think, but it happens.
Scale economics have flipped. At $5K MRR, Mixpanel at $200/month makes sense. At $500K MRR, the same tool at $15,000/month might make the build case viable. Run the numbers at your actual scale.
A practical heuristic
When in doubt, I ask one question: "If we buy this tool today and want to replace it in two years, how painful is that migration?"
If the answer is "painful but survivable," buy now. Speed beats perfection when you're bootstrapped.
If the answer is "catastrophic, we'd have to pause product for six months," think harder about the dependency you're taking on.
The goal isn't to avoid all vendor relationships. It's to not get trapped in ones where you've lost all leverage.
The meta-point
Every hour your engineers spend building infrastructure is an hour they don't spend building your product. For a bootstrapped founder with two developers and 18 months of runway, that tradeoff is ruthless.
Buy the solved problems. Build the unsolved ones.
Where founders need help is usually not "which decision is right"; it's "how do I know which category this falls into." That's the judgment call that's hard to make from inside the problem.
If you're staring at a build vs buy decision and want a second opinion from someone who's made this call dozens of times, grab 30 minutes on my calendar. No pitch, just a technical sounding board.