DEV Community: Carolina

Why I chose Aurora Serverless v2 + App Runner + Vercel for my SaaS stack

Carolina — Fri, 26 Jun 2026 15:38:18 +0000

Every stack decision in a solo-founder SaaS has a cost. Not just money — time, complexity, and cognitive load. When I started building InspectIQ for the H0 Hackathon, I had one rule: every technology choice had to earn its place.

Here's what I chose and why.

Aurora PostgreSQL Serverless v2

The H0 Hackathon required an AWS database. I had three options: Aurora, Aurora DSQL, or DynamoDB.

I chose Aurora PostgreSQL Serverless v2 for one reason that trumped everything else: Row Level Security.

InspectIQ is multi-tenant from day one. Every inspector is a separate tenant with completely isolated data. RLS lets me enforce that isolation at the database layer, not the application layer. One missing WHERE clause in application code can't leak data between tenants when the database itself enforces the policy.

Aurora Serverless v2 also scales to near-zero between requests. For an early-stage SaaS with unpredictable traffic, that matters. I'm not paying for a database that sits idle at 2am.

The cold start is subsecond. I've never noticed it in production.

AWS App Runner

I needed a place to run FastAPI. The options were Lambda, ECS, EC2, or App Runner.

Lambda would have required restructuring the FastAPI app into a Lambda handler.
Doable, but extra work for no gain at this stage.

ECS gives you more control but requires more setup — load balancers, task definitions, service discovery. I didn't need that control yet.

App Runner takes a container image from ECR and runs it. Auto-scaling, health checks, HTTPS, all handled. I push to ECR, App Runner deploys. That's it.

For a solo founder building fast, App Runner is the right call.

Vercel + Next.js 14

The frontend needed to be fast to build and fast to load on mobile. Inspectors use their phones in the field, sometimes with marginal 4G connections.

Next.js App Router gives me Server Components for the initial data fetch (fast, no client-side waterfall) and Client Components for the real-time parts, the findings autosave, the photo upload progress, the observation condition buttons.

The autosave debounces 800ms after the last keystroke. The inspector types a finding, stops typing, and it saves automatically. No save button. No lost data if they close the app.

Vercel deploys on every push to main. Preview deployments for every PR. Zero infrastructure management on the frontend side.

AWS S3 for photos

Home inspectors take a lot of photos. Every defect gets documented. A full inspection might have 20-40 photos.

The naive approach: upload photos to the FastAPI backend, which forwards them to S3. That works, but it doubles the bandwidth and adds latency, the photo travels from the phone to App Runner to S3 instead of phone to S3 directly.

The right approach: presigned PUT URLs. The backend generates a temporary URL that lets the phone upload directly to S3. The file never touches the backend.
The path is:
tenants/{tenant_id}/inspections/{inspection_id}/findings/{finding_id}/{uuid}.jpg

Tenant isolation in the S3 key structure. The backend only stores the key and a presigned GET URL (24h expiry) for serving the photo in the UI and PDF.

WeasyPrint for PDF generation

Generating PDFs is harder than it looks. The options I considered:

Headless Chrome (Puppeteer): Works great, but adds a Chrome binary to the Docker image. That's 300MB+ and a security surface I didn't want.
ReportLab: Python library, but building complex layouts with photos and branding in ReportLab feels like writing assembly code.
WeasyPrint: Renders HTML/CSS to PDF server-side. I write the report as a Jinja2 HTML template, WeasyPrint converts it. The template is readable, maintainable, and easy to update.

WeasyPrint has quirks — it doesn't support flexbox in table cells, and object-fit doesn't work. But once you know the constraints, it's predictable. A 15-section inspection report with photos renders in under 3 seconds.

AWS Cognito

Auth is not where I wanted to spend time. Cognito handles JWT issuance, token refresh, user management, and MFA if I ever need it. I store a custom tenant_id claim in the token so the backend knows which tenant is making the request without a database lookup on every call.

The inspector's inspector_id is resolved on the backend from the JWT sub via a lookup in inspector_profiles. The frontend never sends database IDs — only business data. This was an architecture decision I got right after initially getting it wrong.

Terraform for infrastructure

Everything is in code. The Aurora cluster, App Runner service, S3 bucket, Cognito user pool, ECR repository, security groups, VPC, all Terraform in a separate mcag-h0-infra repo.

When something breaks, I know exactly what's deployed. When I need to
replicate the environment, I run terraform apply.

What I'd change

Honestly, not much at this stage. The stack is boring in the best possible way, proven technologies that do what they say.

The one thing I'd add sooner: CloudFront in front of S3. Right now I'm using presigned GET URLs with 24h expiry for photos in the PDF. That creates a race condition if the PDF is generated close to the URL expiry. CloudFront with Origin Access Control gives permanent URLs that WeasyPrint can always reach.

That's on the roadmap for July.

The live product

InspectIQ is running in production at mcag-h0.vercel.app.
First customer confirmed at $99/month starting July 2026.

The stack made it possible to build a production-grade multi-tenant SaaS in the H0 Hackathon window. Not a demo. A product.

I created this content for the purposes of entering the H0: Hack the Zero Stack Hackathon by AWS and Vercel. #H0Hackathon

From hackathon to real customer: building InspectIQ for Florida home inspectors

Carolina — Fri, 26 Jun 2026 15:27:21 +0000

Most hackathon projects don't have a customer before they're finished.

InspectIQ does.

Before I wrote a single line of code, I had a conversation with REBS Property Specialist LLC — a licensed Florida home inspector with 30 years of experience.
I asked him one question: what's the most painful part of your job that software hasn't fixed?

His answer was immediate: the report.

The problem nobody talks about

Florida has over 8,000 licensed home inspectors. After every inspection, which covers 12 sections, dozens of condition items, and photos of every defect, the inspector has to produce a professional PDF report and deliver it to the client, often within hours.

Most inspectors are still doing this with paper forms, clipboards, and software that was built before smartphones existed. The apps that do exist weren't designed for mobile. They weren't designed for field use. They weren't designed for someone who needs to capture 40 findings, take 20 photos, and generate a branded PDF while standing in someone's attic in July in Florida.

That's the problem InspectIQ solves.

What I built

InspectIQ is a mobile-first SaaS platform that covers the full inspection workflow:

In the field: the inspector opens the app on their phone, selects a section (Roof, Electrical, Plumbing, etc.), and starts documenting. Every finding has a condition rating (GOOD, MARGINAL, DEFECTIVE), free-form observations, and photos that upload directly from the phone to S3 — no waiting for a slow backend upload.
Component observations: beyond free-form findings, each section has structured metadata fields (what material is the roof? what type of electrical panel?) and condition items that map directly to the InterNACHI inspection standard Florida inspectors are trained on.
The report: one click generates a professional PDF with the inspector's branding — their logo, their colors, their license numbers — plus all the findings, conditions, photos, and section disclaimers. WeasyPrint renders it server-side in under 3 seconds.

The distribution insight

Here's what made me confident this could work as a real business:

REBS runs an inspection school. Every year, 30 to 60 new inspectors graduate from his program and enter the Florida market. They need software from day one of their career. If InspectIQ is the tool they learn on, the CAC for those customers is essentially zero, they come through the school channel already trained on the product.

That's not a hackathon pitch. That's a real distribution channel.

Building it during H0

The H0 Hackathon gave me the infrastructure constraint I needed: Aurora PostgreSQL on AWS with a Vercel frontend. That's exactly the stack I wanted for production anyway.

So instead of building a demo, I built the real thing. Multi-tenant database with Row Level Security. White-label branding per inspector. A 5-state inspection lifecycle with write-locks on delivered reports. S3 photo storage with presigned URLs. Thirteen database migrations.

It's not a prototype. It's a product.

Where it stands today

InspectIQ is live at mcag-h0.vercel.app. REBS confirmed at $99/month starting July 2026. His network of 3-5 inspectors are next in the pipeline.

The MRR targets: $500 in month 1, $5,000 by month 6, $30,000 by month 18.

The path to get there runs through every inspector school in Florida.

I created this content for the purposes of entering the H0: Hack the Zero Stack
Hackathon by AWS and Vercel. #H0Hackathon

How I built multi-tenant Row Level Security with Aurora PostgreSQL for a B2B SaaS — H0 Hackathon

Carolina — Fri, 26 Jun 2026 15:21:53 +0000

I'll be honest: I almost did multi-tenancy the wrong way.

When I started building InspectIQ "a SaaS platform for Florida home inspectors" my first instinct was to add a tenant_id column to every table and filter it in the application layer. Every query would have a WHERE tenant_id = :current_tenant clause. Simple, familiar, done.

Then I thought about what happens when you forget one.

One missing WHERE clause. One endpoint that skips the filter. One inspector sees another inspector's client data. In a home inspection business, that's not just a bug — it's a HIPAA-adjacent nightmare and a trust-destroying moment with your first customer.

So I did it properly from day one: Row Level Security at the database layer.

What is Row Level Security?

RLS is a PostgreSQL feature that lets you define policies directly on tables.
When a user queries a table, the policy runs automatically, before your application code even sees the results. You can't forget to apply it. You can't bypass it with a careless JOIN. It's enforced at the lowest possible layer.

For a multi-tenant SaaS, this is exactly what you want.

How I implemented it

Every table in InspectIQ has this pattern:

ALTER TABLE inspections ENABLE ROW LEVEL SECURITY;
ALTER TABLE inspections FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON inspections
  USING (tenant_id = NULLIF(current_setting('app.current_tenant_id',true), '')::uuid);

The FORCE is important — it applies the policy even to the table owner.
No superuser backdoor.

The tenant context comes from the JWT. When an inspector logs in, theirtenant_id is embedded as a custom Cognito claim. The FastAPI middleware extracts it and sets it at the start of every request:

await session.execute(
    text(f"SET LOCAL app.current_tenant_id = '{tenant_id}'")
)

SET LOCAL scopes the setting to the current transaction. When the transaction ends, it's gone. No leakage between requests.

Aurora PostgreSQL Serverless v2

I'm running this on Aurora PostgreSQL Serverless v2 on AWS. For an early-stage SaaS, the economics are compelling: you pay for what you use, it scales to zero between requests, and you get full PostgreSQL compatibility.

The RLS policies work identically on Aurora as they do on vanilla PostgreSQL.
No Aurora-specific gotchas, no driver changes.

One thing I learned the hard way: Aurora with restricted database users (which is the right security posture) means your migration user needs DDL privileges separately from your application user. I run schema migrations via a bastion EC2 through AWS SSM — no SSH, no exposed credentials, no public IP on the database.

The moment it clicked

The first time I tested with two tenants, I logged in as Tenant A and ran a query that should only return Tenant B's data. I got an empty result set.

Not an error. Not "access denied." Just nothing — because from the database's perspective, those rows don't exist for this tenant.

That's the right behavior. That's what you want. And I didn't have to write a single WHERE clause in my application code to get it.

The tradeoff

RLS adds complexity to your migration process and your database user setup.
You need to think carefully about which user runs DDL vs. which user runs application queries. You need to test that your policies actually work, both that they block the right data AND that they return the right data for the correct tenant.

But for a B2B SaaS where tenant isolation is a hard requirement, the tradeoff is worth it. The alternative — application-level filtering — is a security debt that compounds with every new endpoint you add.

What's next

InspectIQ is live at mcag-h0.vercel.app with a confirmed first customer (REBS Property Specialist LLC, a 30-year Florida licensed inspector) starting July 2026.

If you're building multi-tenant SaaS on Aurora PostgreSQL and want to talk architecture, find me here on dev.to.

I created this content for the purposes of entering the H0: Hack the Zero Stack
Hackathon by AWS and Vercel. #H0Hackathon