·5 min read

Build vs Buy: When Building Custom Is Worth It

Custom auth or Auth0? Homegrown email or Resend? My criteria for choosing between SaaS and custom development, with concrete examples.

TL;DR

Inner Gallery: custom encryption (competitive advantage). Coachy: auth and email via SaaS (no advantage in rebuilding them). The rule: build what differentiates you, buy the rest.

Auth0 or homegrown auth? Resend or SMTP server? Mixpanel or custom analytics? These decisions shape your architecture for the next 5 years.

The 4 criteria that decide everything

1. Long-term cost

SaaS looks cheaper at first. $29/month for Resend is peanuts compared to 2 weeks of email development. But multiply that by 5 years.

For Inner Gallery (a local app), email wasn't even necessary. Savings: $1,740/year. For Coachy (which will have user accounts), I built a simple email system with Nodemailer. Cost: $0 after development.

My rule: if the SaaS cost exceeds $2,000/year, I seriously consider going custom.

SaaS often costs less in the first year but more over 5 years. Think total cost of ownership.

2. Level of control needed

With a SaaS, you depend on their decisions. Pricing changes, deprecated features, acquisition by a competitor...

For Coachy's auth, I went custom. Why? I wanted seamless integration with my Event Sourcing system. SaaS solutions imposed their own data models.

Result: JWT auth + refresh tokens + custom EventStore. More upfront work, but total control over UX and performance.

3. Competitive differentiation

If you can copy-paste standard auth code, you might as well use Auth0. But if your auth becomes a competitive advantage, invest in it.

Inner Gallery: local PIN + biometric auth was crucial for the UX. No SaaS offered this specific combination. Custom was the only option.

4. Future scalability

SaaS scaling is expensive. Stripe takes 2.9% + $0.30. Acceptable at first, problematic at $100k/month in revenue.

But building a payment system from scratch? Suicide. Regulations, security, bank integrations... Stripe is worth its price.

My rule: if the feature is part of the core business (payments for a financial app), I consider custom. Otherwise, SaaS.

Authentication: Custom (PIN + biometrics)

Why custom:

  • Specific UX (unlock via PIN/Face ID)
  • Entirely local app, no auth server needed
  • Security-critical (private photos)

Time invested: 3 days

Cost avoided: N/A (no equivalent SaaS)

Analytics: None

Why neither SaaS nor custom:

  • Privacy promise (zero tracking)
  • App Store Analytics are enough for business metrics
  • Every analytics SaaS violates my privacy promise

Time saved: 5 days

Cost avoided: $300/month (Mixpanel)

Crash reporting: Basic custom

Why custom:

  • Privacy-first approach
  • Simple logs stored locally
  • Manual reporting by the user

Alternative evaluated: Crashlytics (free but Google)

My choices for Coachy

Authentication: Custom (JWT + EventStore)

Why custom:

  • Native integration with Event Sourcing
  • Specific data model (coach/client)
  • Auth0 cost prohibitive long-term ($5/user/month)

Time invested: 1 week

Cost avoided: $500/month projected

Email: Custom (Nodemailer + SMTP)

Why custom:

  • Custom templates for coaching
  • Integration with EventStore (full history)
  • Predictable volume (<10k emails/month)

Alternative evaluated: Resend ($29/month) -> $348/year savings

Push notifications: SaaS (Firebase)

Why SaaS:

  • Enormous technical complexity (iOS + Android)
  • No competitive differentiation
  • Reliability is critical, delegate to the experts

Cost: Free up to 10M messages/month

Build when it's your competitive advantage. Buy when it's standard plumbing. Simple but effective.

Classic mistakes

Over-engineering out of ego

I spent 2 weeks building a custom Redis caching system for Coachy. Result: 0.01% performance improvement for a massive maintenance cost.

Lesson: only optimize what matters. Premature optimization is the root of all evil.

Underestimating maintenance

Your custom code is yours to maintain for life. Bugs, updates, evolutions... A SaaS handles that for you.

For every "build" decision, I multiply the initial development time by 3. That covers maintenance over 3 years. If it's still cheaper than the SaaS, I go for it.

Ignoring hidden costs

SaaS = visible monthly cost. Custom = hidden cost of your time. Estimate your daily rate, multiply by development days, and compare with the SaaS cost over 2-3 years.

Decision framework

For each feature, I ask myself 4 questions:

  1. Differentiation: Does this feature set me apart from the competition?
  2. Control: Do I need deep customization?
  3. 5-year cost: Custom vs SaaS, which wins over time?
  4. Maintenance: Do I have the time and desire to maintain this?

If 3 out of 4 answers lean "custom," I build. Otherwise, SaaS.

Cases where SaaS always wins

Compliance and regulation

Payments (PCI DSS), email marketing (GDPR), health data storage... Regulations change constantly. Specialized SaaS providers keep up with these changes.

Building a GDPR-compliant payment solution from scratch? Good luck.

Third-party integrations

Zapier connects 5,000+ services. Rebuilding those integrations would take years. Same logic for CRMs, support tools, etc.

Complex domain expertise

ML, computer vision, NLP... Unless it's your core business, delegate to the experts. OpenAI for text, Algolia for search.

Building products on the side

When you're developing products in parallel with your main activity, time becomes your most precious resource.

My strict rule: 20% custom max per project. The rest with SaaS or existing solutions. Otherwise, you'll never ship your product.

Inner Gallery: 80% standard Swift + 20% custom security (Apple's CryptoKit)

Coachy: 70% standard Flutter/NestJS + 30% custom Event Sourcing

Build vs Buy is a business question. Build what differentiates you, buy the rest. Your time is limited -- use it wisely.

Also worth reading

build-vs-buysaasdevelopmentstartuparchitecture