The Build vs Buy Decision: When to Write Code and When to Use SaaS

Every project I start involves this conversation: "Should we build this ourselves or use an existing service?" And every time, the founder's instinct is wrong in at least one direction. Either they want to build everything from scratch because "we might need to customise it later," or they want to use SaaS for everything because "why reinvent the wheel?"

Both instincts are partially right. The trick is knowing which applies where.

Never Build These

I'm going to be blunt. If your developer suggests building any of the following from scratch, question their judgement.

Authentication. Laravel has Fortify. There's Clerk, Auth0, Firebase Auth. Authentication is a solved problem with massive security implications if you get it wrong. I've been building web applications for 16 years and I still don't build auth from scratch. On every Laravel project, I use Fortify. It handles registration, login, password reset, two-factor auth — all properly secured, all tested by thousands of other applications.

Building custom auth is how you end up with password hashing bugs, session management vulnerabilities, and a two-factor implementation that doesn't actually work. Don't.

Email delivery. Use Postmark, Resend, or SES. They handle deliverability, bounce processing, spam compliance, and analytics. Building your own email sending means dealing with SPF records, DKIM signing, IP reputation, bounce handling, and the endless fight against spam filters. It's a full-time job disguised as a feature.

File storage and CDN. Use S3, Cloudflare R2, or similar. On the Rezzy project, we use Cloudflare R2 for image storage. It costs pennies per month and handles all the edge cases — thumbnail generation, CDN distribution, access control. Building this yourself is weeks of work for a worse result.

Payment processing. Use Stripe. Or if you must, PayPal or Square. Never, ever handle card details yourself. PCI compliance alone would cost more than your entire MVP budget. Stripe's fees are the cost of not having to think about payment security. It's the best money you'll spend.

Search. If you need full-text search beyond basic database queries, use Meilisearch, Algolia, or Elasticsearch. Building good search is deceptively complex — stemming, typo tolerance, relevance scoring, faceted filtering. The hosted services have spent years making this work properly.

Always Build These

Your core domain logic. This is the thing that makes your product different from everything else. The matching algorithm. The pricing engine. The workflow that's specific to your industry.

For TidyLinker, the core domain logic is: how cleaners get verified, how jobs get posted and matched, how the quoting system works, how career progression through certifications functions. No SaaS product does this because it's specific to this marketplace's value proposition.

For DevTrends, it was the intelligence pipeline — how 100+ sources get aggregated, deduplicated, and analysed to produce actionable developer insights. You can't buy that off the shelf because it's the entire point of the product.

If you can buy your core differentiator as a service, you don't have a product. You have a reskinned version of someone else's product.

Admin and operational tools. Your internal dashboards, approval workflows, and operational tools should be custom-built (or use something like Filament in Laravel, which gives you 90% of an admin panel for minimal effort). These tools encode your specific business processes and they'll change constantly as your operations evolve.

Data models and relationships. Your database schema is your business logic made tangible. The way your entities relate to each other reflects your specific domain. This always needs to be custom.

The Grey Area

Most decisions aren't obvious. They sit in the messy middle where either approach could work. Here's my framework for those:

Question 1: Is this a competitive advantage?

If the feature directly contributes to what makes your product better than alternatives, build it. If it's plumbing that every product needs, buy it.

Customer-facing scheduling in a cleaning marketplace? Build it — the UX of booking is part of your value proposition. Internal team scheduling for your own operations? Buy it — use Calendly or Cal.com.

Question 2: How much will you need to customise it?

If a SaaS tool gets you 90% of what you need and the remaining 10% doesn't matter, use it. If it gets you 60% and the remaining 40% is critical to your user experience, build it. That 40% gap will haunt you forever as workarounds, hacks, and user complaints.

I've seen founders adopt a SaaS tool for "80% fit" only to spend more time working around its limitations than building the thing from scratch would have taken.

Question 3: What's the switching cost?

If you adopt a service and later need to leave, how painful is that? Email delivery? Easy to switch — they all accept the same inputs. CMS? Much harder — your content structure is locked into their schema. Auth provider? Extremely painful — you're migrating user credentials.

The higher the switching cost, the more carefully you should evaluate the decision. For high switching-cost services, consider whether an open-source self-hosted option gives you more control. I use Coolify for deployment rather than Vercel or Heroku specifically because I own the infrastructure and can move it.

Question 4: What are the long-term economics?

SaaS costs are ongoing. Custom code costs are front-loaded. At small scale, SaaS almost always wins — you're paying pennies. At scale, SaaS costs can become eye-watering.

Do the maths. If a service costs £50/month now but scales to £500/month at your target user count, factor that in. If building it yourself costs £5k upfront but £20/month to run on your own infrastructure, the break-even point might be sooner than you think.

That said, don't optimise for scale you don't have. Paying £50/month for a service while you've got 100 users is fine. You can revisit when you've got 10,000 users and a revenue stream to fund the custom build.

Real Examples From My Projects

TidyLinker — Stripe Connect (Buy)

We use Stripe Connect for marketplace payments. Could I build a custom payment splitting system? Technically, yes. Should I? Absolutely not. Stripe handles KYC, bank payouts, refunds, tax reporting, and fraud detection. Building even a fraction of this would take months and expose us to financial risk. The 2.9% + 30p fee is the best money we spend.

Rezzy — Supabase (Buy, Then Partially Replace)

Rezzy uses Supabase for the database and real-time features. But we ended up building a Laravel API in parallel because Supabase's Row Level Security, while powerful, was creating complexity that a proper backend would handle more cleanly. Sometimes you start with "buy" and migrate to "build" as the requirements crystallise.

DevTrends — Content Extraction (Build)

For the intelligence platform, we needed to extract full article text from 100+ sources. There are APIs for this — Diffbot, Mercury Parser — but they didn't handle the specific sources we needed, and the extraction quality wasn't good enough for AI analysis. So we built a custom pipeline. The extraction logic is core to the product's value, so it made sense to own it.

The Decision Checklist

Before you build anything custom, answer these:

Is there an existing tool that does 90%+ of what I need?
Am I building this because it's genuinely needed, or because it's more fun to code?
What's the maintenance burden of building this ourselves?
What's the switching cost if the SaaS tool doesn't work out?
Will this matter in 6 months, or is it a launch-day concern?

Before you adopt any SaaS tool, answer these:

Does it handle my specific edge cases, or just the common ones?
What happens to my data if this company shuts down?
What's the cost at 10x my current scale?
Am I locking myself into their ecosystem?
Can my developer integrate this in hours, not weeks?

The best products I've built use a mix of both approaches, chosen deliberately rather than by default. Don't be dogmatic about either direction. Be pragmatic.

If any of this resonates, I work with founders directly — from early MVP planning through to scaling. No fluff, just practical engineering.