DEV Community: BuildMintZ Media

How to Build a Production-Ready SaaS Integration Layer on Azure and AWS (.NET 8)

BuildMintZ Media — Fri, 17 Apr 2026 00:04:43 +0000

I Rebuilt the Same SaaS Integration Layer 6 Times. So I Stopped.

Every new project. Same boilerplate. Different client. Same pain.

After years working as a DevOps engineer — architecting solutions on Azure and AWS, shipping .NET backends, connecting SaaS products to the tools their customers actually use — I noticed a pattern I couldn't shake.

Every project started the same way.

Not with the product. With the plumbing.

Stripe. SendGrid. Twilio. Webhooks. File storage on S3 or Azure Blob. JWT auth. Multi-tenant architecture. Rate limiting. Audit logs.

Six different projects. Six times rebuilding the same foundation. The specifics changed — the stack stayed identical.

So I finally did something about it.

What "the plumbing" actually looks like in production

Let me be specific, because this is where most tutorials stop short.

Webhooks aren't fire-and-forget

Everyone knows how to send a webhook. You POST to a URL. Done.

What most developers underestimate is the retry layer. In production, the receiving end will go down. It will timeout. It will return a 500 at 2am. If you're not handling that, you're losing data.

A production webhook dispatcher needs:

Exponential backoff — not fixed retries. 1min → 2min → 4min → 8min → 16min. Linear retries hammer a struggling server.
Delivery tracking — you need to know which events succeeded, which failed, and which are queued.
Manual retry — operations teams need a button to replay a failed event without re-triggering the source.
Dead letter handling — after N failures, park it somewhere and alert. Don't silently drop it.

I've seen teams burn two weeks building this correctly. Most don't build it correctly at all.

Multi-tenant isn't just a `tenantId` column

Adding a tenantId to your tables is the beginning of multi-tenancy, not the end.

A real multi-tenant architecture means:

Per-tenant database isolation — not just row-level filtering, but the option to physically separate tenant data when compliance requires it
Per-tenant rate limiting — one noisy tenant shouldn't degrade experience for others
Per-tenant audit logs — every action logged, attributable, exportable
Per-tenant API keys — rotation, scoping, revocation, all manageable per customer

This is the stuff that kills SaaS MVPs post-launch when enterprise customers start asking questions.

Data transformation is the unsexy problem nobody talks about

You've connected Shopify to your platform. Now you need to forward that order to your warehouse system — which expects a completely different JSON schema.

You've connected Stripe to your billing layer. Now you need to push that event to your accounting software — which expects yet another format.

This happens constantly in integration work. The standard answer is "write a mapper function." The problem is you end up with dozens of brittle, untestable mapper functions scattered across your codebase.

A better pattern: Liquid templates for JSON-to-JSON transformation. Define the mapping as a template. Test it against sample payloads before deploying. Change the mapping without touching application code.

Shopify order → [Liquid template] → Warehouse API format
Stripe event  → [Liquid template] → Accounting platform format

It sounds simple. It changes how you think about integrations entirely.

The stack that actually covers it

After the sixth rebuild, I documented every decision I'd made — and packaged it into a single .NET 8 platform. Here's what ended up in it:

Payments
Stripe integration, PCI compliant, supporting 7+ payment methods (PayPal, iDEAL, Klarna, Bancontact, Giropay, Sofort). Webhook-driven, not polling.

Webhooks
Full dispatcher with exponential backoff retries, delivery tracking, manual retry, and monitoring.

Email & SMS
SendGrid for transactional email (welcome flows, receipts, alerts). Twilio for SMS (security codes, payment confirmations). Template system with delivery history.

File Storage
AWS S3 and Azure Blob — both, so your cloud strategy doesn't lock you in. Tenant-isolated. Full CRUD.

Data Transformation
Liquid template engine. JSON-to-JSON mapping. Testable before deploy.

Security
JWT with refresh tokens. MFA via TOTP. API key management with rotation. SSO via Google, Azure AD, and Okta. Session management. Rate limiting with configurable quotas per tenant.

Subscriptions
Plan management (Basic/Pro/Enterprise). Lifecycle handling. Cancel and refund flows. Metered billing support.

Observability
Complete audit logging. Health checks (liveness, readiness, detailed). Request/response logging. Performance metrics.

61 endpoints total. Docker-ready. SQLite for local development, SQL Server for production. Swagger/OpenAPI docs included. Deployable to Azure App Service or AWS ECS.

Why build this vs. using Zapier or Make?

Fair question. Here's the honest breakdown:

	This platform	Build yourself	Zapier/Make
Cost	€399 one-time	€30k+ dev time	€500+/month
Time to launch	~10 minutes	3–6 months	~1 day
Full source code	✅	✅	❌
Self-hosted	✅	✅	❌
Webhook retries	✅ built-in	Build yourself	✅
Custom transforms	✅ Liquid templates	Build yourself	Limited
Multi-tenant	✅ built-in	Build yourself	❌
Audit logging	✅ built-in	Build yourself	❌

Zapier is fine for simple automations. It breaks down fast when you need custom transforms, tenant isolation, or anything that touches compliance.

Who this is for

SaaS founders who want to ship product, not infrastructure
Freelancers who deliver .NET backends and are tired of the same setup overhead on every engagement
Dev teams starting greenfield projects who want a production-ready base, not a tutorial skeleton

It is not for you if you enjoy building webhook dispatchers. Some people do. I respect it.

Try it before you buy it

There's a live Test Hub at localhost:5000/testhub after you clone and run docker compose up. Every one of the 61 endpoints is testable before you spend a cent.

If you want to grab it: API Integration & Automation Platform on Gumroad — €399, one-time, full source code, lifetime updates, commercial license. https://youtu.be/3nQfoa8x_kc?si=IGMg41Tt-98q5VOD

30-day money-back guarantee. No questions asked.

Built on .NET 8 · Runs on Azure & AWS · Part of the BuildMintZ platform

What's the integration you've rebuilt the most times? Drop it in the comments — genuinely curious whether webhook retries or multi-tenant auth is the more universal pain point.

Tags: dotnet devops azure aws webdev saas architecture productivity

I was tired of juggling AI APIs… so we built one API for everything

BuildMintZ Media — Tue, 07 Apr 2026 12:37:17 +0000

I got tired of juggling AI APIs… so we built one API for everything

If you’ve worked with AI APIs recently, you probably know the pain:

One API for text
Another for images
Another for speech
Different formats, auth, pricing, limits…
Glue code everywhere

At some point, it stops being “building with AI” and starts being managing APIs.

So we decided to fix that.

What we built

We created a Unified AI Gateway — one API that handles:

Text generation
Image generation
Speech (TTS / STT)
Vision + document analysis
Translation & transcription

All through a single endpoint.

What this actually looks like

Instead of juggling multiple SDKs and APIs, you just send:

POST /api/ai/gateway

With something like:

{
"category": "image",
"input": {
"text": "Futuristic data center"
},
"quality": "flux-pro"
}

Or:

{
"category": "document",
"subType": "invoice",
"input": {
"prompt": "Enterprise invoice for AI consulting"
},
"language": "es"
}

That’s it. Same structure. Same endpoint.

Why we built it this way

Most tools optimize for model access.
We wanted to optimize for developer experience.

So we focused on:

⚡ ~50ms average latency
🧠 Intelligent model routing (you don’t have to pick every time)
🌍 100+ languages
💸 Simple usage-based pricing (1000 free daily neurons)
What surprised us

The biggest win wasn’t performance.

It was how much simpler the codebase became.

Less branching.
Less vendor lock-in.
Less time spent debugging weird API differences.

Try it yourself

If you’re curious, you can explore it here:

Docs → https://docs-api.usefreelanceflow.com/
Swagger (live playground) → https://docs-api.usefreelanceflow.com/swagger
OpenAPI spec → https://docs-api.usefreelanceflow.com/openapi.json
Looking for feedback

This is still early, and we’re actively improving it.

If you’re building anything with AI, I’d genuinely love to know:

What’s annoying you right now?
What APIs are you stitching together?
What would make this actually useful for you?

Tear it apart 👇

We Migrated our AI Agents from Azure to AWS — Here's the Minimal Setup You Actually Need

BuildMintZ Media — Fri, 20 Mar 2026 22:26:41 +0000

After migrating our agent-based document processing system from Azure to AWS, one thing became obvious:

Most cloud setups are wildly over-engineered for development.

You don’t need half the services people default to just to build and test a distributed system.

Here’s the minimal AWS architecture you actually need to develop and run an agent-based pipeline end-to-end — plus what each piece maps to if you’re coming from Azure.

The System

Before we even touch the cloud layer, here’s what’s actually running.

At its core, this is a pipeline of independent Python workers processing documents in stages. Each worker listens to its own queue, does one job well, and hands off to the next stage.

In front of that sits a hybrid FastAPI gateway exposing both REST and GraphQL endpoints, depending on the consumer.

Five containers total:

gateway
ai-core
collector
exporter
redis

[insert architecture diagram here]

Core Services — What You Actually Need

If you're building something similar on AWS, these are the essentials.

RDS (PostgreSQL)

This is your source of truth: datasets, schemas, job states.

You can use SQLite for early local testing — but don’t let that leak into staging. You’ll regret it the moment concurrency shows up.

Raw data in. Clean datasets out. Exports delivered.

It’s cheap, durable, and at any meaningful scale, there’s really no alternative.

This is the backbone of the entire system.

Each worker type gets its own queue:

scraper-jobs
validate-jobs
improve-jobs
refurbish-jobs
export-jobs

This gives you full decoupling:

Workers can scale independently
Crashes are isolated
Deployments don’t ripple across the system

Cognito

Handles authentication for the gateway.

Don’t skip this. Retrofitting auth later is always worse than doing it properly from day one.

Everything runs inside it.

Not optional. No shortcuts here.

What You Can Disable in Dev (and Save Real Money)

While you're still building, you don’t need the full production setup.

Service Why you don’t need it yet Monthly saving
ElastiCache (Redis) Run Redis locally in Docker ~$15
Application Load Balancer Not needed before production traffic ~$18
NAT Gateway Only required for private subnet outbound ~$32

That’s roughly $65/month saved — which adds up fast across a team.

Azure → AWS: The Mapping

[insert comparison table here]

The Key Insight

Cloud providers look very different — but under the hood, they all boil down to the same building blocks:

Identity
Messaging
Storage
Database
Networking

The names change. The SDKs change. The auth models definitely change.

But if your architecture is built around these primitives, switching clouds becomes a configuration problem, not a code problem.

In our case, moving from:

SERVICE_BUS_CONNECTION
AZURE_OPENAI_KEY

to:

IAM roles
Amazon Bedrock

…required zero changes to business logic.

All the seams were already at the infrastructure boundary — exactly where they should be.

Final Thought

If you're building in the cloud right now:

Start minimal — these five services are enough to ship something real
Add complexity only when you have a concrete reason
Optimize cost early — small monthly savings compound quickly

All five containers are now running healthy on AWS.

Curious — are you team AWS or Azure right now?
And has anyone done this migration the other way around?

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

BuildMintZ Media — Sat, 07 Mar 2026 20:58:34 +0000

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

After months of building, I'm excited to share the first product in my ecosystem:

🔷 Azure SaaS Backend Platform

What makes this different?
→ 1 codebase → 4 marketable products
→ 7 microservices (Payments, Auth, Subscriptions, etc.)
→ Multi-tenant architecture out of the box
→ 30+ API endpoints ready to use
→ Deploys to Azure in minutes

👇 Try it LIVE right now (no signup required):
https://saas-backend-40396021-cjezgvgth5csabhf.francecentral-01.azurewebsites.net/testhub

Test every endpoint yourself:
💳 Process a payment
🔐 Create a tenant
📁 Upload a file
📊 Check audit logs

Everything works. No fake demos. No email required.

Note: This is a commercial product, not open source - production-ready code with commercial license and support.

If you're building a SaaS and tired of rewriting auth and billing every time, this is for you.

👉 Get the code (launch special - 60% off):
https://mintzmedia.gumroad.com/l/uwwgvi

What would you build with a production-ready backend?

dotnet #azure #saas #developer #indiehacker #csharp #commercialsoftware

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products! After months of building, I'm excited to share the first product in my ecosystem: 🔷 Azure SaaS Backend Platform

BuildMintZ Media — Sat, 07 Mar 2026 20:55:31 +0000

🚀 Unified SaaS Backend Starter Kit – .NET 8 Production-Ready Boilerplate Launch your SaaS faster with a complete multi-tenant backend built on .NET 8 and real-world production architecture. https://mintzmedia.gumroad.com/l/uwwgvi

BuildMintZ Media — Thu, 05 Mar 2026 01:24:46 +0000

mintzmedia.gumroad.com

DEV Community: BuildMintZ Media

How to Build a Production-Ready SaaS Integration Layer on Azure and AWS (.NET 8)

What "the plumbing" actually looks like in production

Webhooks aren't fire-and-forget

Multi-tenant isn't just a tenantId column

Data transformation is the unsexy problem nobody talks about

The stack that actually covers it

Why build this vs. using Zapier or Make?

Who this is for

Try it before you buy it

I was tired of juggling AI APIs… so we built one API for everything

We Migrated our AI Agents from Azure to AWS — Here's the Minimal Setup You Actually Need

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

dotnet #azure #saas #developer #indiehacker #csharp #commercialsoftware

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products! After months of building, I'm excited to share the first product in my ecosystem: 🔷 Azure SaaS Backend Platform

🚀 Unified SaaS Backend Starter Kit – .NET 8 Production-Ready Boilerplate Launch your SaaS faster with a complete multi-tenant backend built on .NET 8 and real-world production architecture. https://mintzmedia.gumroad.com/l/uwwgvi

Multi-tenant isn't just a `tenantId` column