Product

Build vs Buy for MVP Components: Auth, Payments, Search

Decide when to build or buy auth, payments, notifications, analytics, CMS and storage for an MVP, including integration work, running costs and exit risks.

Apex Labs / / 5 min read

Buy anything that is not your product's core value and that has security, compliance, or deliverability risk: auth, payments, email delivery, and file storage. Build the parts that make your product different. For everything in between, buy first, put a thin wrapper around it, and keep your data exportable.

Compare usage-based charges, integration work and the cost of leaving. The vendor pages in References describe current commercial terms; this guide does not quote plan prices or quotas.

How to decide

Ask four questions for each component:

  1. Is it the reason customers choose us? If yes, build it.
  2. What happens if we get it wrong? Security, money, and deliverability failures are expensive.
  3. How hard is it to leave? Data portability decides this.
  4. What is the real cost at our expected volume, including engineering time to integrate and maintain?

A vendor bill is visible. Engineering hours spent maintaining a homemade version are not, which is why teams underestimate the cost of building.

Authentication

Buy options: Clerk, Auth0, Supabase Auth, Firebase Auth, or a library such as Auth.js or Better Auth that you self-host.

When to buildUnusual identity requirements, strict data-residency rules, or a very large user base where per-user pricing hurts
Hidden costsPer-active-user pricing growth, SSO and MFA gated to higher plans, vendor-specific session handling that leaks into your code
Exit difficultyMedium to high. Password hashes may not be exportable in the format you need, and users may need to reset passwords

We cover this in depth, including passwords, sessions, and social login, in our MVP authentication guide. Do not roll your own password storage.

Payments

Buy options: Stripe, Razorpay, and other regional gateways. For Indian businesses, Stripe vs Razorpay in India covers the differences.

When to buildAlmost never. You are not building a payment processor. Build only your own billing logic (plans, entitlements, invoices) on top of the gateway
Hidden costsTransaction fees, currency and cross-border rules, webhook handling, refund and dispute workflows, tax invoicing
Exit difficultyMedium. Stored card tokens usually cannot move freely between processors, so migration needs coordination with both

The real work is webhooks and state sync. Read reliable webhooks design before you ship.

Notifications: email, SMS, WhatsApp, push

Buy options: Resend, Postmark, or a similar transactional email service for email; an SMS provider for OTPs and alerts; the WhatsApp Business Platform for WhatsApp; Firebase Cloud Messaging or a push service for mobile push.

When to buildNever build the delivery layer. Build your own notification preferences, templates, and routing logic
Hidden costsDomain authentication (SPF, DKIM, DMARC), sender reputation, regional SMS registration rules, WhatsApp template approval, delivered-message charges and account-specific allowances
Exit difficultyFor email and SMS, migrate sender setup, templates, suppression lists and delivery events. For WhatsApp, account structure and provider permissions can restrict the exit path

For WhatsApp, see Cloud API vs BSP and templates, pricing and messaging windows. If you want to add WhatsApp to an existing product, our WhatsApp team builds on Meta's official Cloud API.

Analytics

Buy options: PostHog, Google Analytics, Plausible, Mixpanel, Amplitude.

When to buildRarely. Build your own event table only for numbers that drive billing or in-product features
Hidden costsEvent volume pricing, consent banners where regulation requires them, inconsistent event naming that makes data useless
Exit difficultyLow for new data, high for history. You can switch tools, but old data rarely moves cleanly

Decide what to track before you pick a tool: what to track in an MVP.

CMS

Buy options: a hosted headless CMS, an open-source CMS, WordPress, or content in Markdown/MDX files in your repo.

When to buildWhen content is really structured product data with workflow rules. Otherwise do not build an admin panel for marketing copy
Hidden costsSeat pricing, API limits, preview setup, content modelling effort
Exit difficultyMedium. Content exports well, but your content model and editorial habits are tied to the tool

How to choose a CMS covers the options in detail. For a handful of pages edited by developers, files in Git can avoid a CMS subscription, provided developer review and publishing time fit your budget.

Buy options: managed search such as Algolia, Typesense Cloud, or Meilisearch Cloud; or database full-text search in PostgreSQL.

When to buildWhen Postgres full-text search is enough. It often is for an MVP: add an index and a query
Hidden costsIndex sync jobs, relevance tuning, per-search or per-record pricing, typo tolerance expectations
Exit difficultyLow to medium. Your source of truth stays in your database; the index can be rebuilt elsewhere

Start by testing database search with representative queries. Add a search service when measured response times, relevance requirements or language support justify it.

File storage

Buy options: S3-compatible object storage from a cloud provider, or a storage service from your backend platform.

When to buildAvoid ephemeral app-server storage for durable user files; use persistent storage with an explicit backup and access model
Hidden costsEgress (download) fees, image processing, access control, virus scanning for public uploads
Exit difficultyOften manageable with object keys and portable metadata, but data transfer, permissions and API differences still need a migration plan

Use signed URLs for private files and keep the bucket name and base URL in configuration.

Keep your exit open

  • Wrap each vendor behind a small module of your own (sendEmail, createCheckout) so a swap touches one place.
  • Store your own user IDs and map vendor IDs to them.
  • Schedule periodic data exports and check that they restore.
  • Avoid vendor features that have no equivalent elsewhere unless they save real time.

Where to start

For most MVPs: buy auth, payments, email, and storage; use Postgres for search; start with a simple analytics tool; keep content in files or a light CMS. Build what makes your product different. If you are scoping an MVP and want help with this split, our product team works through it during planning.

References

  • build vs buy
  • mvp
  • saas
  • payments
  • notifications
  • search