It is a Tuesday at 4pm. The founder has been at their kitchen table for nine hours. Cursor finished the last component an hour ago. Stripe Checkout works. Supabase RLS is on. They run git push, the Vercel deploy turns green, they refresh production, and it loads.

They feel done.

They are not.

In 2026, anyone can have a working SaaS in a weekend. Cursor writes the components. Claude writes the schema. v0 designs the landing page. Supabase handles auth. Stripe ships the checkout. The cost of building software has collapsed in a way nobody predicted three years ago, and that is real, and that is good.

That is also not the problem.

The problem is that vibe-coding ships an app that runs. It does not ship a product that lasts. The 5% of work that AI does for you is the part that used to take six months. The 95% it cannot do for you — operations, money, email reputation, legal, customer trust, on-call discipline — is the part that decides whether your first paying customer churns at week six or sticks for two years.

This article is for the founder who just typed git push and feels done. You are not. Here is the gap between "the code works" and "the SaaS is shipped." It is mostly invisible until it bites you.

The Vibe-Coding Trap

I have watched this pattern three times in the last six months. A founder ships a beautiful prompt-built MVP. The UI is clean — it should be, v0 designed it. The auth flow works. Stripe goes live on day one. They post on LinkedIn. Eight people sign up. Two convert.

Then:

The first refund attempt fails because the customer's bank declined the reverse charge and the founder has no UX for the "do_not_honor" Stripe error code. The customer charges back instead.
The "welcome" email lands in spam for three of the first ten signups because DKIM was never set on the new domain.
An EU customer asks for a Data Processing Agreement. The founder googles "DPA template," panics, and stalls for two weeks.
The Supabase free tier hits its row limit at week four because nobody set up a backup-and-prune cron.
A Sentry alert fires at 11pm Saturday. It is in an email inbox the founder will check on Monday.

By month three, the founder is exhausted, the customer is cold, and the project quietly stops shipping. Nothing about the code was wrong. The code, in fact, was the easy part.

The hardest skill in 2026 is not knowing how to build. Building has been democratized. The hardest skill is knowing what production actually means — and that is exactly the skill no LLM has been trained to teach you, because the training data is full of "how to build a SaaS," not "how to survive shipping one."

The rest of this article is the surviving part.

vibe-coding-trap-desk.webp

A developer's desk at 4pm — empty coffee cup, laptop showing a green Vercel deploy success, a printed pre-launch checklist with most boxes still unchecked.

DALL·E 3 prompt

Editorial top-down photograph of a solo developer's desk at 4pm Tuesday. Empty espresso cup, MacBook showing a successful Vercel deploy screen with a green checkmark, a printed pre-launch checklist on paper next to it with most checkboxes still empty, two sticky notes reading "DKIM?" and "test refund." Warm tungsten desk lamp, dark wood surface, deep navy background (#080d1a), photographic, shallow depth of field, slightly desaturated, no faces visible, premium SaaS magazine aesthetic. --ar 16:9 --style raw --q 2 --v 6

1. The Five Things First-Time Founders Get Wrong

1.1 Don't ship payments live without running a real refund

Test mode lies. Webhook payloads differ. Tax behaviour differs. 3D Secure challenges differ. The first time you discover this should not be when an actual customer is on the phone.

The fix is thirty minutes of work. Switch one of your cards to live, charge yourself CHF 25, then refund it from the dashboard. Watch the webhook. Watch your soft-lock recovery. Watch your audit log. Watch your invoice PDF. Watch your customer email.

The first refund you do should not be a customer's.

Cursor will write your checkout flow. It will not write your refund policy, your VAT registration, or your soft-lock recovery — because those are not code, they are decisions, and they require you to have thought about what your business actually does when something goes wrong.

1.2 Email reputation is set before launch, not after

The day you send 50 invitations is the day Gmail decides whether your domain is trustworthy or not. That decision sticks. It is very hard to reverse.

Concrete checklist, before you send a single transactional email:

SPF, DKIM, DMARC verified on the sending domain. Use mxtoolbox.com to confirm. All three. Not two.
Google Postmaster Tools registered. You will not see deliverability data without it.
Microsoft SNDS and JMRP registered. Outlook reputation matters more than first-time founders think — many B2B inboxes are still on Microsoft 365.
Two weeks of warm-up. Send 1–2 manual emails per day to friendly inboxes, then ramp slowly. Do not blast 200 transactional emails on launch day from a fresh domain.

The single biggest deliverability mistake first-time founders make: a fresh domain blasts 200 transactional emails on launch day. Half land in spam. Customers do not tell you. They simply do not reply, and you spend the next week wondering why your conversion rate is so bad.

DKIM is not a vibe. It is a DNS record, and it is the difference between "professional SaaS" and "phishing attempt" in the eyes of every spam filter on Earth.

1.3 Your first ten customers are your QA team, not your revenue

Do not chase 50 signups. Find one customer that owes you a favour. Sit in their office on a Monday morning. Watch what breaks.

Onboarding friction shows up in the first five minutes or it does not show up at all. If they get confused, that is not their fault. That is a bug you did not see — usually because you wrote the copy and you already know what every button does.

The first ten customers will tell you what 100 will not: where the language is wrong, where the empty states fail, what they wish they could do "from their phone, in the car." A hundred customers tell you average behaviour. Ten customers, watched closely, tell you what your product actually is.

Founder A chases sign-ups. They run a Product Hunt launch, they buy LinkedIn ads, they hit 30 trial users in week one. None convert. By week twelve they have 30 churned trials, no testimonial, and a graveyard analytics dashboard.

Founder B finds one company that needs the thing, sells them the thing at full price, and spends three months making sure that one company stays. By week twelve they have one customer, full price, three referrals, and a clear roadmap. Founder B wins. Founder B always wins.

1.4 Live Stripe finds bugs test mode never does

Test mode is a happy path. Live mode is the real world. Things you will only see live:

Tax. VAT registration thresholds, EU OSS rules, Swiss MwSt rounding, B2B reverse-charge logic. None of this fires in test mode.
3D Secure. Real EU cards challenge ~30% of the time. Your "redirect after checkout" flow needs to handle the challenge interrupt cleanly. Test mode rarely triggers it.
Card declined: do_not_honor with no actionable error from the bank. Your error UI must give the user something — "Your bank declined the charge. Try another card or contact your bank" — not a stack trace and not "payment failed."
Currency rounding. If you charge in EUR but report in CHF, you will see a 1-cent drift on a percentage of transactions. Decide how to handle it before a customer notices.

Plan a week between "Stripe live keys deployed" and "first paying customer." That buffer is where you find the surprises. Skip it and the surprises find your customer.

1.5 Don't ship on Friday. Don't migrate the database on Friday.

A bug shipped at 4:30pm Tuesday is a 7pm pager call. A bug shipped at 4:30pm Friday is a weekend.

Don't push to production after 4pm any day, ever. The cost of waiting until Monday morning is zero. The cost of debugging a Friday-night migration with one tester (you, exhausted) is enormous.

This is not about cowardice. It is about respecting the asymmetric cost of recovery time. You can ship faster on Monday. You cannot ship safer on Sunday at midnight.

pre-launch-checklist-overlay.webp

A holographic pre-launch checklist floating above a glowing terminal — Stripe, DKIM, GDPR, /health, backups.

DALL·E 3 prompt

Cinematic dark editorial illustration. A glowing terminal cursor blinking on a polished black surface, with a faint translucent checklist of operational items (Stripe live, DKIM verified, GDPR DPA, /health endpoint, backups tested) floating above it like a holographic overlay. Cyan and violet rim lighting, deep navy background (#080d1a), subtle film grain, minimalist composition. Sharp focus on the cursor, soft bokeh on the checklist. No human figure. No text in the rendered image — the checklist items should be illegible glyphs to keep it visual. --ar 16:9 --style raw --q 2 --v 6

2. Observability — Beyond "I Have Sentry"

Installing Sentry does not count as observability. It counts as a starting point.

2.1 Pipe critical alerts to a phone-bothering channel

Sentry email goes to a folder you check tomorrow. Tomorrow is too late if Stripe webhooks are 5xx-ing right now and a customer just paid.

The fix: a Telegram bot, ntfy.sh, Pushover, or a Twilio SMS hook. Anything that vibrates a phone for prod fatal errors, Stripe webhook 5xx, and /health endpoint failing. Email equals no signal. Treat it that way.

2.2 Session Replay for the first 50 customers

Sentry has it. Turn it on. Disable it later when volume grows and the cost flips.

Session Replay records anonymized video of how users actually move through your app. The first un-reproducible bug report — "I clicked the button and nothing happened" — justifies the cost ten times over. You will see the customer hovering over the wrong button for fifteen seconds. That is not a customer problem. That is a UX bug, and you would never have caught it in testing.

2.3 A /health endpoint your monitor checks every minute

The endpoint checks: database reachable, Stripe key valid (a no-op API call), email provider key valid. UptimeRobot, BetterStack, or even a free GitHub Actions cron on a five-minute schedule.

Cost: free. Time: thirty minutes. Value: catches outages before customers do. There is no excuse for not having this on launch day.

2.4 Backups: test the restore once

Your provider runs nightly backups. You do not know if they work. Spin up a staging project, restore yesterday's backup, verify your data. Once. Now. Before you need it.

The day you actually need a restore is not the day to discover the docs lied. A founder I know discovered, on the day a junior dev truncated the wrong table, that their nightly backups had been failing silently for three weeks because of an expired credential. They lost twelve days of customer data and a contract worth four months of revenue.

Migration files in git are not a backup. The DB is the source of truth. Migrations are a recipe, not a snapshot. Founders confuse this regularly.

An AI built your app. It is not on call when it dies at 2am. You are.

3. Email — The Underrated Trust Layer

Founders dismiss email as "solved." It is not. It is the most dangerous part of your stack because failure is invisible — you do not know what landed in spam, only what bounced.

3.1 Three things to do before you launch

DNS. SPF + DKIM + DMARC. Verify with mxtoolbox.com. All three.
Register. Google Postmaster, Microsoft SNDS, Microsoft JMRP. Free. Five minutes each.
Warm up. Two weeks of low-volume real sends to friendly inboxes. Do not blast on day one.

3.2 The transactional email digest fatigue trap

Your customers will get: invite emails, reminder emails, billing emails, tip-of-the-day emails, system emails, password reset emails. Five emails a week from your domain is the threshold where your reputation starts hurting itself.

Consolidate where you can. Daily digests are better than five separate emails. Always offer "less email" in settings — and respect it.

3.3 Reply-to your customer's actual support inbox

no-reply@yourdomain.com is hostile. At minimum, route replies to a real inbox. Bonus: have a human reply within the same business day for the first three months. Customers tell their friends about that. They do not tell their friends about a chatbot that took six hours to misunderstand them.

3.4 The single deliverability tip nobody mentions

Avoid words in transactional subject lines that look like marketing: "free," "trial," "offer," "exclusive," "winner." Spam filters are bayesian. Your subject line is your reputation.

"Your trial expires in 3 days" → "Sparkd · trial ending Friday" reads as transactional, not marketing. Same information. Different deliverability tier.

legal-compliance-stack.webp

A neat stack of compliance documents under tungsten light — privacy policy, DPA, GDPR forms — with a Swiss + EU flag motif.

DALL·E 3 prompt

Moody editorial photograph of a neat stack of legal compliance documents on a dark wooden desk. Top page reads "Data Processing Agreement" in subtle relief. A small Swiss flag pin and an EU flag pin sit beside the stack. Warm tungsten light from upper left, deep navy background, slight haze, premium magazine aesthetic, photographic, no people, paper-and-ink texture, shallow depth of field. --ar 16:9 --style raw --q 2 --v 6

4. Legal Compliance — Swiss/EU Specific

This section is concrete and unsexy. Just get the founder out of trouble.

4.1 Swiss FADP (revFADP)

In force since September 2023. If you have any Swiss customer or process Swiss data, you are in scope. Your privacy policy must name your data processors specifically: hosting, database, email, payments, error tracking, analytics. Be specific. "We use Stripe (USA, Inc.)" not "we use payment providers."

Right to information. Right to deletion. Right to data portability. All required. All shippable in a weekend if you plan for it. Catastrophic to retrofit if you do not.

4.2 GDPR DPA template

A Data Processing Agreement is the contract that says here is what we do with your data, here is who we share it with, here is what happens if we have a breach. Any B2B EU customer will ask for one. They will refuse to sign your contract until they have it.

Do not write it from scratch. Adapt one from a sane template (saaslawyer.com, GitHub templates) and have a Swiss lawyer review for €500–€1,500 once. Reuse forever.

ChatGPT will not represent you in a Swiss DPA dispute. Pay the lawyer.

4.3 EU VAT and the One-Stop-Shop scheme

B2C EU revenue greater than €10,000 cross-border in a year? You must register for OSS VAT. B2B EU customer? Reverse charge applies if you collect their VAT ID. Build that into your billing settings before launch — retrofitting it costs more than doing it right.

Swiss VAT (MwSt) at 8.1% applies to Swiss B2C and Swiss B2B. Do not forget it. Underpayment penalties in Switzerland are unkind.

4.4 Cookie banner — only if you need it

If you have EU visitors AND any analytics that uses cookies (Google Analytics, PostHog with cookies enabled), you need consent. Cookie-less analytics (Plausible default, Fathom) avoid the banner entirely. Strongly consider this — your conversion rate will thank you.

5. Mobile (Where Applicable)

5.1 Test on a €100 Android in a basement

Your dev MacBook on fibre Wi-Fi is the best-case scenario your users will never experience. The real test: a cheap Android, one bar of 4G, 6am, photo upload. If that works, your app works. If it does not, you do not have an app — you have a demo.

5.2 Add the Apple meta tags even without a PWA

apple-mobile-web-app-capable, apple-mobile-web-app-status-bar-style — three lines in your <head>. When a customer "Add to Home Screen," the app feels native. Massive perceived-quality bump for zero effort.

5.3 Mobile-web is fine; native is a trap

A native app triples your maintenance and gives roughly zero retention bump for an internal-tool SaaS. Do not build a native app until your customers literally cancel because of its absence. They will not.

6. Founder Ops — The Counter-Intuitive Stuff

This section is psychology, not engineering. Be honest about the failure modes.

6.1 Set support hours and enforce them

"9–18 Mon–Fri, 1-business-day SLA, urgent issues via WhatsApp" beats silence every time. Customers respect a documented SLA. They resent silent founders.

Burning out at 11pm on a Sunday because a customer reported a non-urgent typo is a self-inflicted wound. Sleep is a feature.

6.2 A public changelog is the cheapest retention tool

A /changelog page. Doesn't have to be fancy. Even a Notion page linked from settings. Customers love seeing motion. Founders consistently underestimate this. Look at how Linear, Resend, Vercel, and Stripe publish changelogs — that level of discipline, at any scale, signals "this product is alive."

6.3 Default to "no" on feature requests for six months

Most requests are local maxima for one customer. The right reply: "What problem does that solve?" Then ask "Would you pay 20% more for it?"

Eighty percent of the time the existing system already solves it. They did not find the feature. The other twenty percent become next quarter's roadmap, prioritized by who will pay for it.

6.4 Don't grow the team yet

One person plus one happy customer doing 20 jobs a week beats five people plus zero customers. Hire only after a customer is paying you full price and asking for things you genuinely cannot ship alone.

Hiring early is the most expensive validation mistake first-time founders make. The salary is not the cost. The cost is the management overhead, the meetings, the loss of speed — paid out of a runway that has not yet been earned.

6.5 Talk to your first customer every week

The single most important rule in this article. If you cut everything else, keep this one.

Voice or video, not email. Ask "what did you do in our app today" and "what did you do outside it that you wished was inside it." Half your roadmap will rewrite itself in 90 days, and you will save yourself from building three features nobody wants.

7. Anti-Patterns — What NOT to Build

❌ Realtime updates because someone says "I want it to update automatically." Cost vs. value at small scale is bad. Window-focus refresh is enough until you are at thousands of organizations.
❌ AI / ChatGPT features for at least a year. Your job is making customers' Mondays easier, not bolting on hype. The market is already saturated with "ChatGPT for X." Be the one without it.
❌ Native mobile app before mobile-web has been validated by real users. Triples maintenance, near-zero retention bump for B2B tools.
❌ Promised SLAs you cannot measure. "99.9% uptime" requires you to measure uptime. Pick a number you can defend with data.
❌ Multi-region until you have a customer in another region asking about latency. Single-region single-DB is fine through low thousands of customers.
❌ Your own auth system. Use Auth0, Supabase Auth, Clerk, anything. Auth bugs are the #1 cause of catastrophic data leaks. This is the one place where "build it yourself" is wrong.

8. The Pre-Launch Checklist

Print this. Do them in order.

PRE-LAUNCH CHECKLIST

1. Stripe live
   ☐ Live keys swapped (use printf, never echo, to avoid \n corruption)
   ☐ Test refund executed end-to-end on your own card
   ☐ Webhook delivery verified in Stripe dashboard
   ☐ Tax registration / VAT settings confirmed

2. Email
   ☐ SPF, DKIM, DMARC published and verified
   ☐ Google Postmaster + Microsoft SNDS registered
   ☐ Domain warmed for 2 weeks at low volume

3. Backups
   ☐ Restore tested on staging once
   ☐ Restore runbook documented (where, who, how long)

4. Alerting
   ☐ Sentry critical alerts → phone (Telegram / ntfy / SMS)
   ☐ /health endpoint → uptime monitor (1-min interval)
   ☐ Stripe webhook 5xx → alert channel

5. Legal
   ☐ Privacy policy (names processors, jurisdiction-specific)
   ☐ Terms of Service
   ☐ DPA template ready (B2B EU customers will ask)
   ☐ Cookie banner — or migrate to cookie-less analytics

6. Onboarding content
   ☐ Every step copy reviewed by a real human
   ☐ All locales (if applicable) translated by humans, not Google
   ☐ Empty states with clear next-action CTAs

7. First customer
   ☐ Found, contracted, scheduled for Monday morning ride-along
   ☐ Direct phone line for first 30 days

8. Status page
   ☐ status.yourdomain live (BetterStack free tier — 5 min setup)
   ☐ Linked from app footer + support emails

If even one box is unchecked on launch day, you are not launching. You are gambling.

The One Rule

AI made the first 5% trivial. The other 95% still belongs to founders who do the boring work.

The pre-launch checklist will get you to the door. Talking to your first customer every week for three months is what gets them to stay.

Code is a precondition. The launch is operations, communication, and not panicking on launch day.

Good luck.

This article is the pre-launch hardening pass we ran before shipping Sparkd, a multi-tenant SaaS for cleaning operators. Every item on the checklist is one we executed — usually after learning the hard way that we should have.

They feel done.

They are not.

That is also not the problem.

This article is for the founder who just typed git push and feels done. You are not. Here is the gap between "the code works" and "the SaaS is shipped." It is mostly invisible until it bites you.

The Vibe-Coding Trap

Then:

The first refund attempt fails because the customer's bank declined the reverse charge and the founder has no UX for the "do_not_honor" Stripe error code. The customer charges back instead.
The "welcome" email lands in spam for three of the first ten signups because DKIM was never set on the new domain.
An EU customer asks for a Data Processing Agreement. The founder googles "DPA template," panics, and stalls for two weeks.
The Supabase free tier hits its row limit at week four because nobody set up a backup-and-prune cron.
A Sentry alert fires at 11pm Saturday. It is in an email inbox the founder will check on Monday.

By month three, the founder is exhausted, the customer is cold, and the project quietly stops shipping. Nothing about the code was wrong. The code, in fact, was the easy part.

The rest of this article is the surviving part.

vibe-coding-trap-desk.webp

A developer's desk at 4pm — empty coffee cup, laptop showing a green Vercel deploy success, a printed pre-launch checklist with most boxes still unchecked.

DALL·E 3 prompt

1. The Five Things First-Time Founders Get Wrong

1.1 Don't ship payments live without running a real refund

Test mode lies. Webhook payloads differ. Tax behaviour differs. 3D Secure challenges differ. The first time you discover this should not be when an actual customer is on the phone.

The first refund you do should not be a customer's.

1.2 Email reputation is set before launch, not after

The day you send 50 invitations is the day Gmail decides whether your domain is trustworthy or not. That decision sticks. It is very hard to reverse.

Concrete checklist, before you send a single transactional email:

SPF, DKIM, DMARC verified on the sending domain. Use mxtoolbox.com to confirm. All three. Not two.
Google Postmaster Tools registered. You will not see deliverability data without it.
Microsoft SNDS and JMRP registered. Outlook reputation matters more than first-time founders think — many B2B inboxes are still on Microsoft 365.
Two weeks of warm-up. Send 1–2 manual emails per day to friendly inboxes, then ramp slowly. Do not blast 200 transactional emails on launch day from a fresh domain.

DKIM is not a vibe. It is a DNS record, and it is the difference between "professional SaaS" and "phishing attempt" in the eyes of every spam filter on Earth.

1.3 Your first ten customers are your QA team, not your revenue

Do not chase 50 signups. Find one customer that owes you a favour. Sit in their office on a Monday morning. Watch what breaks.

1.4 Live Stripe finds bugs test mode never does

Test mode is a happy path. Live mode is the real world. Things you will only see live:

Tax. VAT registration thresholds, EU OSS rules, Swiss MwSt rounding, B2B reverse-charge logic. None of this fires in test mode.
3D Secure. Real EU cards challenge ~30% of the time. Your "redirect after checkout" flow needs to handle the challenge interrupt cleanly. Test mode rarely triggers it.
Card declined: do_not_honor with no actionable error from the bank. Your error UI must give the user something — "Your bank declined the charge. Try another card or contact your bank" — not a stack trace and not "payment failed."
Currency rounding. If you charge in EUR but report in CHF, you will see a 1-cent drift on a percentage of transactions. Decide how to handle it before a customer notices.

Plan a week between "Stripe live keys deployed" and "first paying customer." That buffer is where you find the surprises. Skip it and the surprises find your customer.

1.5 Don't ship on Friday. Don't migrate the database on Friday.

A bug shipped at 4:30pm Tuesday is a 7pm pager call. A bug shipped at 4:30pm Friday is a weekend.

Don't push to production after 4pm any day, ever. The cost of waiting until Monday morning is zero. The cost of debugging a Friday-night migration with one tester (you, exhausted) is enormous.

This is not about cowardice. It is about respecting the asymmetric cost of recovery time. You can ship faster on Monday. You cannot ship safer on Sunday at midnight.

pre-launch-checklist-overlay.webp

A holographic pre-launch checklist floating above a glowing terminal — Stripe, DKIM, GDPR, /health, backups.

DALL·E 3 prompt

2. Observability — Beyond "I Have Sentry"

Installing Sentry does not count as observability. It counts as a starting point.

2.1 Pipe critical alerts to a phone-bothering channel

Sentry email goes to a folder you check tomorrow. Tomorrow is too late if Stripe webhooks are 5xx-ing right now and a customer just paid.

2.2 Session Replay for the first 50 customers

Sentry has it. Turn it on. Disable it later when volume grows and the cost flips.

2.3 A /health endpoint your monitor checks every minute

The endpoint checks: database reachable, Stripe key valid (a no-op API call), email provider key valid. UptimeRobot, BetterStack, or even a free GitHub Actions cron on a five-minute schedule.

Cost: free. Time: thirty minutes. Value: catches outages before customers do. There is no excuse for not having this on launch day.