You've got the schema, the auth flow and the core feature working, and real customers are starting to arrive. This is the point where the layer underneath starts to matter: the jobs, webhooks, email and internal tools that never show up in a demo. A first action that takes ten minutes: list every event that enters your product from outside (a Stripe payment, a calendar feed, an inbound email) and write next to each one where it gets retried, where it gets recorded, and where you'd see it fail. The blanks are your backlog.
This page is the hub for that layer. It covers six systems and links to a deeper guide on each one. If you're still deciding what to build first, the SaaS MVP development guide covers scope and sequencing before you reach this point.
What is SaaS backend infrastructure, and which parts does a production SaaS need?
SaaS backend infrastructure is the set of supporting systems around your database and API: background jobs, webhook handling, transactional email, notifications, a support inbox and an internal admin dashboard. They run when nobody is looking at a screen.
People searching for "SaaS backend architecture" usually mean the visible parts: the schema, the auth flow, the endpoints. The working definition I use for this layer is narrower: everything that has to keep behaving correctly when traffic is uneven, networks are flaky and external services fail. That gives six concrete systems.
| System | What goes wrong without it | Deep dive |
|---|---|---|
| Background jobs | Slow requests, scheduled work that silently stops | Background jobs for SaaS |
| Webhook handling | Duplicate charges, forged or dropped events | Webhook reliability |
| Transactional email | Password resets and receipts land in spam | Email deliverability |
| Notifications | Three unrelated features, none of them muteable | Notification system |
| Support inbox | Lost threads, no customer context | Support inbox |
| Admin dashboard | Hand-written queries on live data | Admin dashboard |
Why does this layer get skipped?
It doesn't demo well. You can't screenshot a retry queue, and a founder showing a product to investors shows the dashboard, not the nightly job that recalculates usage. This suggests the work gets deferred until the first incident makes it urgent. That is an inference, not a measured figure. The cheaper order is to add each system when its first external dependency appears.
How do background jobs and webhooks keep a SaaS reliable?
Background jobs move slow, scheduled or retryable work off the HTTP request path, and webhook handlers accept events that providers deliver at least once, so both have to tolerate retries and duplicates by design.
Which work belongs in a background job?
An HTTP request should do the minimum needed to respond and hand the rest to a job. Three kinds of work qualify:
- Slow work: report generation, image processing, third-party API calls that might hang.
- Scheduled work: nightly cleanup, usage rollups, digest emails, polling an external system.
- Retryable work: anything that can fail transiently and should be retried with backoff instead of failing the user's action.
BookBed, the Flutter and Firebase property management system I built solo over six months, is a good fit for the second and third kinds. Its iCal sync pulls calendars from Booking.com, Airbnb and Adriagate, and the case study notes that each exports slightly different formats. Reading external feeds like that is slow, scheduled and failure-prone, so it belongs off the request path. Whether you run it on a managed job runner or a queue you own depends on volume and how much operational surface you want. I compare the options in background jobs for SaaS: Inngest vs Trigger vs custom, and the Inngest walkthrough goes deeper on one of them.
What makes webhook handling reliable?
Delivery is at-least-once, so your handler sees duplicates and out-of-order events. Stripe's webhook documentation (checked 30 September 2026) says it attempts delivery for up to three days with exponential backoff in live mode, retries sandbox events three times over a few hours, and doesn't guarantee events arrive in the order they were generated. It also tells you to return a 2xx quickly before any complex logic, and to process events from an asynchronous queue.
Reliable handling rests on three things:
- Signature verification: confirm the request came from the provider before you act on it.
- Idempotency: record each event ID and skip ones you've already processed. Stripe's own advice is to log the event IDs you've handled.
- A dead-letter queue: events that fail every retry land somewhere you can inspect and replay.
This matters most around money. Callidus, the React, Firebase and Stripe Connect clinic SaaS I built, handles twenty Stripe webhook events end to end, including the 3D Secure escalation path for invoice.payment_action_required. The mechanics are in webhook reliability: idempotency and dead-letter queues, the billing side is in SaaS billing and payments, and the Postgres-flavoured version is the Stripe and Supabase subscription pattern.
How do email, notifications and a support inbox reach your customers?
Transactional email reaches the inbox when your sending domain authenticates with SPF, DKIM and DMARC and complaint rates stay low, and notifications and support replies work best as channels of one event pipeline, not separate features.
What does transactional email deliverability depend on?
Three DNS records: SPF says which servers may send for your domain, DKIM signs each message, and DMARC tells receivers what to do when those checks fail. Google's bulk sender requirements (Google Workspace Admin Help, checked 30 September 2026) require SPF, DKIM and DMARC for senders of 5,000 or more messages a day to Gmail accounts, ask you to keep the spam rate reported in Postmaster Tools below 0.30%, and have been mandatory since 1 February 2024. A small product sends far less than 5,000 a day, but the same setup is the sensible baseline.
Resend's domain documentation says you must verify at least one domain and recommends sending from a subdomain to isolate your sending reputation. BookBed ships eighteen-plus Resend email templates, and Pizzeria Bestek uses Supabase Edge Functions to send localized order emails in four languages (Croatian, English, German and Italian) through an account the restaurant owns. The DNS walkthrough is in email deliverability for SaaS: SPF, DKIM and DMARC.
How should notifications work across channels?
Treat in-app, email and push as one system with three delivery channels. An event creates a notification record, and a routing rule picks channels from the event type and the user's preferences. A "new booking" event might produce an in-app entry and a push, and skip email because that user muted booking emails. A preferences model per event type and channel is what keeps people from muting everything. The design is in building a SaaS notification system, and the engagement side connects to SaaS UX and growth.
What does a support inbox add?
Customer linkage. A contact form pointed at a personal inbox works until messages get lost and you can't tell which customer a thread belongs to. If you already send mail through a provider, you can receive and thread replies on the same rail and attach each thread to the customer record, so whoever answers sees the plan and recent activity. I cover the build in building a SaaS customer support inbox.
Why build the admin dashboard early, and how do the six systems fit together?
An internal admin dashboard turns support requests and incidents into a search box and a button instead of hand-written queries, and it's the place where failed jobs, dead-lettered webhooks and email errors become visible to you.
What belongs in it?
Start with customer lookup, subscription state and a view of recent failures: the dead-letter queue, failed jobs, recent email sends and webhook history. On per-tenant products like Callidus, which is sold to independent UK aesthetic clinics with strictly isolated tenants, the admin layer has to respect the same boundaries, so an operator looking at one clinic can't see another's data. The tenancy model is in multi-tenant SaaS architecture, access controls and audit trails in SaaS security and compliance, and the concrete build in the SaaS admin dashboard that saves hours. Once the dashboard exists, add telemetry so you find problems before customers do: observability for SaaS covers logs, metrics and alerts, and Sentry vs Datadog vs Honeycomb compares the tools.
How do the pieces connect?
They share a backbone. Consider a hypothetical booking arriving from a channel calendar: a webhook or feed import is verified and deduplicated, a background job records it, a notification fans out to in-app and push, a confirmation email goes out, the support inbox can later thread the guest's reply, and the admin dashboard shows the whole chain if any step fails.
Building this once is most of what "production-ready" means. For scale, caseStudies.ts records BookBed as a six-month solo build and Callidus as roughly ten weeks of solo work, and I'm an AI-augmented full-stack engineer, so I lean on tooling to keep that pace without skipping this layer; the AI-augmented development guide explains how. If you're budgeting the work, software development cost and pricing shows where hours go, and hiring SaaS developers covers how to vet for it.
Here's your next step: take the list of external events from the start of this page and pick the one that carries money. Can you answer, for that event, what happens on a duplicate, where a failure ends up, and which screen shows it to you? If any of the three answers is "nowhere", start there.