Lessons from Shipping 6+ SaaS Products

Shipping SaaS products at pace is a specific kind of challenge. You are writing the code, making the product decisions, handling the infrastructure, and thinking about positioning, often simultaneously. The things that slow you down are rarely what you expect.

Here are the lessons the team has learned from shipping multiple SaaS products, some of which found traction and some of which did not.

Multi-Tenancy: Get the Architecture Right Early

The most expensive architectural decision in any SaaS product is multi-tenancy. If you build the first version as a single-tenant application and then need to add proper isolation later, you are often looking at a near-full rewrite.

There are three common approaches: shared schema with tenant IDs on every row, separate schemas per tenant, and separate databases per tenant. For most SaaS products at early stage, shared schema with row-level security (Postgres RLS policies) is the right default. It is simple to reason about, enforces isolation at the database layer rather than the application layer, and scales further than most products ever need to go.

A common early mistake: trusting application-level tenant filtering instead of enforcing it at the database. One missing `WHERE tenant_id = ?` clause is a data leak. Enforce it at the layer where it cannot be accidentally omitted.

Stripe Integration: Over-Engineer It Once

Stripe is not complicated. Until your billing logic becomes slightly non-standard, and then it is very complicated. The moment you add trials, proration, seat-based billing, or usage metering, the edge cases multiply.

My current approach: build the Stripe integration properly once, including webhook handling with idempotency checks, subscription status synced to your database, and clear separation between "what Stripe thinks" and "what your application thinks." Keep them in sync via webhooks, not polling.

The specific mistake to avoid: gating features based on live Stripe API calls. Call Stripe once, write the result to your database, gate everything based on your local state. This is faster, more reliable, and easier to test.

Authentication: Use a Provider, Not a DIY Solution

Writing your own auth is a time sink that almost never pays off. The session management, password reset flows, multi-factor auth, OAuth providers, and compliance requirements are not your competitive advantage. They are infrastructure.

We use Clerk for most projects now. It handles the complexity of auth correctly, integrates cleanly with Next.js, and removes an entire category of security surface area from what we have to maintain. The time saved goes directly into product work.

The one thing worth customising: how you represent the user in your database. Your auth provider knows about authentication events; your application needs to know about business entities. Keep those concerns separate and sync them cleanly on sign-up and update events.

AI Integration: Treat It Like Any External Service

Adding AI capabilities to a SaaS product is now close to table stakes in many categories. The implementation decisions that matter: which model for which task, how to handle latency in user-facing flows, and how to manage cost at scale.

The pattern we use: wrap all AI calls in a service layer that can swap models without touching call sites. Stream responses for user-facing generation so there is no perceived wait time. Cache aggressively where the inputs are predictable and the outputs do not need to be fresh. Log every AI call. Cost visibility is important early because it is easy to build a workflow that is economically unsustainable at scale.

On model selection: use the cheapest model that produces acceptable output for each task. Do not default everything to the most capable model. Structure your prompts to be explicit and predictable, which allows you to use faster, cheaper models for most operations.

The Decisions That Actually Matter

After shipping multiple products, the decisions I think about most carefully are not the technical ones. They are:

Who specifically is this for? A SaaS product that serves "small businesses" is underspecified. A product for independent music distributors, or for accountants who manage payroll for hospitality businesses, is specific enough to build to.

What does the customer do after they sign up? The onboarding flow is the most important thing to get right and the most commonly neglected. If a new user does not reach the core value within a few minutes of creating an account, you will lose them regardless of how good the product is.

What is the pricing model, and does it align with customer value? Per-seat, per-usage, flat-rate: the right answer depends on how customers experience value. If value scales with usage, flat-rate pricing creates a ceiling on revenue and a floor on cost. Get this wrong and you are either undercharging or making it hard for customers to justify the product.

The Part No One Tells You

Building SaaS products is mostly about decision-making under uncertainty with incomplete information. The technical work is learnable. The product sense, knowing what to build next, when to kill a feature, when to pivot, comes from shipping things, talking to users, and being honest about what the data is telling you.

The SaaS path is viable. Multiple products we have shipped are in active use. The ones that failed taught us something specific. The combination of technical fluency and direct responsibility for outcomes is genuinely different from working inside a large organisation, and it produces a kind of instinct that is hard to develop any other way.

If you are building something and want a technical or product perspective from a team that has been in that position, get in touch. Sometimes an outside view on an architectural decision or a positioning question is worth more than another week of building.