How I Build SaaS Products Before the Money Runs Out

Every SaaS product I have built under real startup conditions shares one defining constraint: the thesis has to be provable before the runway ends. That is not a philosophical point. It shapes every architectural decision, every third-party integration, and every feature you agree to cut. This is a field note on how I approach zero-to-one SaaS product engineering, written from the work rather than from theory.

Stack choices that buy you time

The biggest time sink in early SaaS is not the core feature. It is the plumbing: authentication, billing, background jobs, and data persistence.

For authentication, I stopped building custom flows entirely. Specialized identity-as-a-service providers like Clerk and WorkOS handle passkeys, enterprise SSO, and multi-tenancy out of the box. A founding team does not need to own that surface area. The risk is too high and the maintenance cost compounds.

For data, I default to PostgreSQL with the pgvector extension. A few years ago, a product with any AI-adjacent feature would have required a separate vector database alongside the relational store. That split created two systems to migrate, back up, and reason about under pressure. The unified approach cuts that overhead significantly, and the performance is production-grade.

For billing, the hybrid model is now the baseline expectation: flat-rate subscription tiers combined with usage-based metering. Billing engines like Lago integrate with Stripe and give you that flexibility without writing a billing system from scratch. Getting pricing architecture wrong at the start is expensive to unwind, so I treat it as infrastructure, not a product decision to defer.

When background AI work changes the shape of the product

The shift from simple prompt-and-response AI features to multi-agent workflows has changed what SaaS products can promise. Frameworks like LangGraph and CrewAI allow asynchronous, orchestrated background tasks that run without the user waiting at a screen. That changes the product model entirely.

Working on some projects, required background processing that coordinated state across multiple actors without blocking the primary UI. The architectural pattern there, separating the orchestration layer from the user-facing application, is the same one I now apply to AI-heavy SaaS products. The user submits a job. The system works. The result arrives. That loop is more robust than trying to stream everything synchronously.

The constraint that makes this hard is observability. When something fails inside an async multi-agent workflow, you need to know exactly which step broke and why. I instrument every agent node with structured logging from day one, not as a polish step. Debugging a silent failure in production with no trace is the kind of problem that kills a sprint.

Scoping the MVP without losing the thesis

The hardest conversation in a zero-to-one engagement is scope. A founder arrives with a product vision that is coherent and ambitious. The job is to find the smallest version that still proves the core thesis, not just the smallest version that ships.

With Job Hunter, a daily job board and outreach engine, the thesis was that automated crawling and personalized outreach could meaningfully reduce the manual work of a job search. The proof required the crawling to actually work at scale across 185+ career pages, and the outreach to be personalized enough to be useful. Cutting either of those would have invalidated the thesis. So we cut the dashboard polish, the notification preferences, and the export formats. Those came later.

The discipline is in knowing which features are load-bearing for the thesis and which are comfort features for the demo. Comfort features feel important in the room. They are not.

The multi-tenant architecture decision you cannot defer

For any SaaS product serving more than one organization, multi-tenancy is not an implementation detail you can bolt on later. The data isolation model has to be decided before the first migration runs.

I have worked across three approaches: shared schema with tenant IDs, separate schemas per tenant, and separate databases per tenant. Each has a different cost profile and a different ceiling. The shared schema approach is cheapest to operate at low scale and most painful to migrate away from when an enterprise customer requires stricter data isolation. I default to separate schemas unless the business model makes that operationally unworkable.

This is the kind of decision that belongs in a technical due diligence review before a product is built, not after. If you are heading into a seed round and your multi-tenancy model is undocumented or inconsistent, that will surface in the diligence process and it will slow the close.

Shipping the first version under real constraints

I built Fursa, a visa route eligibility product, with a narrow but precise scope: given a user's profile, identify which visa routes are actually viable across four destination countries. The constraint was that the underlying eligibility logic is complex, changes with policy updates, and cannot be wrong in ways that mislead a user into an expensive mistake.

The architecture separated the eligibility rules from the inference layer so that policy updates could be applied without redeploying the model. That separation added a week to the initial build. It saved far more time in the months after launch when the rules changed, as they always do.

Shipping under real constraints means making explicit trade-offs and documenting them. Not every trade-off is wrong. Some are correct given the information and the runway at the time. The ones that hurt later are the ones made without acknowledgment.

What the next step actually looks like

If you are building a SaaS product and trying to decide whether the architecture is sound before you commit more capital, that is a concrete problem with a concrete answer. I offer a focused technical review that looks at the stack, the data model, the multi-tenancy approach, and the billing architecture, and gives you a written assessment you can act on.

You can see the full range of product work across sectors at /work, including the SaaS and AI product case studies referenced here. If you want to talk through a specific build, the contact form is the fastest route to a real conversation.

The best time to pressure-test an architecture is before the first enterprise customer asks a question you cannot answer.