What Not to Build in a SaaS: Build vs Buy for Auth, Email, Analytics and Payments

How do I decide what not to build, including authentication, email, analytics and payments?

Ask whether the feature is part of why customers choose you. If it is not, and a reputable provider does it well, buy it. Authentication, transactional email, payments and billing, and product analytics are the classic examples: each looks small but carries security, deliverability or compliance obligations that a specialist handles better. Keep your own code for the workflow that makes the product worth paying for.

Why this decision matters so much early on

In startup MVP development, every week spent on infrastructure is a week not spent on the thing customers pay for. Commodity features also tend to hide their real size. A login form is a few hours; a secure authentication system, with password resets, rate limiting, multi-factor authentication, session handling and account recovery, is weeks, and it is a security liability for as long as you maintain it. OWASP's Authentication Cheat Sheet lists the areas an implementation has to get right, including secure password storage, MFA, account recovery, throttling of login attempts, session management and error messages that do not reveal whether an account exists. A good authentication provider has done that work already. This guide is about infrastructure you can buy; for deciding which product features belong in version one, see our post on SaaS MVP planning and the SaaS MVP planning checklist.

The six decision criteria

1. Differentiation. Would a customer notice, and care, if this were done differently? If not, it is a commodity: buy it.
2. Risk. What happens if it is wrong? Security-sensitive features (authentication, payments, file uploads) punish small mistakes; specialists spend all their time on them.
3. Compliance. Does the feature bring legal or industry obligations, such as PCI DSS for card data or consent rules for analytics cookies? Buying can shrink those obligations.
4. Lock-in. How hard would it be to leave? Prefer providers that let you export your data and that use open standards where they exist (OAuth/OIDC for sign-in, SMTP for email, SQL for data).
5. Cost at scale. Per-user or per-event pricing that is negligible at a hundred customers can dominate costs at a hundred thousand. Model it at ten times your expected volume, using the provider's current pricing page.
6. Exit path. Before you integrate, write down how you would replace the provider. If the answer is "rewrite half the app", put an interface between your code and theirs.

A build vs buy table for common SaaS features

Authentication: the strongest case for buying

Choosing between authentication providers is mostly about where your users will sign in from and what your buyers will ask for. Check that the provider supports the methods you need (email and password, magic links, Google and Microsoft accounts), that it can add SAML or OIDC single sign-on when an enterprise buyer requires it, and that you can export users if you leave. Keep authorisation, meaning what each user is allowed to do inside each organisation, in your own code and database, because it is tightly bound to your data model. Our SaaS tech stack guide compares common options.

Payments and billing: let the specialist hold the card data

Card data is where building it yourself is most expensive. Stripe's integration security guide says that a business that handles sensitive card data directly might be required to meet more than 300 security controls in PCI DSS, and that its low-risk integrations send payment details directly to Stripe without passing through your servers, reducing your PCI obligations. Stripe Billing then adds subscriptions, invoices and retries, and Stripe's customer portal lets customers update payment methods, view invoices and change or cancel subscriptions without you building those screens. Your engineering work is connecting billing events to access rules; our guide to failed payments and dunning covers that part.

Email: deliverability is the hard part

Sending an email is easy; getting it into the inbox is not. Google's email sender guidelines require all senders to Gmail to set up SPF or DKIM, and bulk senders (more than 5,000 messages a day to Gmail accounts) to use SPF, DKIM and DMARC and offer one-click unsubscribe on marketing messages. A transactional email service handles the sending reputation and gives you logs when a password reset does not arrive. Send transactional and marketing email from separate streams or subdomains, so a marketing complaint cannot block your login emails.

Analytics: buy the tool, design the events

Product analytics tools are mature, so building your own pipeline at the MVP stage is rarely worthwhile. What you should own is the list of events, named and agreed before the build, so you can measure activation and retention. Check consent rules for your markets: in the UK, the ICO's guidance on storage and access technologies describes an exception for analytics where the sole purpose is statistics to improve your service and users are given clear information and a simple way to object, but advertising uses still need consent. EU rules differ, so take advice for your situation. For the wider picture, see our guide to GDPR and SaaS legal basics.

What you should build

• The core workflow and the data model behind it: this is the product.
• Authorisation rules: who can see and change what, in which organisation. See multi-tenant SaaS architecture.
• The glue: webhook handlers, background jobs and the logic that keeps your data consistent with providers.
• Anything a customer would describe as the reason they chose you.

When building the commodity is right

Building a commodity feature makes sense when a hard requirement rules out providers (data must stay on infrastructure you control, for example), when usage-based pricing has grown to exceed the cost of owning it including maintenance, or when the feature has become part of your differentiation. Make that decision with real usage numbers, not at the MVP stage. If you are unsure whether your current set of tools is costing more than it should, our guide to SaaS sprawl and software costs helps you audit it, and our SaaS development services team can review a build-or-buy plan before you commit.