DEV Community: Somnath Khadanga

What to Audit in a Vibe-Coded MVP Before Real Users See It

Somnath Khadanga — Sat, 09 May 2026 17:14:14 +0000

You built it with Cursor. Or Claude Code. Maybe both. The product works — users can sign up, the core workflow runs, and you've shown it to a dozen people without anything catching fire.

Now you want to share it more widely.

Before you do, run this audit.

This is not a "rewrite everything" post. Most AI-generated code is structurally fine. The problem is almost never the code itself — it's the things the AI didn't know to think about: your deployment environment, your specific threat model, what happens when a real user does something unexpected at 2am.

I've reviewed several AI-assisted codebases in the last few months. The same problems show up in almost all of them. They're not hard to fix. They're just not obvious when you're moving fast.

<p>AI coding tools are genuinely fast. They're not good at knowing what they don't know about your specific production context.</p>



<p>The things that break in production are almost never the core feature. They're the edges around it that nobody vibe-coded.</p>

1. Auth: The Most Common Breaking Point

AI tools write auth that works for the happy path. It's the unhappy paths that cause incidents.

Here's what to check:

Middleware protection is consistent, not selective.

In Next.js, a common pattern is protecting routes via middleware.ts — but then having API routes that don't re-verify the session. If someone bypasses your frontend and hits /api/admin/users directly, does the route independently check auth?

Every API route that touches user data should verify the session or token independently of whatever the middleware does. Middleware is a convenience layer, not a security boundary.

// This pattern from AI tools is not enough
export async function GET(request: NextRequest) {
  // If middleware already checked, is this safe?
  // No — middleware can be bypassed, skipped, or misconfigured
  const users = await db.user.findMany()
  return NextResponse.json(users)
}

// This is what you actually want
export async function GET(request: NextRequest) {
  const session = await getServerSession(authOptions)
  if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  if (session.user.role !== 'admin') return NextResponse.json({ error: 'Forbidden' }, { status: 403 })

  const users = await db.user.findMany()
  return NextResponse.json(users)
}

Role checks happen on the server, not just the client.

If your app shows an admin dashboard only when user.role === 'admin' in a React component, that's UI gating — not access control. The underlying API calls that populate the admin dashboard still need server-side role verification.

Sessions expire and get revoked correctly.

Ask this: if you manually delete a user's session from the database, will they be logged out on their next request? Or will their existing cookie still work? AI-generated session handling often doesn't account for forced logout, user banning, or credential rotation.

Password reset tokens are single-use.

Generate a reset token, use it, and try to use the same link again. It should fail. Many AI-generated flows mark the token as used after the password is changed — but not immediately on click, which opens a small window.

Auth issues in production are not usually dramatic hacks. They're edge cases that a real user stumbles into — like a session that stays alive after account deletion, or an admin endpoint that returns data to any authenticated user regardless of role.

2. API Routes That Think the Frontend Is the Last Line of Defense

Vibe-coded apps often have validation that only lives in the form — in Zod schemas on the client, in form submission handlers, in UI state. The API route trusts that the frontend already checked everything.

It didn't. Or rather, it did — until someone uses curl.

The fix is simple: every API route that accepts user input validates that input server-side, independently.

// Common in AI-generated code — validation only happens in the form component
export async function POST(request: NextRequest) {
  const body = await request.json()
  // body.amount could be negative, null, a string, or 999999999
  await createCharge({ amount: body.amount, userId: body.userId })
}

// What you want
const createChargeSchema = z.object({
  amount: z.number().positive().max(100000),
  userId: z.string().uuid(),
})

export async function POST(request: NextRequest) {
  const session = await getServerSession(authOptions)
  if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })

  const parsed = createChargeSchema.safeParse(await request.json())
  if (!parsed.success) return NextResponse.json({ error: parsed.error }, { status: 400 })

  // Now you can trust the data
  await createCharge({ ...parsed.data })
}

Check for mass assignment too. If you're doing db.user.update({ data: body }), a user could pass { role: 'admin', stripeCustomerId: 'someone_elses_id' } in the request body. Never pass user-controlled data directly to a database update without explicitly picking the fields you allow.

// Dangerous
await db.user.update({ where: { id }, data: body })

// Safe
await db.user.update({
  where: { id },
  data: {
    name: body.name,
    bio: body.bio,
    // role, email, stripeCustomerId — not here
  }
})

3. Error Messages Are Telling People Too Much

In development, you want verbose errors. In production, you do not want stack traces or database errors reaching the browser.

Open your app's network tab and trigger a few errors — a failed form submission, a 404 for a resource that doesn't exist, a request to an endpoint without auth. What does the response body contain?

A typical AI-generated error handler:

} catch (error) {
  return NextResponse.json({ error: error.message }, { status: 500 })
}

error.message in a database error might be:

Invalid `prisma.user.findUnique()` invocation:
column "users"."emailAddress" does not exist

That tells an attacker your ORM, your schema shape, and that you have a column naming inconsistency. None of that should leave the server.

} catch (error) {
  // Log the real error for yourself
  console.error('API error:', error)

  // Return a safe message to the client
  return NextResponse.json(
    { error: 'Something went wrong. Please try again.' },
    { status: 500 }
  )
}

Also check: are you calling JSON.stringify(error) anywhere in response bodies? Error objects serialized to JSON can expose a lot of internal state.

4. Webhook Handlers That Trust Everything

If your app uses Stripe, Clerk, Resend, GitHub, or any other service that sends webhooks, those endpoints need signature verification. Without it, anyone can POST to your webhook URL with fake events.

AI tools often generate the webhook handler but skip the signature check, especially if you're prototyping quickly with Stripe CLI in local dev (which verifies automatically).

// Missing verification — dangerous
export async function POST(request: NextRequest) {
  const event = await request.json()

  if (event.type === 'checkout.session.completed') {
    await activateSubscription(event.data.object.customer)
  }

  return NextResponse.json({ received: true })
}

// With Stripe signature verification
export async function POST(request: NextRequest) {
  const body = await request.text()
  const sig = request.headers.get('stripe-signature')

  let event: Stripe.Event
  try {
    event = stripe.webhooks.constructEvent(body, sig!, process.env.STRIPE_WEBHOOK_SECRET!)
  } catch (err) {
    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 })
  }

  if (event.type === 'checkout.session.completed') {
    await activateSubscription(event.data.object.customer)
  }

  return NextResponse.json({ received: true })
}

Also check: is your payment webhook handler idempotent? Stripe can send the same event more than once. If activateSubscription charges the user again or creates a duplicate record on a second call, that's a real production bug.

Every webhook handler should do two things before touching your database: verify the signature, and check whether you've already processed this event ID. Both are skippable in dev. Neither is optional in production.

5. Secrets That Ended Up in the Wrong Place

Run this command in your project root:

git log --all --full-history -- .env
git log --all --full-history -- .env.local

If .env or .env.local ever got committed — even once, even before you added them to .gitignore — those secrets are in your git history. GitHub has tooling that detects this, but you should also check manually.

Check your .gitignore is actually working:

git status
git ls-files .env*

If any .env files appear in ls-files, they're tracked.

Check for secrets in your frontend bundle. If you accidentally used a server-side API key in a client component — passed it as a prop, included it in a const in a shared file that got bundled — it'll be visible in the browser's JavaScript. Open DevTools, go to Sources, and search for your key name.

In Next.js, any process.env.VARIABLE that doesn't start with NEXT_PUBLIC_ should never appear in client-side code. If it does, something's wrong.

Check for missing environment validation. If your app starts without a required secret, what happens? Ideally it fails loudly at startup. AI-generated apps often let missing env variables surface as confusing errors at runtime — Cannot read properties of undefined six layers deep.

// Add this to your app startup or a lib/env.ts
const requiredVars = [
  'DATABASE_URL',
  'NEXTAUTH_SECRET',
  'STRIPE_SECRET_KEY',
  'STRIPE_WEBHOOK_SECRET',
]

for (const key of requiredVars) {
  if (!process.env[key]) {
    throw new Error(`Missing required environment variable: ${key}`)
  }
}

6. Data Model Decisions That Will Hurt at 1,000 Users

You don't need to optimize for scale before launch. You do need to avoid decisions that are expensive to undo.

Check for missing indexes on columns you filter or join on.

If you're doing db.post.findMany({ where: { userId: session.user.id } }), and userId doesn't have a database index, that query does a full table scan on every page load. Fine at 100 rows. Brutal at 50,000.

For a Prisma schema, add indexes where you filter:

model Post {
  id        String   @id @default(cuid())
  userId    String
  createdAt DateTime @default(now())
  user      User     @relation(fields: [userId], references: [id])

  @@index([userId])           // add this
  @@index([userId, createdAt]) // and this if you sort by date
}

Check cascade behavior on deletes. If you delete a user, what happens to their posts, their payment records, their audit logs? AI-generated schemas often use onDelete: Cascade everywhere because it's the simple answer. Sometimes that's right. Sometimes you want Restrict (block deletion until child records are removed) or SetNull (preserve the records, just remove the user link).

Find every onDelete in your Prisma schema and verify each one matches your actual intent.

Check for missing updatedAt timestamps. You will want to know when records were last modified. Add updatedAt DateTime @updatedAt to every table that isn't append-only. Adding it later requires a migration and a backfill.

Check for soft delete if you need it. If your product involves anything users create and might want back (documents, workspaces, projects), hard deletes are risky. A deletedAt DateTime? column lets you recover from accidental deletions. AI-generated apps almost never include this — they use db.post.delete() everywhere.

Data model mistakes compound. A missing index is a slow query now and a production incident at 10x the users. An accidental hard delete is recoverable until it isn't. Spend 30 minutes reviewing the schema before launch — it's cheaper than a midnight migration.

7. Deployment Assumptions That Break on Vercel or Railway

Vercel and Railway are stateless by default. Your code runs in ephemeral containers that can restart, scale, or be replaced at any time. A lot of vibe-coded apps assume persistent state in ways that fail silently.

Check for local filesystem usage. If you're writing files to disk — temporary files, uploaded images, cached data — those don't survive a container restart on Vercel. Switch to object storage (Cloudflare R2, AWS S3, Vercel Blob) before you launch.

// This breaks on Vercel
import fs from 'fs'
fs.writeFileSync('/tmp/upload.pdf', buffer)

// This survives
import { put } from '@vercel/blob'
const blob = await put('upload.pdf', buffer, { access: 'public' })

Check for in-memory caching. If you're caching data in a Map or a module-level variable, that cache is per-instance and per-restart. On a platform that spins up multiple instances, each instance has its own cache with no shared state. Use Redis (Upstash is the easy path) for anything you need to cache across requests.

Check your database connection handling. Serverless functions open a new connection per invocation. Without connection pooling, you'll hit your database's connection limit fast under load. For Prisma on Vercel, you need either PgBouncer or Prisma Accelerate. For Drizzle, check your connection pool settings.

Check your cold start behavior. First request to a new serverless function instance can be slow — sometimes several seconds. If your auth flow or payment flow hits this, users will see an inexplicable delay on the most important interaction in your product. Test the cold path explicitly.

8. Rate Limiting and Abuse Prevention

Your endpoints have no rate limiting. Every AI-generated app I've reviewed has this gap. It's not dramatic — it just means anyone can hammer your API indefinitely, trigger unlimited password reset emails, or enumerate your users by cycling through email addresses.

The easiest solution in 2026 is Upstash Ratelimit:

import { Ratelimit } from "@upstash/ratelimit"
import { Redis } from "@upstash/redis"

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "10 s"), // 10 requests per 10 seconds
})

export async function POST(request: NextRequest) {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1'
  const { success } = await ratelimit.limit(ip)

  if (!success) {
    return NextResponse.json(
      { error: 'Too many requests' },
      { status: 429 }
    )
  }

  // rest of handler
}

Apply stricter limits to:

Password reset / magic link endpoints (max 3 per hour per email)
Auth endpoints (max 10 per minute per IP)
Any endpoint that sends email or SMS

- Any endpoint that triggers a paid action

9. The Production Basics Nobody Vibe-Coded In

Error tracking. You need to know when things break in production before your users tell you. Sentry has a generous free tier and integrates in 5 minutes with Next.js. Without it, your errors exist as silent database errors, half-completed requests, and confused users who stopped using the product.

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

Health check endpoint. If you're on Railway, Render, or any platform that monitors your app's health, you need a route that returns 200 when the app is healthy. Keep it simple:

// app/api/health/route.ts
export async function GET() {
  return Response.json({ status: 'ok', timestamp: new Date().toISOString() })
}

Logging. console.log in production goes... somewhere. On Vercel, it goes to the function logs. On Railway, it goes to the container logs. Make sure you know where your logs actually are and how to access them when something goes wrong at 2am. For anything beyond simple text, structured logging with something like pino makes filtering and searching significantly easier.

Email deliverability basics. If your app sends email — welcome emails, password resets, notifications — check that your sending domain has SPF, DKIM, and DMARC configured. Without them, your emails go to spam. Resend's dashboard will show you if these are missing. This is a 20-minute fix that most vibe-coded apps skip.

Error tracking and structured logs are the difference between "something is wrong and I don't know what" and "this API route is failing for users who signed up with a Google account." The first one takes days to debug. The second takes 20 minutes.

The 30-Minute Audit Checklist

Work through this before you share the link more widely. Each item is a yes/no — if the answer is no, it goes in the list of things to fix this week.

Auth

[ ] Every API route independently verifies auth (not just middleware)
[ ] Role/permission checks happen server-side, not just in the UI
[ ] Deleting a session in the database actually logs the user out
[ ] Password reset tokens expire and are single-use
[ ] User deletion cleans up sessions properly API and Input
[ ] API routes validate all user input server-side with Zod or equivalent
[ ] Database updates explicitly pick allowed fields (no mass assignment)
[ ] Production error responses don't include stack traces or schema details Webhooks
[ ] All webhook endpoints verify the provider signature
[ ] Payment webhook handlers are idempotent (safe to call twice) Secrets
[ ] .env files have never been committed (check git history)
[ ] No server-side secrets appear in the browser bundle
[ ] App fails with a clear error at startup if required env vars are missing Data Model
[ ] Indexes exist on columns used in where and orderBy clauses
[ ] onDelete behavior is intentional on every relation
[ ] updatedAt timestamps exist on mutable tables
[ ] Soft deletes are considered for user-created content Deployment
[ ] No local filesystem writes (use object storage instead)
[ ] No in-memory caches (use Redis for shared state)
[ ] Database connection pooling is configured for serverless Rate Limiting
[ ] Auth endpoints are rate limited
[ ] Email-sending endpoints are rate limited
[ ] Any endpoint triggering paid actions is rate limited Production Basics
[ ] Error tracking is set up (Sentry or equivalent)
[ ] Health check endpoint exists
[ ] You know where your production logs live

- [ ] Email sending domain has SPF, DKIM, DMARC

What to Fix First

If everything on that list is unchecked, you have a day's work — not a week's. Most of these are 30-minute fixes.

The priority order:

Auth gaps — these have the highest potential for user data exposure
Server-side input validation — stops the most common class of attacks
Webhook signature verification — especially if payments are involved
Secrets audit — check git history, check the browser bundle
Error tracking — you're flying blind without it
Rate limiting — before you do any marketing or sharing
Data model review — before you hit meaningful user numbers
Deployment assumptions — before you scale The good news: most vibe-coded MVPs only have 5–8 actual issues from this list, not all of them. AI tools have gotten genuinely good at the standard patterns. The gaps are almost always in the specific edge cases — what happens when auth is missing, when a secret is wrong, when an input is unexpected.

When to Call In Someone Else

This audit covers the obvious gaps. It doesn't cover:

Complex multi-tenant data isolation (one tenant seeing another's data)
Subtle race conditions in payment and subscription flows
Performance issues that only show up at scale
Security vulnerabilities in your specific business logic If you've worked through this list and something still feels wrong — or if any of the above categories are central to your product — that's the point where a technical review from someone outside the build is worth the time.

If you want a second pair of eyes on a vibe-coded codebase before it goes to more users, see Production Readiness Upgrade. If you want to talk through where the risks actually are first, book a 20-minute call.

Final Thoughts

Vibe-coded MVPs are a real and legitimate way to ship faster in 2026. The AI coding tools are genuinely good. The code they produce is usually fine — clean, readable, structurally sound.

The gaps are almost always in the things that weren't explicitly asked for: what happens on auth failure, what happens to a secret that slipped into client code, what happens when a webhook fires twice.

This audit is not about distrusting AI tools. It's about understanding where the gap between "works in development" and "ready for real users" actually lives — and closing it before someone else finds it for you.

If you found something specific that broke in your vibe-coded build that isn't in this list, the Production Readiness Upgrade is exactly the service for that kind of targeted cleanup.

OpenAI on AWS Bedrock: The AI SaaS Provider Landscape Just Shifted

Somnath Khadanga — Thu, 07 May 2026 16:51:48 +0000

The AI provider landscape changed twice in one week.

On April 28, OpenAI ended its exclusivity arrangement with Microsoft and announced expanded availability on AWS. On May 4, AWS made it concrete: GPT-5.5 and GPT-5.4 are now available through Amazon Bedrock in limited preview, Codex is on Bedrock as a CLI, desktop app, and VS Code extension, and a new Bedrock Managed Agents product wraps OpenAI's frontier models with AWS infrastructure for production agent workflows.

That's the news cycle. Here's the founder version: if you've been building an AI SaaS on the assumption that "OpenAI = Azure" and "Anthropic = AWS" — those defaults no longer hold. Both frontier providers now sit on AWS. Both also sit elsewhere. Your provider decisions just got more interesting and harder.

This post is about how to think through that, not which "winner" to pick.

<p>GPT-5.5 and GPT-5.4 are now on AWS Bedrock alongside Anthropic Claude — meaning AWS hosts both frontier providers in one place for the first time.</p>



<p>Codex on Bedrock means you can use OpenAI's coding agent inside an AWS account using AWS auth and AWS billing — instead of separate OpenAI API keys.</p>



<p>For most existing SaaS apps, this is more about future flexibility than an immediate "switch providers" decision.</p>

What Actually Got Announced

Three things, in plain language:

OpenAI models on Amazon Bedrock (Limited preview). GPT-5.5 and GPT-5.4 — OpenAI's frontier models — are now callable through the Bedrock API with the same patterns you'd use for Anthropic Claude or Meta Llama. Same IAM auth, same VPC endpoints, same CloudWatch metrics, same Bedrock pricing model.
Codex on Amazon Bedrock (Limited preview). OpenAI's coding agent — the same one that ships as codex CLI, a Codex desktop app, and a VS Code extension — can now run against Bedrock-hosted OpenAI models. For teams already inside an AWS environment, this means coding-agent traffic stays inside your AWS account boundary instead of going to a separate OpenAI account.
Amazon Bedrock Managed Agents (Limited preview). A new managed service that wraps OpenAI frontier models in AWS-hosted agent infrastructure. Memory, tool use, retrieval, evaluation — all the agent plumbing — managed by AWS instead of built by you.

All three are limited preview. Most teams won't have access on day one. The mid-term direction is clear: AWS becomes a place where you can use any major frontier model under one billing relationship, one IAM model, and one set of compliance certifications.

Why This Matters for AI SaaS Founders

Until April, the practical picture for founders building AI features looked like this:

OpenAI = direct API or Azure OpenAI Service. Different auth, different SLAs, different regions.
Anthropic = direct API or AWS Bedrock or Google Vertex AI. Easy to use on Bedrock.
Google Gemini = direct API or Vertex AI.
Meta Llama = AWS Bedrock or Vertex AI or self-hosted.

If you wanted to be multi-provider — calling OpenAI for one feature and Claude for another — you were managing at least two billing relationships, two auth flows, and two sets of SDKs. Most founders didn't bother. They picked one provider and stuck with it.

Bedrock now collapses that picture. Both OpenAI and Anthropic models live behind the same API surface. Switching between them — or A/B testing them on a per-feature basis — becomes a config change instead of a rewrite.

That sounds like a clean win, and for new builds it largely is. For existing SaaS apps, the calculation is more nuanced. The cost of changing your stack is real, and the benefit of "now I can switch" is mostly latent until you actually need to switch.

If your SaaS is already running on OpenAI direct API or Anthropic direct API and it's working, the right answer this week is probably: don't move yet. Watch for general availability, watch for pricing parity, then revisit.

If you're picking a stack for a new product right now, that's where this changes things.

The Provider Landscape in May 2026

Here's how I'd map it out today:

Provider	Direct API	AWS Bedrock	Azure	Google Vertex	Self-host
OpenAI (GPT-5.x, Codex)	✅	🟡 limited preview	✅ Azure OpenAI	—	—
Anthropic (Claude)	✅	✅	—	✅	—
Google Gemini	✅	—	—	✅	—
Meta Llama	—	✅	✅	✅	✅
Mistral / Cohere / others	✅ each	✅ Bedrock	varies	varies	varies

The headline: AWS Bedrock is now the only managed surface that hosts both OpenAI and Anthropic frontier models. Direct API from each provider is still the cheapest and lowest-latency path, but Bedrock is the only "neutral ground" for multi-provider architectures.

Anthropic's relationship with AWS is also worth flagging. In April, Amazon committed to investing up to $25B more in Anthropic, and Anthropic pledged $100B in cloud spending to AWS over time. That alignment isn't going away. Bedrock's bias toward Anthropic models — better region coverage, deeper integrations, longer-running availability — is structural.

OpenAI on Bedrock is real but newer and smaller. Treat that as the asymmetry it is.

For most SaaS founders, the practical takeaway from this map isn't "go multi-provider." It's "the cost of going multi-provider later is now lower than it used to be." That's a different kind of optionality.

Five Real Decisions This Forces You to Think About

If you're building or scaling an AI SaaS product, here are the actual questions worth a meeting:

1. Direct API or Bedrock?

Direct API wins on: lowest latency, lowest per-token cost, fastest access to new models (Bedrock typically lags by weeks to months on new model releases), simpler SDKs.

Bedrock wins on: unified billing under your AWS account, IAM-based auth (no API keys to manage), VPC isolation, CloudWatch monitoring out of the box, easier procurement for enterprise customers (your buyer doesn't have to onboard OpenAI as a separate vendor), shared infrastructure with the rest of your AWS workload.

For a solo founder or small team building a B2C product, direct API is almost always the right starting answer. For a B2B SaaS selling to enterprise — especially anyone in regulated industries — Bedrock removes a real procurement headache.

2. Are you ever going to actually be multi-provider?

A lot of teams say "we want optionality" without ever exercising it. Multi-provider architectures cost something — abstraction layers, extra testing, prompt drift between models, more runtime configuration.

Honest test: if your current provider had a 4-hour outage tomorrow, would you actually fail over to a different model, or would you just wait? If the answer is "wait" then you're not really multi-provider — you're paying the abstraction cost without getting the benefit.

If the answer is "fail over" then you should have built that path already, in which case Bedrock's unified API is genuinely useful.

3. Where do your customer's tokens live?

For B2B AI SaaS, your customer is increasingly going to ask: "where does my data go when I use your AI features, and who has it?"

Direct OpenAI API answer: "It goes to OpenAI servers. They have a data processing agreement we signed."

Bedrock answer: "It goes through your AWS account, which is already covered under your AWS BAA / DPA / [whichever framework]. AWS doesn't train on it. Neither does OpenAI through this surface."

Some enterprise customers care a lot about which answer they hear. Some don't care at all. Know which kind of customer you're selling to.

4. What's your latency budget?

Bedrock adds a hop. Calls go through AWS's regional Bedrock endpoint, which routes to the model provider's infrastructure. In practice this typically adds 50–200ms compared to direct API, depending on region.

For most SaaS workloads — chat features, summarization, search — that's invisible. For latency-critical features (real-time autocomplete, voice, agent loops with tight cycle times), it matters. If your AI feature lives in the user's hot path and the perceived speed is already a complaint, this is a real concern. If it's covered by a loading spinner anyway, it isn't.

This connects to the broader "your Next.js app feels slow after launch" pattern — the kind of work covered in Next.js Performance Optimization. AI latency is now part of total user-perceived latency, and it's easy to underestimate.

5. Are you using an AI Gateway?

The third option that doesn't show up in most "Bedrock vs direct API" debates: AI gateways — Vercel AI Gateway, OpenRouter, Portkey, Helicone. These sit between your app and any frontier provider, giving you observability, rate limiting, automatic provider failover, and a unified API across providers.

For solo founders and small teams, an AI gateway is often the better answer than either direct or Bedrock. You get most of the operational benefits of Bedrock without the AWS lock-in, and you get easy provider switching without writing your own abstraction layer.

If you're already on Vercel, the AI Gateway is the lowest-friction path. If you're already deep into AWS, Bedrock makes more sense.

The "right" answer is rarely "use the most powerful platform." It's "use the platform whose lock-in you're least worried about, given the way your product will actually evolve over the next 12 months."

What I Wouldn't Do Yet

A few things the news cycle is pushing that I'd push back on:

Don't migrate a working stack just because Bedrock has OpenAI now. If your SaaS already runs on OpenAI direct API and your billing, latency, and customer compliance are all fine, the cost of moving to Bedrock is real and the benefit is largely "future optionality." Migrate when you have a concrete reason to.

Don't bet on Codex on Bedrock for production yet. Codex CLI is a developer-experience tool, not a customer-facing API. The Bedrock version is limited preview. Use it for your own engineering workflow if you want, but don't build customer features that depend on it being generally available on a particular timeline.

Don't go multi-provider before you have one provider working well. Multi-provider abstractions are expensive to maintain and easy to over-engineer. Ship the single-provider version first. Add the abstraction the first time you have a real reason to switch — and not before.

Don't trust pricing comparisons that don't include egress and gateway costs. Bedrock's per-token pricing isn't the full picture. Your AWS networking costs, log storage costs, and Bedrock-specific markups all factor in. The honest comparison is your monthly AWS bill before vs after, not the rate card.

The Bigger Picture

Two patterns are clear from this week's announcements:

The frontier-model business is consolidating around three hyperscalers — AWS, Azure, GCP — even while staying nominally multi-provider. The economic gravity is pulling everything toward managed surfaces. If you've been holding off on cloud commitments to "stay neutral," that's getting harder.
Cloud-provider lock-in for AI SaaS is becoming structural. Once your AI traffic, your auth, your monitoring, and your customer's data residency commitments all live inside one AWS account, switching is no longer a code change. It's a compliance change.

This isn't necessarily bad. Concentration trades away some flexibility for a lot of operational simplicity, and for B2B SaaS especially, that's often the right trade. But it's worth making the trade consciously, not by default.

If you're picking a stack for a new AI SaaS right now, the questions worth answering first aren't "GPT-5.5 or Claude?" — they're:

Where is your customer's data going to live?
What does your auth and billing look like in 12 months when you have 10 features instead of 1?
Is multi-provider real for your product, or aspirational?

Those questions matter more than the model picker. They're also exactly the kinds of decisions covered by SaaS MVP Development when the AI feature is the product, and AI SaaS Development when AI is one feature inside a broader product.

The teams I see make the best AI provider decisions are the ones that decide what they're optimizing for first — latency, cost, compliance, optionality — and then pick the stack that fits. The teams that make the worst decisions pick the stack first and figure out the tradeoffs later.

Frequently Asked Questions

Is OpenAI available on AWS Bedrock?

Yes, as of May 2026 — GPT-5.5 and GPT-5.4 are available through Amazon Bedrock in limited preview. Codex is also on Bedrock as a CLI, desktop app, and VS Code extension. General availability hasn't been confirmed yet, so production builds should plan for a waiting period.

Is AWS Bedrock cheaper than using the OpenAI API directly?

Not necessarily. Bedrock adds its own markup on top of the provider's base rate, plus you pay for AWS networking, CloudWatch logging, and Bedrock-specific costs. Direct API is usually cheaper for pure token cost. Bedrock's value is in the operational layer — unified billing, IAM auth, VPC isolation, compliance — not in per-token savings.

Can I use both OpenAI and Anthropic Claude on the same Bedrock account?

Yes. That's the main structural change from this announcement. Before May 2026, Bedrock hosted Anthropic, Meta, Mistral, and others — but not OpenAI. Now both major frontier providers (OpenAI and Anthropic) are callable through the same Bedrock API surface, with the same auth and billing.

Does AWS Bedrock support GPT-4?

Not currently. The models announced are GPT-5.5 and GPT-5.4, which are OpenAI's frontier-tier models as of 2026. Older GPT-4 variants aren't listed in the Bedrock catalog. For GPT-4-class workloads, the direct OpenAI API or Azure OpenAI Service remain the current paths.

How does OpenAI on Bedrock compare to Azure OpenAI Service?

Azure OpenAI has been available since 2023 and has broader model coverage and more enterprise deployment options. Bedrock's OpenAI offering is newer and in limited preview. If you're already on Azure or have an existing Azure OpenAI deployment, there's no reason to move. If you're already AWS-native, Bedrock is now a viable alternative to keep your AI traffic inside the same cloud account.

Final Thoughts

OpenAI on Bedrock is a real shift. It changes what's possible, especially for B2B SaaS selling into enterprise. It doesn't change what's necessary for most existing AI SaaS apps that are already shipping.

The right move this week is mostly "watch and read." The right move in three months — when limited preview turns into general availability, when pricing settles, when the integrations mature — will be more concrete.

If you're earlier in the journey and you haven't picked your provider yet, this is the moment to think harder about it than usual. The default of "use OpenAI direct" or "use Anthropic direct" is still defensible. But the calculus around Bedrock and AI gateways is shifting fast enough that the answer that was right last quarter may not be right next quarter.

Posts like Which AI Features Are Actually Worth Building in a SaaS Product Right Now cover the feature side of this question — what to build. This post covers the infrastructure side — where to build it. They go together.

If you'd rather have a single call to figure out what your specific SaaS actually needs first — direct API, Bedrock, or AI gateway — that's exactly what AI SaaS Development covers, and a 20-minute strategy call is usually enough to sort the first few decisions.

What the Vercel Security Incident Should Teach SaaS Teams About Production Readiness

Somnath Khadanga — Sat, 25 Apr 2026 07:44:24 +0000

A lot of teams think production readiness is mostly about uptime, performance, deployment speed, and bug rates.

That is incomplete.

As of Vercel's April 21, 2026 security bulletin update, the company says attackers gained unauthorized access to certain internal systems, impacted a limited subset of customers, and traced the incident to a compromise of Context.ai, a third-party AI tool used by a Vercel employee. Vercel says the attack path involved the employee's Google Workspace account and exposure of environment variables that were not marked as sensitive.

That is why this is not just a "Vercel got breached" story.

It is a reminder that production readiness also includes workflow security: how your team connects third-party tools, how OAuth access is handled, how credentials are stored, and how much internal access can be exposed when one trusted integration goes wrong.

<p>Production readiness includes workflow security, not just release reliability.</p>



<p>OAuth access and secret hygiene can become incident paths if they are not reviewed aggressively.</p>



<p>A compromise in one trusted tool can expand into a larger operational blast radius very quickly.</p>



<p>Mature teams need incident playbooks for vendor and integration failures, not just app bugs.</p>

In this post, I will focus on the real lesson for SaaS teams: production readiness is not only about the code you ship. It is also about the workflows around the code.

What Happened

On April 19, 2026, Vercel disclosed that attackers had gained unauthorized access to certain internal systems and that the incident affected a limited subset of customers.

By April 21, Vercel had added more detail to its bulletin:

The incident originated from a compromise of Context.ai, a third-party AI tool
The attack path involved a Vercel employee's Google Workspace account
Some environment variables that were not marked as sensitive should be treated as potentially exposed
Customers were advised to review activity logs, inspect recent deployments, rotate exposed secrets, and enable stronger account protections

Independent reporting from TechCrunch and The Verge filled in some of the surrounding context, but the key operational lesson was already visible in Vercel's own bulletin: a trusted workflow connection became a path into more sensitive internal systems.

That is the part SaaS teams should pay attention to.

Why This Matters Beyond Vercel

This is not only a platform story. It is a modern engineering workflow story.

Most SaaS teams now run through a web of connected systems:

Cloud platforms
CI/CD tools
Collaboration suites
AI tools
OAuth-based integrations
Environment variables
Internal dashboards
Admin and support workflows

When those systems are tightly connected, a compromise in one trusted workflow can become a path into something much more important.

That is why Vercel's warning about a broader compromise of the Google Workspace OAuth app matters even if you are not a Vercel customer. The pattern is bigger than the vendor.

If your team uses third-party AI tools, Google Workspace integrations, deployment platforms, or shared operational credentials, the same category of weakness can exist in your stack too.

The Real Lesson: Production Readiness Includes Workflow Security

Many teams still treat workflow security as an internal IT concern instead of a product concern.

I think that is a mistake.

If your product depends on:

Deploy pipelines
Hosted infrastructure
Admin dashboards
OAuth-connected tools
Environment variables
Support workflows
Build and release systems

Then workflow security directly affects:

Release confidence
Operational reliability
Incident response speed
Customer trust
Engineering velocity after an incident

That is why I would treat this as a production-readiness issue, not just a one-off security headline.

This is also the same reason I map this kind of work more naturally to Production Readiness Upgrade than to a generic "security news" take. If the operating workflow around a live product is weak, the product is not actually production-ready.

What SaaS Teams Should Review Immediately

1. Third-Party OAuth Access

If a third-party app connected through Google Workspace or another identity provider can become a path into internal systems, that access needs a much higher bar than "it helps productivity."

I would review:

Which third-party apps have OAuth access to corporate accounts
Which employees approved them
What scopes they received
Whether those tools are still actively needed
Whether access review is periodic or effectively forgotten

This is the most direct lesson from the Vercel incident, because the company's own April 21 bulletin tied the origin to a compromised Google Workspace OAuth app from a third-party AI tool.

2. Internal Access Blast Radius

A compromise is bad. A compromise with broad internal reach is worse.

Teams should ask:

If one employee account is taken over, what internal systems become reachable?
What secrets, dashboards, or workflows are exposed from there?
Are there internal systems that should be segmented more tightly?
Does one identity unlock too much?

This is where product engineering, identity management, and operations stop being separate conversations.

3. Secret and Environment Variable Hygiene

Vercel explicitly advised customers to review and rotate environment variables that were not marked as sensitive. That is a strong reminder that secrets hygiene is not boilerplate policy. It is a real incident-response step.

For a SaaS team, I would review:

Where secrets are stored
Who can view them
How often they are rotated
Which ones are over-privileged
Whether urgent rotation has an actual documented playbook

Vercel also shipped product changes after the incident, including making environment variable creation default to sensitive. That is a good example of a company tightening the product after learning where customers are vulnerable.

4. Audit Visibility and Ownership

An activity log only helps if someone actually knows when and how to use it.

Vercel told customers to review activity logs and inspect recent deployments. For most SaaS teams, the question is not just "Do we have logs?" It is "Who owns checking them when something unusual happens?"

I would want clear answers to:

Which logs matter first during a security event
Who is responsible for triage
How suspicious deployments are reviewed
How quickly a team can decide whether to rotate secrets or disable access

An alerting system with no owner is not a security process.

5. Vendor Dependence and Response Discipline

This incident is also a reminder that a hosted platform can be excellent and still become part of your risk surface.

That does not mean "do not use platforms."

It means:

Understand what access flows exist
Understand what secrets live there
Understand what you would rotate first if something upstream went wrong
Understand how your own incident process depends on vendor communications

To Vercel's credit, the company published a customer bulletin, indicators of compromise, mitigation guidance, and product hardening updates quickly. That is what a mature vendor should do.

But your team still needs its own response discipline on top of vendor response.

The Founder Angle

This kind of risk is easy for founders to underestimate because it does not show up in a demo.

Users do not see:

OAuth app sprawl
Weak secret rotation practices
Broad internal-access paths
Poor third-party review habits
Unclear incident ownership

But those things still shape how resilient the business really is.

When a security incident hits, the damage is not only technical. It affects:

Delivery confidence
Support load
Customer communication
Team focus
Roadmap disruption

That is why production readiness is not only about whether the app deploys cleanly. It is also about whether the team behind the app operates securely enough to absorb risk without chaos.

What I Would Fix This Week

If I were advising a SaaS team right now, I would start with:

Audit all Google Workspace and identity-provider OAuth apps
Remove unused or weakly justified third-party access
Review which internal systems are reachable from compromised employee accounts
Rotate high-blast-radius environment variables and tokens
Define who owns logs, alerts, and emergency credential rotation
Document a short incident checklist for third-party platform compromises

These are not theoretical improvements. They are practical workflow-hardening steps that reduce the damage a compromised integration or employee account can cause.

If you are also tightening package publishing and dependency workflow risk, Recent npm Security Changes: What SaaS Teams Should Fix Right Now covers the package-side version of the same maturity problem.

Final Thought

The Vercel incident is not just a story about one platform having a bad week.

It is a reminder that in 2026, production readiness includes more than code quality and deployment speed.

It includes:

Third-party access review
OAuth hygiene
Secret management
Internal access boundaries
Clear operational ownership when something trusted stops being trustworthy

That is the maturity bar SaaS teams need as their products grow.

If your product is live and the workflow behind it needs cleanup, this is exactly the kind of work covered in Production Readiness Upgrade.

Sources

Next.js 16 App Router Caching Changed — Here's What to Update in Your SaaS

Somnath Khadanga — Wed, 22 Apr 2026 10:46:21 +0000

If your SaaS product is on Next.js 16 or you're planning the upgrade, the biggest practical change is not a new feature — it's caching.

The App Router's caching model has shifted from "cache by default, opt out when you need fresh data" to "fetch fresh by default, opt in to caching when you want it." For a lot of SaaS teams, that flipped assumption is the difference between a smooth upgrade and a week of weird bugs.

This post is the shortest useful version of what changed, why it matters for SaaS apps specifically, and what I'd actually update in a live product.

<p>The default caching behavior in Next.js 16 is more predictable, but it shifts the burden of caching decisions to you.</p>



<p>Many SaaS apps upgrading from 14 or 15 will see more database and API calls after upgrading unless they opt in to caching explicitly.</p>

The Short Version

Before Next.js 16, a lot of things were cached implicitly:

fetch() calls were cached unless you passed cache: 'no-store'
Route segments were statically rendered by default
GET route handlers were cached
The full route cache was aggressive about reusing previous renders

In Next.js 16, the model is inverted:

Data fetches are fresh by default
Caching is something you ask for, usually with 'use cache'
Route segments are dynamic unless you explicitly mark them cacheable
Revalidation is clearer and more explicit

The point is not that one model is better than the other in the abstract. The point is that your app was built around specific assumptions, and most of those assumptions just changed.

Why This Matters for SaaS Apps Specifically

Marketing sites mostly did not notice this change. SaaS apps did.

Here is why:

SaaS apps have dashboards that mix fresh data (live metrics) with stable data (user profiles, settings)
SaaS apps often had fetch() calls to internal APIs that were being cached without anyone realizing
SaaS apps use role-based views where the same route renders different content per user, which interacts with caching in non-obvious ways
SaaS apps have admin panels where stale data is actively harmful

If your dashboard suddenly feels slower after upgrading to 16, you probably lost some implicit caching you did not know you had. If your dashboard suddenly shows correct-but-old data, you almost certainly did.

What Actually Changed, With Examples

1. `fetch()` Is No Longer Cached by Default

Before, this was cached indefinitely unless you told it otherwise:

const data = await fetch('https://api.example.com/products')

In Next.js 16, the same call hits the network every request. If you want it cached, you now opt in explicitly:

const data = await fetch('https://api.example.com/products', {
  cache: 'force-cache',
  next: { revalidate: 3600 }
})

What to update: audit every fetch() call in your app/ directory. Ones that pull stable data (catalogs, configurations, public content) should get explicit caching. Ones that pull per-user data should stay fresh.

2. `'use cache'` Is the New Primary Caching Primitive

Instead of caching decisions being scattered across fetch options, unstable_cache, and route config, Next.js 16 leans on a single directive:

'use cache'

export async function getFeaturedProducts() {
  const data = await db.query('SELECT * FROM products WHERE featured = true')
  return data
}

You can put 'use cache' at the top of a file, a function, or a component. It tells the framework "everything this function returns is cacheable." Combined with cacheLife and cacheTag, you get explicit control over what's cached, how long, and how to invalidate it.

What to update: anywhere you were using unstable_cache, migrate to 'use cache'. The API is cleaner and it's no longer unstable.

3. Route Segments Default to Dynamic

Previously, a page was static unless something in it forced dynamic rendering. Now, the default is dynamic unless you mark the segment cacheable.

For most SaaS dashboards, this matches your intent — you wanted fresh per-request data anyway. But marketing pages, docs, and public pages under app/ may need explicit caching to perform well.

What to update: for each top-level route under app/, decide: is this page the same for everyone, or is it per-user? If it's the same for everyone, add 'use cache' or set the appropriate segment config.

4. `GET` Route Handlers Are No Longer Cached

This is the one that surprised the most teams.

Before, a GET handler in app/api/something/route.ts was cached by default if it didn't use dynamic features. Now it isn't.

If you had public API endpoints that were "basically free" because Next.js was caching them at the edge without you asking — those are now hitting your database on every request.

What to update: for public, read-heavy API routes, explicitly cache them. For authenticated SaaS routes, this was probably what you wanted anyway, but check the ones you assumed were always fresh.

The most common Next.js 16 upgrade bug I see in SaaS apps is a silent increase in database load. Your code did not change, but the caching that used to hide N+1 queries went away.

The Upgrade Audit I'd Actually Run

If I were upgrading a real SaaS product to Next.js 16, here's the order I'd do things in.

Step 1: Measure Before You Upgrade

Record the basics before touching anything:

Average dashboard load time (p50 and p95)
Database queries per minute at steady state
API route response times
Any external API calls you make per request

This gives you a baseline. Without it, "it feels slower" is just a feeling.

Step 2: Upgrade on a Branch, Don't Change Caching Yet

Do the Next.js 16 upgrade with no caching changes. Run your app. What you see is the "nothing opted in" baseline — this is what your code behaves like now that the defaults flipped.

Expect: more DB calls, slower dashboards, and possibly some pages that suddenly show correct data they weren't showing before.

Step 3: Categorize Every Data Access Point

Go through every fetch, await db.query, and external API call in your app/ directory. For each one, decide:

Stable and public: catalogs, marketing copy, public product data. Add explicit caching with a long TTL.
Stable and private: user settings, org configurations. Cache per-user with a short to medium TTL.
Fresh and private: live dashboard metrics, notifications, inbox. Do not cache.
Fresh and public: live leaderboards, pricing. Cache with a short TTL (seconds).

This is more work than it sounds, but it is one-time work. Once you've done it, your caching is explicit and debuggable forever after.

Step 4: Use `cacheTag` for Invalidation

Instead of timed revalidation only, tag your cached data:

'use cache'
import { cacheTag } from 'next/cache'

export async function getOrgProjects(orgId: string) {
  cacheTag(`org-${orgId}-projects`)
  return db.projects.findMany({ where: { orgId } })
}

Then invalidate explicitly when something changes:

import { revalidateTag } from 'next/cache'

export async function createProject(orgId: string, data: ProjectInput) {
  const project = await db.projects.create({ data: { ...data, orgId } })
  revalidateTag(`org-${orgId}-projects`)
  return project
}

For SaaS apps with real mutations, this is far more useful than TTL-based revalidation. You get cached reads without stale data.

Step 5: Re-Measure

Run the same metrics from Step 1. You should see:

Dashboard load times back to or better than baseline
Database queries per minute lower than baseline (because your caching is now explicit and probably covers cases the old implicit cache missed)
No stale data bugs

If you don't, you missed something. The most common miss is a marketing or docs page under app/ that is now being rendered per-request for thousands of visitors.

Explicit caching is more work upfront and much less work later. Implicit caching is the opposite — cheap to start with, expensive when something goes wrong and nobody can figure out why a value is stale.

Three Specific Bugs I've Seen Post-Upgrade

Bug 1: "The Dashboard Got Slower"

Usually this is a widget that was being served from the cached fetch response and is now hitting the API on every page load. The fix is almost always: identify the three or four widgets that don't need to be live, and cache them.

Bug 2: "Some Users See Other Users' Data" (Rare but Serious)

This is almost always a caching directive that was copied from a tutorial and applied to a user-scoped data function without cacheTag including the user or org ID. Every cached function that returns per-user data must include the user or org in its cache key, full stop.

Bug 3: "Revalidation Just Stopped Working"

Usually someone kept their old revalidate segment config around and added 'use cache' on top. The two don't compose the way you'd expect. Pick one strategy per route and stick with it.

When to Not Upgrade Yet

Reasons to delay the Next.js 16 upgrade:

You're mid-launch and any instability is expensive
You have complex custom caching logic that will need to be rewritten
Your team is small and nobody has time to do the caching audit properly

"We'll upgrade and fix caching later" is a trap. Upgrade when you can do the caching audit as part of the same work.

The Bigger Picture

The shift from implicit to explicit caching is part of a broader pattern in the App Router: fewer decisions are being made for you, and the ones that are get more visible.

This is good for serious SaaS products. Caching is one of those areas where "it just works" is usually "it just works until it doesn't, and then nobody can figure out why." Explicit caching is slightly more verbose and dramatically more debuggable.

It does mean the upgrade is not a drop-in replacement for most SaaS apps. Budget real time — not for the upgrade itself, which is fast, but for the caching audit that should go with it.

If your SaaS product feels slower or heavier after the Next.js 16 upgrade, the fix is almost never in the framework. It is in the assumptions your code was making about caching that no longer hold.

FAQ

Does Next.js 16 break my existing app?

Not directly. Your code still runs. What changes is behavior — specifically, data that used to be cached implicitly is now fetched fresh every request. The app works, but your database and API calls go up. Plan the upgrade alongside a caching audit, not as a standalone version bump.

Do I need to rewrite every `fetch()` call in Next.js 16?

Only the ones you actually want cached. In 16, fetch() is fresh by default. If you had public, stable data (product catalogs, marketing content, public config) that was implicitly cached before, you'll need to add cache: 'force-cache' and a revalidate window to restore that behavior. Per-user and per-request data can stay as-is.

What replaces `unstable_cache` in Next.js 16?

'use cache' plus the cacheLife and cacheTag APIs. unstable_cache still works for now but the ergonomics are worse and it's deprecated in the docs. If you're already in a Next.js 16 codebase doing caching work, migrate to 'use cache' in the same PR — it's a cleaner API and removes a deprecation you'd otherwise revisit in 17.

Is `'use cache'` stable in production?

Yes, as of Next.js 16. It's no longer behind an experimental flag and it's the primary caching primitive going forward. The thing to be careful about is cache keys — any function with 'use cache' that returns per-user data must include the user or org ID via cacheTag, or you'll cross-contaminate users.

Final Thoughts

Next.js 16's caching changes are an example of a framework asking you to be explicit about something that used to be implicit. For SaaS apps specifically, that's net positive — but only if you treat the upgrade as an opportunity to audit caching, not just bump a version number.

If you're also dealing with broader performance issues that the caching changes surfaced — slow dashboards, heavy re-renders, or fragile data flows — Why Your Next.js App Feels Slow After Launch covers the full picture, and React Compiler in Production is worth reading alongside this one.

If your product is on Next.js and performance is actively hurting user experience, see Next.js Performance Optimization.

If you want someone to review your upgrade plan before you ship it, book a 20-minute strategy call.

How much should an MVP actually cost?

Somnath Khadanga — Thu, 09 Apr 2026 16:47:11 +0000

If you are planning a SaaS product, one of the first questions you will ask is simple:

How much should an MVP actually cost?

The honest answer is that there is no single fixed price. The cost of a SaaS MVP depends much more on scope, product complexity, and launch quality than on the label "MVP" itself.

A lot of founders make the mistake of thinking MVP means "cheap version."

It usually should mean:

The smallest version of the product that solves a real problem and is credible enough to launch.

That is very different from a throwaway demo.

In this guide, I’ll break down what really affects SaaS MVP cost in 2026, where founders overspend, where they cut the wrong corners, and how to think about budget in a practical way.

The Short Answer

A SaaS MVP can cost very little if it is extremely narrow, but it can become expensive quickly when you add custom dashboards, billing, admin tools, advanced user roles, integrations, AI features, or production-quality requirements.

So instead of asking:

"What is the average SaaS MVP cost?"

A better question is:

"What is the smallest version of this product that is still useful, trustworthy, and launchable?"

That is the question that usually leads to a smarter budget.

What Actually Drives SaaS MVP Cost

1. Scope Is the Biggest Cost Factor

Most MVP budgets do not break because of technology. They break because the scope is too loose.

If your MVP includes only:

User signup and login
One core workflow
One user dashboard
Basic admin management
Clean launch-ready UI

That is a very different project from an MVP that includes:

Multiple user roles
Subscriptions and billing
AI workflows
Document uploads
Internal admin tools
Notifications
Analytics
Third-party integrations

The biggest pricing jump usually comes from trying to include version-two ideas inside version one.

A founder often says they want an MVP, but the actual feature list looks closer to an early full product.

2. Product Complexity Matters More Than Page Count

Many founders try to estimate cost based on how many screens the app has.

That is usually the wrong way to think about it.

A "simple" SaaS product with 8 screens can still be expensive if it has:

Complex business logic
Role-based access
Multi-step workflows
Dynamic dashboards
Custom API integrations
AI processing
Billing rules

Meanwhile, a product with more screens can still be manageable if the workflows are straightforward.

The important thing is not how many pages exist. It is how much logic, state, data flow, and backend behavior each page requires.

3. Design Quality Changes the Budget

Some founders want:

Basic, clean, usable UI

Others want:

Polished visual identity
Custom UX details
Motion
Premium interactions
Conversion-focused flows
Responsive behavior tuned carefully across devices

Both are valid.

But they are not the same budget.

If the goal is to validate quickly, a clean and credible UI is often enough. If the goal is also to impress early customers, investors, or partners, design quality becomes a bigger part of the MVP cost.

4. Auth, Roles, and Permissions Add More Work Than People Expect

A lot of SaaS founders underestimate how much complexity comes from user management.

The moment your product needs things like:

Admin vs user roles
Workspace or team structure
Invitations
Permissions
Approval flows
Session handling
Access control by feature

The MVP becomes more complex.

This is one of the most common areas where "simple SaaS app" estimates stop being simple.

5. Payments and Billing Can Expand the Scope Fast

If your MVP includes:

Subscriptions
Plan limits
Trial logic
Invoices
Taxes
Failed payment handling
Coupon flows
Team billing

Then the product is no longer just about your core feature. It also becomes a billing product.

Payments are worth adding early if they are part of the business model, but they should be planned carefully because they add both engineering and product complexity.

6. AI Features Change Both Cost and Risk

In 2026, many founders want AI inside the MVP from day one.

Sometimes that makes sense. Sometimes it is a distraction.

AI can increase MVP development cost through:

Prompt and workflow design
Chat or copilot UX
Retrieval and search systems
Document processing
Quality and fallback logic
API usage costs
Latency and reliability concerns

The most important question is not:

"Can we add AI?"

It is:

"Does AI make the first version meaningfully more useful?"

If the answer is yes, it may belong in the MVP. If not, it may be smarter as a post-launch improvement.

If AI is central to the first release, AI SaaS Development becomes part of the MVP scope, not just a future experiment.

7. Launch Quality Changes the Budget More Than Founders Think

Two products can have the same features but very different cost depending on how seriously you take launch quality.

For example:

Lower-Quality Launch

Rushed structure
Minimal testing
Weak performance
Weak error handling
Messy deployment
Fragile code decisions

Stronger Launch

Cleaner architecture
Better performance
More reliable user flows
Safer auth handling
Stronger deployment setup
More maintainable codebase

The second one costs more initially.

But it often costs less overall because you avoid expensive cleanup later.

This is why I usually recommend building an MVP that is small in scope, not careless in quality.

If the launch foundation already feels shaky, Production Readiness Upgrade is the kind of follow-up work that prevents an early MVP from turning into a cleanup project.

Where Founders Usually Overspend

Overspending Pattern 1: Trying to Impress Everyone in Version One

Many MVPs become bloated because the founder wants:

Investor-ready polish
Customer-ready features
Admin-ready controls
Marketing-ready analytics
Enterprise-ready permissions

All at once.

That turns an MVP into a much bigger product before market validation.

Overspending Pattern 2: Unclear Priorities

If every feature feels important, the budget rises fast.

A better approach is to split features into:

Must-have for first launch
Useful soon after launch
Wait until users prove demand

This usually reduces both cost and time.

Overspending Pattern 3: Adding Too Many Integrations Early

Integrations often sound small in planning and become large in implementation.

Every integration adds:

Setup
Edge cases
Maintenance
Sync logic
Failure handling

If it is not central to the MVP, it is often better to delay it.

Where Founders Cut the Wrong Corners

Wrong Shortcut 1: Treating the MVP Like a Throwaway Build

If the product works, gets users, and shows traction, you will want to keep building on it.

A bad foundation can become more expensive than starting properly.

Wrong Shortcut 2: Ignoring Performance Until Later

Many SaaS products feel slow right after launch because performance was not considered during the MVP phase.

That slows onboarding, hurts trust, and makes the product feel weaker than it is.

Wrong Shortcut 3: Weak Auth and Admin Flows

A lot of early products underestimate how important clean auth, role handling, and admin visibility are.

These are often the parts that make a product feel real rather than half-finished.

If you want to avoid those problems, this is exactly the kind of thinking I bring to SaaS MVP development.

A Better Way to Think About MVP Budget

Instead of asking for one big estimate for "the whole app," break it into these layers:

Layer 1: Core User Problem

What is the single most important workflow?

Layer 2: Minimum Product Credibility

What does the product need so real users will trust it enough to try it?

Layer 3: Launch Essentials

What needs to exist for a real release, not just an internal demo?

Layer 4: Delay List

What can wait until after the first feedback cycle?

This framework usually leads to a much more realistic MVP budget.

My Practical Advice for Founders

If you want a smarter MVP budget in 2026, do this:

Start with one painful problem
Keep the feature set narrow
Be serious about fundamentals
Separate MVP from roadmap
Budget for launch, not just coding

A product that only "exists" is not the same as a product that is ready to launch.

If you want more context on that distinction, read What Makes a SaaS MVP Production-Ready (Most MVPs Are Not).

So How Much Should a SaaS MVP Cost?

The real answer is:

It should cost enough to launch something useful and credible, but not so much that you build version two before validating version one.

That is the balance.

A strong MVP is not the cheapest version. It is the smallest version worth shipping.

When to Talk to a Developer Early

You should talk to a technical partner early if:

Your feature list keeps growing
You are unsure what belongs in version one
AI is part of the product
You need user roles, billing, dashboards, or admin flows
You want to avoid rebuilding after launch

That early clarity can save a surprising amount of time and budget.

FAQ: SaaS MVP Cost in 2026

How much does a SaaS MVP cost in 2026?

It depends on the feature set, product complexity, launch quality, and whether the MVP includes things like billing, AI, admin tools, and multiple user roles. The real cost question is whether the scope is disciplined enough for a useful first release.

What increases MVP development cost the fastest?

Loose scope is usually the biggest reason cost rises. After that, the biggest multipliers are billing, permissions, integrations, AI workflows, and trying to include roadmap features in version one.

Should AI be in a SaaS MVP from day one?

Only if it makes the first version materially more useful. If AI is interesting but not essential, it is often better added after launch once the core workflow is validated.

Final Thoughts

Most founders do not actually need the biggest possible MVP.

They need:

The right scope
The right technical decisions
The right launch quality
The right sequencing

That is what keeps cost under control without creating technical debt on day one.

If you are planning an MVP and want to launch without building version one the wrong way, see SaaS MVP Development.

Tired of ChatGPT "forgetting" context, so I engineered a Private "Second Brain" using MERN & Local Llama 3 🧠

Somnath Khadanga — Fri, 23 Jan 2026 15:56:20 +0000

As a full-stack developer juggling multiple projects, context switching is my biggest productivity killer. I use AI tools daily, but they have two major flaws for professional workflow:

They Forget: Start a new chat, and the context is gone. They don't remember the bug I debugged yesterday or the specific architectural constraints of my current project.

Privacy Anxiety: There are times I want to paste sensitive client logic or proprietary snippets, but sending that data to a cloud API feels risky.

I realized I didn't just need a chatbot; I needed a persistent, private "Second Brain" that lived on my machine and knew my work history.

Instead of waiting for a product to solve this, I decided to engineer my own solution using the stack I know best.

The High-Level Architecture
The goal was to build a system that runs 100% locally—no internet connection required for inference, no data leaving my laptop.

Here is the system design I came up with:

The Stack Breakdown

Here is why I chose these specific tools for the job:

Frontend: React (Vite)

Why: I needed a snappy, familiar chat interface. React’s component-based architecture makes it easy to manage chat history state and streaming responses.

*Backend: Node.js / Express
*
Why: It’s the glue. Node acts as the orchestration layer, handling API requests from the frontend, managing file uploads for memory, and communicating asynchronously with the AI engine.

The Brain: Ollama running Llama 3 (8B)

Why: Ollama is hands-down the easiest way to run local models. I chose Llama 3 8B because it hits the sweet spot for my hardware—it's fast enough for real-time chat but smart enough to follow complex instructions.

The Memory (RAG): ChromaDB (running locally)

Why: This is the core of the "Second Brain." I needed a Vector Database to store embeddings of my notes and code. I chose ChromaDB because it's open-source, easy to run locally via Docker, and integrates well with JavaScript ecosystems.

The Challenges: It's Not Magic

Any senior developer knows that the "happy path" is only 20% of the work. The biggest challenge wasn't getting the components to talk to each other; it was Retrieval Accuracy.

Initially, the RAG pipeline was "dumb." It would fetch documents based on simple keyword matching, confusing the LLM with irrelevant context.

The fix (currently in progress): I'm experimenting with smaller, more semantic chunk sizes and looking into implementing a "re-ranking" step—where we retrieve 20 documents but have a smaller, faster model sort them by relevance before sending top 5 to Llama 3. This significantly improves the quality of answers.

Conclusion

This project is still very much a work in progress. It’s messy, but it’s mine, and most importantly, it’s private.

It has forced me to dive deep into the mechanics of Vector Databases and local inference, skills that are becoming essential for modern backend engineering.

If you’re interested in seeing the final polished version or following my journey as I build this out in public:

Follow me on Twitter/X: [👉 https://www.somanathkhadanga.com/]

Check out my other projects: [👉 https://www.somanathkhadanga.com/]

DEV Community: Somnath Khadanga

What to Audit in a Vibe-Coded MVP Before Real Users See It

1. Auth: The Most Common Breaking Point

2. API Routes That Think the Frontend Is the Last Line of Defense

3. Error Messages Are Telling People Too Much

4. Webhook Handlers That Trust Everything

5. Secrets That Ended Up in the Wrong Place

6. Data Model Decisions That Will Hurt at 1,000 Users

7. Deployment Assumptions That Break on Vercel or Railway

8. Rate Limiting and Abuse Prevention

- Any endpoint that triggers a paid action

9. The Production Basics Nobody Vibe-Coded In

The 30-Minute Audit Checklist

- [ ] Email sending domain has SPF, DKIM, DMARC

What to Fix First

When to Call In Someone Else

Final Thoughts

OpenAI on AWS Bedrock: The AI SaaS Provider Landscape Just Shifted

What Actually Got Announced

Why This Matters for AI SaaS Founders

The Provider Landscape in May 2026

Five Real Decisions This Forces You to Think About

1. Direct API or Bedrock?

2. Are you ever going to actually be multi-provider?

3. Where do your customer's tokens live?

4. What's your latency budget?

5. Are you using an AI Gateway?

What I Wouldn't Do Yet

The Bigger Picture

Frequently Asked Questions

Is OpenAI available on AWS Bedrock?

Is AWS Bedrock cheaper than using the OpenAI API directly?

Can I use both OpenAI and Anthropic Claude on the same Bedrock account?

Does AWS Bedrock support GPT-4?

How does OpenAI on Bedrock compare to Azure OpenAI Service?

Final Thoughts

What the Vercel Security Incident Should Teach SaaS Teams About Production Readiness

What Happened

Why This Matters Beyond Vercel

The Real Lesson: Production Readiness Includes Workflow Security

What SaaS Teams Should Review Immediately

1. Third-Party OAuth Access

2. Internal Access Blast Radius

3. Secret and Environment Variable Hygiene

4. Audit Visibility and Ownership

5. Vendor Dependence and Response Discipline

The Founder Angle

What I Would Fix This Week

Final Thought

Sources

Next.js 16 App Router Caching Changed — Here's What to Update in Your SaaS

The Short Version

Why This Matters for SaaS Apps Specifically

What Actually Changed, With Examples

1. fetch() Is No Longer Cached by Default

2. 'use cache' Is the New Primary Caching Primitive

3. Route Segments Default to Dynamic

4. GET Route Handlers Are No Longer Cached

The Upgrade Audit I'd Actually Run

Step 1: Measure Before You Upgrade

Step 2: Upgrade on a Branch, Don't Change Caching Yet

Step 3: Categorize Every Data Access Point

Step 4: Use cacheTag for Invalidation

Step 5: Re-Measure

Three Specific Bugs I've Seen Post-Upgrade

Bug 1: "The Dashboard Got Slower"

Bug 2: "Some Users See Other Users' Data" (Rare but Serious)

Bug 3: "Revalidation Just Stopped Working"

When to Not Upgrade Yet

The Bigger Picture

FAQ

Does Next.js 16 break my existing app?

Do I need to rewrite every fetch() call in Next.js 16?

What replaces unstable_cache in Next.js 16?

Is 'use cache' stable in production?

Final Thoughts

How much should an MVP actually cost?

The Short Answer

What Actually Drives SaaS MVP Cost

1. Scope Is the Biggest Cost Factor

1. `fetch()` Is No Longer Cached by Default

2. `'use cache'` Is the New Primary Caching Primitive

4. `GET` Route Handlers Are No Longer Cached

Step 4: Use `cacheTag` for Invalidation

Do I need to rewrite every `fetch()` call in Next.js 16?

What replaces `unstable_cache` in Next.js 16?

Is `'use cache'` stable in production?