DEV Community

cucoleadan
cucoleadan

Posted on • Originally published at vibestacklab.substack.com on

The Build vs Buy Scorecard

This post was originally published on my Substack publication as The Build vs Buy Scorecard.

You just asked Claude to build user authentication. In 90 seconds, you have working code. You deploy it. Two weeks later, you're debugging OAuth callback failures, implementing password reset emails, and researching session security.

Meanwhile, Clerk would've taken 30 minutes to integrate, or NextAuth (open source) would've given you the same functionality in 2 hours. AI never suggested either option because AI doesn't do that (by default).

AI coding tools have accidentally made the build vs buy problem worse.

Build vs buy decision framework illustration showing the three paths: build, buy, or use open source

Before AI, building was painful enough that you naturally researched alternatives. Now AI makes building feel free (just prompt it!), so you skip asking "should I build this at all?"

This results in codebases full of custom-built analytics, authentication systems, email handlers, and payment flows that could've been a $20/month service, a free open source package, or a simple integration.

AI is trained to write code, not to suggest alternatives. When you ask "build me a contact form," it doesn't pause to say "Tally does this for free" or "React Hook Form is a proven package."

When you ask for authentication, it doesn't stop to explain that Clerk, Auth0, Supabase Auth, or NextAuth exist.

AI defaults to building because that's how it was trained. Let's not forget that a LLM is just a large language model, so the way it works is that it predicts the next word. Now imagine if the vast majority of devs writing code were to suddenly add comments between lines // I recommend to use React Hook Forms or // It's best to buy Stripe than build this. That'd be kind of stupid.

AI training bias illustration showing how LLMs default to writing code instead of recommending existing tools

What's important to know is that every feature you're about to build has three paths:

  1. Build it from scratch (write everything yourself).

  2. Buy it (SaaS service like Stripe, Clerk, SendGrid or Brevo).

  3. Use it (open source library or package like NextAuth, Nodemailer, Chart.js, React Hook Form).

AI only shows you option 1 because that's what generates code. Options 2 and 3 are invisible in the AI workflow.

The opportunity cost compounds daily. Every hour spent debugging your custom-built analytics dashboard is an hour not spent on the AI keyword research algorithm that actually differentiates your product.

Every authentication edge case you handle manually is time Clerk or NextAuth already solved. You're burning your finite complexity budget on infrastructure while your competitors bought or installed the infrastructure and focused on unique value.

Every time you build with AI, you pay an invisible tax that speeds up your syntax but slows down your launch.

You write every line. You own every decision. You maintain everything forever. You debug every edge case. You explain it to AI six months from now when you need changes.

This path makes sense only when:

  • the feature IS your product's unique value (your AI algorithm, your core workflow, your proprietary data model);

  • no existing solution fits your specific requirements;

  • or you're learning and the educational value justifies the time cost.

Build your AI-powered keyword research algorithm (that's your product). Build your custom recommendation engine (that's your differentiation). Build your specific workflow automation (no tool does exactly this).

Don't build authentication, payments, email delivery, file storage, or analytics from scratch.

You pay monthly. They handle security, scaling, edge cases, and maintenance. You integrate via API or SDK.

This path makes sense when:

  • integration is simpler than building;

  • the service is proven and reliable (Stripe-tier quality);

  • the monthly cost is reasonable relative to your revenue or budget;

  • it's commodity infrastructure everyone needs (payments, auth, email, storage);

Buy Stripe for payments (don't build payment processing). Buy Clerk or Auth0 for authentication if you need enterprise features. Buy SendGrid or Resend for transactional email at scale. Buy Algolia if you need complex search with typo tolerance and instant results.

The cost is predictable, the reliability is proven, and you outsource an entire category of problems.

Free or low-cost. Battle-tested by thousands of developers. You install it, configure it, and own the deployment. You control the code but benefit from community maintenance and security patches.

This path makes sense when:

  • the package solves 80%+ of your need;

  • you can self-host or include it in your bundle;

  • you want control without building from scratch;

  • the package is actively maintained with good documentation.

Use NextAuth or Passport.js for authentication (free, proven, self-hosted). Use Nodemailer for email sending (free, just configure SMTP). Use Chart.js or Recharts for data visualization (free, customizable). Use React Hook Form for form handling (free, handles validation and state). Use Prisma or Drizzle for database ORM (free, type-safe, generates migrations). Use TanStack Query for data fetching (free, handles caching and refetching).

AI sees "authentication" and builds OAuth from scratch. It doesn't care NextAuth exists.

AI sees "charts" and builds D3 visualizations from scratch. It doesn't care that Chart.js exists.

AI sees "forms" and builds validation logic from scratch. It doesn't care React Hook Form exists.

Three paths decision flowchart showing build vs buy vs use decision criteria

This bias is structural (AI is trained to answer with code when asked not to recommend a tool) and you must be explicit about what you want to achieve before you start coding.

This 60-second check runs before you prompt AI to build anything. This framework forces you to research the three paths before writing a single line of code.

Build vs Buy Scorecard framework showing the 4-step decision process

Step 1: Name the Feature in Plain English

Be specific. Not "user management" but "email/password authentication with password reset and session management." Not "data display" but "interactive line charts showing time-series data with tooltips and zoom."

Step 2: Research All Three Paths (5 minutes)

Copy-paste this prompt into an AI tool with web access (like Perplexity, ChatGPT, or Claude):

I need to add [FEATURE NAME] to my application. Act as a senior tech lead and research the current market landscape for this feature.

Search for 'Buy' options: List 3 proven SaaS services that solve this problem (focus on established, developer-friendly tools).

Search for 'Use' options: List 3 popular, actively maintained open source packages or libraries for this (check for recent updates and high community usage).

Recommendation: Based on the complexity of this feature, write a 1-paragraph recommendation on whether I should Build (custom code), Buy (SaaS), or Use (Open Source).

Only include options that are currently active and reliable. If 3 valid options don't exist for a category, list fewer rather than hallucinating bad ones.
Enter fullscreen mode Exit fullscreen mode

Write down the best options it finds. If it comes back with "there are no good packages for this," you just validated that building might actually be necessary.

Step 3: Run The Scorecard

Answer 10 questions with three response options each. The scorecard reveals which path matches your situation.

Step 4: Make the Decision, Then Prompt AI

If Build: Give AI full context and expect to review heavily for edge cases.

If Buy: Skip AI entirely, read the service's integration docs, use AI only to help with the integration code.

If Use: Prompt AI to "integrate [package name] into my app" instead of "build [feature]." AI is much better at integration than building from scratch.

Answer each question, then count your responses. The path with the most votes wins. If tied, your answer to Question 1 (core value) is the tiebreaker.

Build vs Buy Scorecard table showing 10 questions with Build/Buy/Use columns for scoring

Click here to make a copy in Google Sheets.

How to Score:

Count your responses in each column. The column with the most votes is your answer.

  • Build wins: You selected "Build" 6+ times

  • Buy wins: You selected "Buy" 6+ times

  • Use wins: You selected "Use" 6+ times

  • Tied? Use Question 1 as tiebreaker: if core value is high, build; if commodity, buy or use

  1. Core value? Buy: Commodity infrastructure

  2. SaaS exists? Buy: Yes, Clerk/Auth0 exist

  3. Package exists? Use: Yes, NextAuth is proven

  4. Budget? Use: $0, pre-revenue

  5. Customization? Buy: Standard auth is fine

  6. Timeline? Buy: Need it today

  7. Maintain long-term? Buy: Want it handled

  8. Scale? Buy: Yes, pay for infrastructure

  9. Security? Buy: Want battle-tested security

  10. Learn or ship? Buy: Ship matters most

Result: Buy = 7, Use = 2, Build = 0 → Buy Clerk (or use NextAuth if budget is $0)

  1. Core value? Use: Need it but not my differentiator

  2. SaaS exists? Use: Services exist but overkill

  3. Package exists? Use: Yes, Chart.js/Recharts are proven

  4. Budget? Use: $0, bootstrapped

  5. Customization? Use: Moderate config needed

  6. Timeline? Use: 2-4 hours works

  7. Maintain long-term? Use: Community-maintained is fine

  8. Scale? Use: Client-side rendering, no scaling issues

  9. Security? Use: No security concerns

  10. Learn or ship? Use: Ship, but want to understand

Result: Use = 10, Buy = 0, Build = 0 → Use Recharts or Chart.js

  1. Core value? Build: This IS my product

  2. SaaS exists? Build: Generic SEO tools, not my approach

  3. Package exists? Build: No package for my specific method

  4. Budget? Build: Not about budget, about value

  5. Customization? Build: Extreme, it's proprietary

  6. Timeline? Build: Can spend 1-2 weeks

  7. Maintain long-term? Build: Very comfortable

  8. Scale? Build: Need custom scaling

  9. Security? Build: Not a security concern

  10. Learn or ship? Build: This is the product

Result: Build = 10, Buy = 0, Use = 0 → Build it yourself

The scorecard forces you to face reality before AI starts building a cookie based auth. When you see "Buy = 7" for authentication, you can't pretend building is the smart choice. When you see "Use = 10" for charts, you realize an npm package solves this in 30 minutes. When you see "Build = 10" for your core algorithm, you have permission to spend the time because it actually matters.

AI will always say yes to building. Your job is to ask "should I?" before AI asks "how should I?" That's what separates just coders from real product owners.

Top comments (0)