DEV Community: Alexandre T.

How I Built a Production-Ready AI SaaS Boilerplate with Next.js 14 & Python FastAPI

Alexandre T. — Sat, 03 Oct 2026 08:09:44 +0000

Every time I set out to build an AI SaaS application, I hit the exact same brick wall.

I didn't want to spend my first 3 days setting up:

PostgreSQL connection pools & reconnect retry mechanisms
JWT authentication with Bcrypt password hashing
Stripe Checkout sessions and robust webhook listeners
Docker Compose synchronization so the DB doesn't crash on cold boot

Most boilerplates in the market focus solely on Node.js / Next.js. But if you are doing serious AI work (LangChain, LlamaIndex, fine-tuning, PyTorch, async workers), Python is the undisputed king.

So I built AI-Flow — a production-ready boilerplate uniting Next.js 14 App Router with Python FastAPI and PostgreSQL.

Here is an architectural breakdown of how it works under the hood.

1. The Architecture Breakdown

A clean SaaS architecture must decouple the frontend UX from the AI computing backend:

┌──────────────────────────────────────────────┐
│        Next.js 14 Frontend (App Router)      │
│  - Tailwind CSS & Dark Mode UI               │
│  - Centralized API Client (Bearer Tokens)    │
│  - Dashboard & Stripe Upgrade UI             │
└──────────────────────┬───────────────────────┘
                       │ HTTP / JSON
┌──────────────────────▼───────────────────────┐
│        Python FastAPI High-Speed Backend     │
│  - Pydantic v2 validation                    │
│  - JWT Auth (Register, Login, /me)           │
│  - OpenAI GPT-4o Integration Endpoint        │
│  - Stripe Checkout & Webhook Lifecycle       │
└──────────────────────┬───────────────────────┘
                       │ SQLAlchemy Pool
┌──────────────────────▼───────────────────────┐
│        PostgreSQL 15 Container               │
│  - Synchronized via Docker Compose           │
└──────────────────────────────────────────────┘

2. Eliminating Database Race Conditions on Cold Start

One of the most annoying bugs in Dockerized full-stack apps is FastAPI trying to query PostgreSQL before Postgres is ready to accept connections.

In database.py, we implemented a resilient startup retry loop:

def init_db(retries=5, delay=2):
    """Safely initialize database tables with retry logic on cold start."""
    for attempt in range(1, retries + 1):
        try:
            Base.metadata.create_all(bind=engine)
            print("Database connected and tables initialized.")
            return
        except Exception as e:
            print(f"Connection attempt {attempt}/{retries} failed: {e}")
            if attempt < retries:
                time.sleep(delay)
            else:
                raise e

Coupled with Docker Compose healthcheck testing pg_isready, startup failures are completely eliminated.

3. Bulletproof Stripe Webhook Resolution

In modern Stripe Checkouts, relying on session.customer_email can fail if users pay with Apple Pay or an alternative card.

We resolved this with a dual-lookup strategy:

Always pass client_reference_id=str(user.id) during session creation.
In the webhook, look up by client_reference_id first.
Fall back to session.customer_details.email, then session.customer_email.

This guarantees users are automatically upgraded to Premium immediately upon payment.

4. Launching AI-Flow on Product Hunt Today!

We officially launched AI-Flow on Product Hunt today!

If you are building an AI project, indie hacking, or shipping a SaaS, I would love your support and candid feedback:
Check out AI-Flow on Product Hunt & Join the Discussion

Launch Day Community Resources (20% OFF)

To celebrate launch day, here are the production-ready tools we opened up for developers:

** AI-Flow Full-Stack SaaS Boilerplate** (Next.js 14 App Router + Python FastAPI + Docker + PostgreSQL + OpenAI GPT-4o).
- Use launch promo code PH20 for 20% OFF!
** FastAPI Production Microservices Pack** (Standalone Auth + Stripe Billing microservices, JWT, bcrypt, tested with 18 automated tests).
** AI SaaS Prompt Engineering & System Prompts Vault** (36 production-grade system prompts in structured JSON with Python integration helpers).

I would love to hear your thoughts: What is your biggest challenge when combining Next.js with Python backends? Let's discuss in the comments below!

Why Most Cold Emails Land in Spam: The 4 DNS Authentication Layers Required for 10/10 InBox

Alexandre T. — Sun, 06 Sep 2026 09:49:06 +0000

Why Most Cold Emails Land in Spam: The 4 DNS Authentication Layers Required for 10/10 Deliverability

Engineering Insights by ApexSMTP Cloud Infrastructure • Full Technical Audit

If your outreach emails are landing in the Spam folder or Promotions tab, 90% of the time it is not your copy or subject line — it is a cryptographic or network-level authentication failure.

Here is the exact breakdown of how modern receiving filters (Google Workspace, Microsoft 365, Barracuda, Proofpoint) evaluate inbound SMTP connections in 2026.

1. The FCrDNS (Forward Confirmed Reverse DNS) Test

The most punishing test is FCrDNS:

When your server connects to Gmail on Port 25, Gmail takes your server's IP address (e.g., 185.12.177.92).
Gmail performs a PTR lookup on that IP, resolving it to a hostname (e.g., testapex2.apexsmtp.space).
Gmail immediately performs an A record lookup on that hostname to ensure it resolves back to 185.12.177.92.

If this two-way handshake fails:

Outlook 365: Outright connection drop (550 5.7.1 Service unavailable).
Google: Demotes email directly to the Spam folder.

2. RSA 2048-bit DKIM Key Length

1024-bit RSA keys can now be factorized with moderate compute. Modern mail transfer agents require RSA 2048-bit signatures.
At ApexSMTP, every server node generates clean 2048-bit private keys via OpenDKIM, ensuring cryptographic validation without truncation.

3. Strict SPF Alignment & DMARC

Your SPF record must explicitly authorize your dedicated IP:

v=spf1 ip4:185.12.177.92 ~all

Coupled with a compliant DMARC record:

v=DMARC1; p=none; sp=none; rua=mailto:support@apexsmtp.space;

How to Verify Your Score

You can test any dedicated node live:

Visit Mail-Tester.com to generate a temporary test address.
In your ApexSMTP console at https://apexsmtp.space/client, navigate to Test InBox.
Input the test email and click Exécuter le Test InBox en Direct.
Check Mail-Tester: You will see 10/10 Perfect Score.

Upgrade Your Sending Infrastructure

Stop risking domain burns on shared mailboxes. Deploy isolated dedicated nodes built specifically for high-volume B2B outbound:

👉 Start 48h Free Trial on ApexSMTP

👉 Read the 10/10 InBox Audit Guide

Case Study: How an Agency Fixed Google Workspace Bans and Reached 10/10 InBox on Instantly.ai

Alexandre T. — Sun, 06 Sep 2026 09:39:26 +0000

Case Study: How an Agency Fixed Google Workspace Bans and Reached 10/10 InBox on Instantly.ai

Published by ApexSMTP Infrastructure Engineering • Live Canonical Documentation

The Challenge: The 2026 Google Workspace Outbound Crackdown

In early 2026, a mid-sized B2B acquisition agency managing 45 sender inboxes across 15 secondary domains experienced an abrupt crisis: within 48 hours, 80% of their Google Workspace accounts were flagged or suspended.

Their cold outreach campaigns on Instantly.ai stalled completely:

Open rates plummeted from 48% to under 7%
Mail-Tester scores dropped to 5.5/10 (SpamAssassin penalties: RCVD_IN_DNSBL, T_SPF_HELO_TEMPERROR)
Monthly Workspace invoice: ~360€/month for burned, unusable inboxes.

Root Cause Analysis

Why did Google ban them?

Cross-Tenant IP Pool Contamination: Google Workspace routes outbound emails through shared server pools. If other users on the same subnet send low-quality messages, the entire IP range suffers reputation degradation.
Heuristic AI Pattern Matching: Google's 2026 anti-abuse algorithms detect warm-up peer rings (repeated identical message templates with high open/reply ratios inside closed pools).
Lack of Isolated FCrDNS: Shared hosts cannot give you custom PTR records matching your sending domain.

The Architectural Fix: Dedicated Private SMTP Nodes

Instead of buying more disposable Google accounts, the agency migrated their entire infrastructure to ApexSMTP Dedicated Private SMTP Nodes:

Metric / Feature	Google Workspace (Before)	Apex Dedicated SMTP (After)
IP Address	Shared Pool (Noisy Neighbours)	100% Dedicated Virgin IPv4
Reverse DNS (PTR)	google.com (Shared)	Strict FCrDNS (`testapex2.apexsmtp.space`)
DKIM Signature	Standard 1024/2048-bit	RSA 2048-bit OpenDKIM
Mail-Tester Score	5.5 / 10	Guaranteed 10 / 10
Monthly Cost	360€ / month	149€ / month (Growth Cluster)
Ban Risk	Extreme	Zero (Sovereign MTA)

Implementation in Instantly.ai (Under 30 Seconds)

Connecting the private SMTP node took less than a minute per account:

Instantly > Add Account > Custom SMTP / IMAP.
Host: testapex2.apexsmtp.space (or Dedicated Node IP).
Port: 587 with STARTTLS enabled.
IMAP Port: 993 (SSL) for automated reply tracking and bidirectional sync.

Results After 14 Days

Mail-Tester Score: Locked at 10/10 Perfect Score across all sending domains.
Open Rate: Rebounded to 54.2%.
Monthly Savings: 60% reduction in recurring software costs.
Zero Suspensions: Total infrastructure sovereignty with isolated reputation.

Test It Yourself (48h Free Trial)

ApexSMTP provides enterprise dedicated nodes with automated IP rotation and 10/10 InBox guarantee.
You can run a live InBox test or deploy a 48h trial cluster with zero credit card required:

👉 Deploy Your Free 48h Dedicated SMTP Node

👉 Read the Full Technical Guide

Technical Questions? Contact our DevOps on-call team at support@apexsmtp.space.