DEV Community: masato

Canva MCPで日本語タイトルが「天久百厳浸」になった — AI生成の限界と代替手順の記録

masato — Mon, 20 Jul 2026 19:51:15 +0000

Canva MCP Generated "天久百厳浸" Instead of My Japanese Title — Failure Log

I called Canva MCP from Claude Code to generate hero images with Japanese titles. All 4 generated images had random kanji characters ("天久百厳浸", "米岡済本") that had nothing to do with my actual title.

Root Cause

Canva's AI image generation engine is trained primarily on English corpora and cannot preserve the semantic meaning of Japanese text when rendering it visually.

Operation	Japanese Text Handling
generate-design (AI generation)	Random kanji output
Template copy + text edit	Works correctly

The Fix: Pillow + Bundled TTF Fonts

from PIL import ImageFont, ImageDraw, Image

# Bundle TTF in the repo — don't rely on system fonts
title_font = ImageFont.truetype("public/fonts/NotoSansJP-Bold.ttf", size=48)
sub_font   = ImageFont.truetype("public/fonts/NotoSansJP-Regular.ttf", size=24)

Key insight: System font dependencies (like IPAGothic) break in cloud environments. Bundling fonts in the repo makes the pipeline reproducible.

Decision Framework

"Is this tool trained on English corpora?"

YES → Don't trust it for Japanese content semantic integrity
NO or local processing (Pillow, ImageMagick) → Fine

"Is this running in an automated pipeline without human review?"

YES → Don't use AI-generated text for Japanese content

Full failure log (in Japanese) at masatoman.net.

Automating Content Briefs with Claude Code + Supabase Queue

masato — Mon, 20 Jul 2026 19:51:14 +0000

Built a 3-layer content pipeline using Claude Code routines:

weekly-content-planner (weekly) — reads GSC/GA4 CSVs, generates priority-ranked briefs, INSERTs into Supabase content_briefs
content_briefs table — acts as a queue with status: planned → in_progress → published
content-executor (daily 02:00 JST) — pulls 1 brief, writes MDX article, git pushes, Slack notifies

The key design constraint is in CLAUDE.md:

Max 1 article per day (hard rule)
No fabricated numbers — only use data from data_evidence field
If lint script not found → skip and continue (don't halt)

3 failures I hit:

Mixed up prod/staging Supabase project_id
Executor halted on missing lint script
Claude generated fake "200 subscribers" in ExperienceBox

Full implementation log (Japanese): https://masatoman.net/articles/claude-code-weekly-content-planner-routine-2026

How I burned through Supabase's free egress limit (5GB 10.26GB) with polling and select=*

masato — Sun, 19 Jul 2026 19:16:34 +0000

TL;DR

Supabase free plan: 5GB egress/month
My project: 10.26GB (205% over limit)
Root cause: 5-second polling × select('*') on a table with a 200,000-char text column
Fix: generated column flag + select column restriction + visibilitychange polling stop

What happened

My KOBO project (issue-finder) had a collection-queue-form component polling if_jobs every 5 seconds via select('*'). The table includes raw_input_text (up to 200K chars). Through Vercel Functions, every poll was shipping that full column downstream.

5s interval × 200,000 chars × hours of operation = GB gone

Noticed when I checked the Supabase dashboard on 2026-05-31.

Fix 1: Generated column as boolean flag

If I only need to know whether raw input exists, I don't need to ship the text:

ALTER TABLE if_jobs
ADD COLUMN has_raw_input boolean
  GENERATED ALWAYS AS (raw_input_text IS NOT NULL) STORED;

Fix 2: Narrow the select

// Before
const { data } = await supabase.from('if_jobs').select('*')

// After — list view only needs lightweight columns
const { data } = await supabase
  .from('if_jobs')
  .select('id, status, has_raw_input, created_at, updated_at')

Fix 3: Slow down polling + stop on hidden tab

useEffect(() => {
  let interval: ReturnType<typeof setInterval> | null = null
  const start = () => { interval = setInterval(fetch, 30_000) } // 5s → 30s
  const stop = () => { if (interval) clearInterval(interval) }
  document.addEventListener('visibilitychange', () =>
    document.hidden ? stop() : start()
  )
  start()
  return stop
}, [])

When does this happen to you?

select('*') on a table with large text/JSON columns
Polling interval ≤ 10s
Serverless function proxy (Vercel, etc.) — egress counted on every hop

Full writeup (Japanese): https://masatoman.net/articles/supabase-egress-overage-free-plan-2026

Usage-Based Billing for Indie Hackers 2026: Implement Stripe Meter API in 5 Files

masato — Sun, 19 Jul 2026 19:16:21 +0000

TL;DR

Flat-rate pricing forces a dilemma: too cheap and heavy users drain your margin; too expensive and light users churn. Usage-based billing (metered pricing) ties revenue to the value you deliver.

Here's the 5-file implementation using Stripe Meter API + Supabase + Next.js:

File	Role
Stripe Dashboard	Create Meter + metered Price
`supabase/migrations/add_usage_events.sql`	Store usage locally for real-time display
`app/api/usage/record/route.ts`	Record events to both Stripe and Supabase
`app/api/stripe/webhook/route.ts`	Handle `invoice.payment_succeeded`
`components/UsageMeter.tsx`	Show real-time usage gauge in dashboard

Step 0: Create a Stripe Meter

In Stripe Dashboard → Billing → Meters → Create meter:

Field	Example
Meter name	`ai_tokens`
Event name	`ai_token_consumed`
Aggregation	`SUM`

Then create a metered Price under Products. Set Billing type to Per unit and link it to your Meter.

Step 1: Supabase Usage Table

-- supabase/migrations/add_usage_events.sql
CREATE TABLE IF NOT EXISTS usage_events (
  id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id      uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  event_type   text NOT NULL,
  quantity     integer NOT NULL DEFAULT 1,
  metadata     jsonb,
  created_at   timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX ON usage_events (user_id, event_type, created_at DESC);

CREATE OR REPLACE VIEW usage_monthly AS
SELECT
  user_id,
  event_type,
  date_trunc('month', created_at) AS month,
  SUM(quantity) AS total_quantity
FROM usage_events
GROUP BY user_id, event_type, date_trunc('month', created_at);

Why Supabase too? Stripe Meter is aggregated for billing — not great for real-time UI. Supabase lets you show used: 47,200 / 100,000 tokens in the dashboard without extra API calls.

Step 2: Record Usage (Stripe + Supabase)

// app/api/usage/record/route.ts
import { stripe } from '@/lib/stripe'
import { createClient } from '@/lib/supabase/server'
import { NextResponse } from 'next/server'

export async function POST(req: Request) {
  const supabase = createClient()
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })

  const { eventType, quantity, metadata } = await req.json()

  const { data: profile } = await supabase
    .from('profiles')
    .select('stripe_customer_id')
    .eq('id', user.id)
    .single()

  await Promise.all([
    supabase.from('usage_events').insert({ user_id: user.id, event_type: eventType, quantity, metadata }),
    profile?.stripe_customer_id
      ? stripe.billing.meterEvents.create({
          event_name: eventType,
          payload: {
            stripe_customer_id: profile.stripe_customer_id,
            value: String(quantity),
          },
        })
      : Promise.resolve(),
  ])

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

Call this from your AI feature route — fire-and-forget so it doesn't block the response:

// After your AI call resolves
const tokensUsed = completion.usage?.total_tokens ?? 0
fetch('/api/usage/record', {
  method: 'POST',
  body: JSON.stringify({ eventType: 'ai_token_consumed', quantity: tokensUsed }),
})

Step 3: Handle Invoice Webhook

// app/api/stripe/webhook/route.ts (metered billing section)
case 'invoice.payment_succeeded': {
  const invoice = event.data.object as Stripe.Invoice
  const customerId = invoice.customer as string

  const { data: profile } = await supabase
    .from('profiles')
    .select('id')
    .eq('stripe_customer_id', customerId)
    .single()

  if (!profile) break

  await supabase.from('billing_cycles').upsert({
    user_id: profile.id,
    period_start: new Date(invoice.period_start! * 1000).toISOString(),
    period_end:   new Date(invoice.period_end!   * 1000).toISOString(),
    amount_paid:  invoice.amount_paid,
  })
  break
}

Step 4: Real-Time Usage Meter Component

// components/UsageMeter.tsx
'use client'
import { createClient } from '@/lib/supabase/client'
import { useEffect, useState } from 'react'

export function UsageMeter({
  userId, eventType, limit, label,
}: {
  userId: string; eventType: string; limit?: number; label?: string
}) {
  const [used, setUsed] = useState(0)
  const supabase = createClient()

  useEffect(() => {
    const monthStart = new Date(new Date().getFullYear(), new Date().getMonth(), 1).toISOString()
    supabase
      .from('usage_events')
      .select('quantity')
      .eq('user_id', userId).eq('event_type', eventType).gte('created_at', monthStart)
      .then(({ data }) => setUsed((data ?? []).reduce((s, r) => s + r.quantity, 0)))
  }, [userId, eventType, supabase])

  const pct = limit ? Math.min((used / limit) * 100, 100) : null

  return (
    <div className="space-y-1">
      <div className="flex justify-between text-sm text-gray-600">
        <span>{label ?? eventType}</span>
        <span>{used.toLocaleString()}{limit ? ` / ${limit.toLocaleString()}` : ''}</span>
      </div>
      {pct != null && (
        <div className="h-2 w-full rounded bg-gray-200">
          <div
            className={`h-2 rounded ${pct >= 90 ? 'bg-red-500' : 'bg-blue-500'}`}
            style={{ width: `${pct}%` }}
          />
        </div>
      )}
    </div>
  )
}

When Usage-Based Billing Makes Sense

Product Type	Fit
AI-powered features (tokens, API calls)	✅ Cost-aligned
Storage / bandwidth dependent	✅ Cost-aligned
Uniform usage patterns	⚠️ Flat rate is simpler
B2C individual users	⚠️ Some users dislike unpredictable bills
B2B team usage	✅ Usage scales with team value

Practical hybrid for indie hackers: Base fee (e.g., $10/month) + overage charges. This avoids Stripe's minimum invoice amount issue and gives users a predictable floor.

Full design rationale and Japanese-language version at: masatoman.net/articles/indie-dev-usage-based-billing-2026

Building a Referral Program for Indie SaaS 2026 — Stripe Coupons + Supabase + Resend

masato — Sat, 18 Jul 2026 19:14:39 +0000

TL;DR

No ad budget. Small audience. But you have a few happy users. A referral program turns those users into your sales team.

Here's the 4-file setup:

supabase/migrations/referrals.sql — referrals table + RLS
lib/referral.ts — code generation + signup tracking
lib/referral-reward.ts — Stripe coupon reward on conversion
lib/referral-emails.ts — Resend notification email

Why Referral Works for Indie SaaS

Early indie SaaS users share communities. If your user is a developer building side projects, their network is full of other developers building side projects — which is exactly your target.

This means referral quality is naturally high. You're not buying random clicks.

Industry reports (ReferralHero, Viral Loops) suggest that referral programs in early-stage tools-type SaaS can contribute 10–30% of new signups. Treat these as benchmark ranges, not promises — actual results depend heavily on your community engagement and product enthusiasm.

Database Schema

ALTER TABLE profiles ADD COLUMN referral_code TEXT UNIQUE;
ALTER TABLE profiles ADD COLUMN referred_by TEXT;

CREATE TABLE referrals (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  referrer_id UUID REFERENCES auth.users(id) NOT NULL,
  referee_id UUID REFERENCES auth.users(id),
  referral_code TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'pending'
    CHECK (status IN ('pending', 'signed_up', 'converted', 'rewarded')),
  stripe_coupon_id TEXT,
  created_at TIMESTAMPTZ DEFAULT now(),
  converted_at TIMESTAMPTZ,
  rewarded_at TIMESTAMPTZ
);

ALTER TABLE referrals ENABLE ROW LEVEL SECURITY;
CREATE POLICY "users can see own referrals"
ON referrals FOR SELECT
USING (referrer_id = auth.uid() OR referee_id = auth.uid());

Referral Code Generation

// lib/referral.ts
import { customAlphabet } from 'nanoid'
const nanoid = customAlphabet('ABCDEFGHJKLMNPQRSTUVWXYZ23456789', 8)

export async function ensureReferralCode(userId: string): Promise<string> {
  const supabase = createClient()
  const { data: profile } = await supabase
    .from('profiles').select('referral_code').eq('id', userId).single()

  if (profile?.referral_code) return profile.referral_code

  const code = nanoid()
  await supabase.from('profiles').update({ referral_code: code }).eq('id', userId)
  return code
}

Using a custom alphabet without I, O, 0, 1 prevents misreading.

Tracking Referral Signups

export async function trackReferralSignup(refereeId: string, referralCode: string) {
  const supabase = createClient()
  const { data: referrer } = await supabase
    .from('profiles').select('id').eq('referral_code', referralCode).single()

  if (!referrer || referrer.id === refereeId) return // invalid or self-referral

  await supabase.from('referrals').insert({
    referrer_id: referrer.id,
    referee_id: refereeId,
    referral_code: referralCode,
    status: 'signed_up',
  })

  await supabase.from('profiles')
    .update({ referred_by: referralCode }).eq('id', refereeId)
}

Call this in your Auth callback when ?ref= param is present.

Stripe Coupon Reward on Conversion

Listen for customer.subscription.created in your existing Stripe Webhook handler:

// lib/referral-reward.ts
export async function handleReferralConversion(stripeCustomerId: string) {
  const supabase = createClient()

  const { data: profile } = await supabase
    .from('profiles').select('id, referred_by')
    .eq('stripe_customer_id', stripeCustomerId).single()

  if (!profile?.referred_by) return

  const { data: referral } = await supabase
    .from('referrals').select('id, referrer_id')
    .eq('referral_code', profile.referred_by)
    .eq('referee_id', profile.id)
    .eq('status', 'signed_up').single()

  if (!referral) return

  const { data: referrerProfile } = await supabase
    .from('profiles').select('stripe_customer_id')
    .eq('id', referral.referrer_id).single()

  if (!referrerProfile?.stripe_customer_id) return

  const coupon = await stripe.coupons.create({
    duration: 'once',
    percent_off: 100,
    name: 'Referral Reward — 1 Month Free',
    metadata: { referral_id: referral.id },
  })

  await stripe.customers.update(referrerProfile.stripe_customer_id, { coupon: coupon.id })

  await supabase.from('referrals').update({
    status: 'rewarded',
    stripe_coupon_id: coupon.id,
    converted_at: new Date().toISOString(),
    rewarded_at: new Date().toISOString(),
  }).eq('id', referral.id)

  return { referrerId: referral.referrer_id }
}

Resend Notification Email

// lib/referral-emails.ts
export async function sendReferralRewardEmail(referrerId: string) {
  const supabase = createClient()
  const { data: profile } = await supabase
    .from('profiles').select('email, display_name').eq('id', referrerId).single()

  if (!profile?.email) return

  await resend.emails.send({
    from: 'masato@masatoman.net',
    to: profile.email,
    subject: '🎉 Referral reward — your next month is free',
    html: `<p>The person you referred just upgraded. Your next billing cycle is on us.</p>`,
  })
}

Implementation Cost

Step	Time estimate
DB schema + code gen	1–2h
Signup tracking	1–2h
Stripe coupon reward	2–3h
Resend email	30min–1h

Total: 6–10 hours for a zero-ad-budget acquisition channel.

Full article with the "how does this translate to revenue?" breakdown:
👉 masatoman.net/articles/indie-dev-referral-program-2026

Stripe Dunning for Indie Hackers 2026: Auto-recover Failed Payments with Supabase + Resend

masato — Sat, 18 Jul 2026 19:14:38 +0000

TL;DR

Involuntary churn (subscribers lost to card failures, not cancellations) accounts for 20-40% of SaaS churn per Baremetrics industry data. Here's how to auto-recover them with 3 files:

app/api/stripe/webhook/route.ts — catch invoice.payment_failed
lib/dunning.ts — update Supabase status + generate Billing Portal URL
lib/emails.ts — send recovery email via Resend

Why Involuntary Churn Is Invisible

When Stripe shows "subscription canceled" in your dashboard, it doesn't tell you why. Was it a deliberate cancellation or just an expired card?

Without dunning management, you lose subscribers who actually want to keep paying. Card failures + smart retry exhaustion = silent revenue drain.

Step 0: Enable Stripe Smart Retries

Before touching code, enable automatic retries in the Stripe dashboard:

Billing → Subscriptions and emails → Manage failed payments → Enable smart retries

Stripe's ML picks the optimal retry timing (up to 4 attempts). After that, the subscription is canceled — which is when customer.subscription.deleted fires.

Step 1: Webhook Handler

// app/api/stripe/webhook/route.ts
import Stripe from 'stripe'
import { NextRequest, NextResponse } from 'next/server'
import { handlePaymentFailed, handlePaymentRecovered } from '@/lib/dunning'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: NextRequest) {
  const body = await req.text()
  const sig = req.headers.get('stripe-signature')!

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

  switch (event.type) {
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object as Stripe.Invoice)
      break
    case 'invoice.paid':
      await handlePaymentRecovered(event.data.object as Stripe.Invoice)
      break
  }

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

Step 2: Supabase Update + Billing Portal

// lib/dunning.ts
import Stripe from 'stripe'
import { createClient } from '@/lib/supabase/server'
import { sendPaymentFailedEmail, sendPaymentRecoveredEmail } from '@/lib/emails'

export async function handlePaymentFailed(invoice: Stripe.Invoice) {
  const supabase = createClient()
  const customerId = typeof invoice.customer === 'string'
    ? invoice.customer : invoice.customer?.id
  if (!customerId) return

  const { data: profile } = await supabase
    .from('profiles')
    .select('id, email, name')
    .eq('stripe_customer_id', customerId)
    .single()
  if (!profile) return

  // Mark as past_due
  await supabase
    .from('subscriptions')
    .update({ status: 'past_due', payment_failed_at: new Date().toISOString() })
    .eq('user_id', profile.id)

  // Generate Billing Portal URL
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
  const session = await stripe.billingPortal.sessions.create({
    customer: customerId,
    return_url: `${process.env.NEXT_PUBLIC_BASE_URL}/dashboard`,
  })

  await sendPaymentFailedEmail({
    to: profile.email,
    name: profile.name ?? 'there',
    billingPortalUrl: session.url,
  })
}

export async function handlePaymentRecovered(invoice: Stripe.Invoice) {
  const supabase = createClient()
  const customerId = typeof invoice.customer === 'string'
    ? invoice.customer : invoice.customer?.id
  if (!customerId) return

  const { data: profile } = await supabase
    .from('profiles').select('id, email, name').eq('stripe_customer_id', customerId).single()
  if (!profile) return

  await supabase
    .from('subscriptions')
    .update({ status: 'active', recovered_at: new Date().toISOString() })
    .eq('user_id', profile.id)

  await sendPaymentRecoveredEmail({ to: profile.email, name: profile.name ?? 'there' })
}

Step 3: Recovery Email via Resend

Keep the tone helpful, not accusatory. Most users don't know their card expired.

// lib/emails.ts
import { Resend } from 'resend'
const resend = new Resend(process.env.RESEND_API_KEY)

export async function sendPaymentFailedEmail({
  to, name, billingPortalUrl,
}: { to: string; name: string; billingPortalUrl: string }) {
  await resend.emails.send({
    from: 'support@yourapp.com',
    to,
    subject: `Action required: Update your payment method`,
    html: `
      <p>Hi ${name},</p>
      <p>We had trouble processing your payment — this can happen when a card expires or has insufficient funds.</p>
      <p>
        <a href="${billingPortalUrl}" style="background:#4f46e5;color:#fff;padding:12px 24px;border-radius:6px;text-decoration:none;display:inline-block;">
          Update payment method →
        </a>
      </p>
      <p style="color:#666;font-size:12px;">Stripe will retry automatically, but updating now ensures no service interruption.</p>
    `,
  })
}

Supabase Schema

ALTER TABLE subscriptions
  ADD COLUMN IF NOT EXISTS status TEXT DEFAULT 'active',
  ADD COLUMN IF NOT EXISTS payment_failed_at TIMESTAMPTZ,
  ADD COLUMN IF NOT EXISTS payment_failed_count INTEGER DEFAULT 0,
  ADD COLUMN IF NOT EXISTS recovered_at TIMESTAMPTZ;

Key Stripe Events to Handle

Event	When	Action
`invoice.payment_failed`	Each failed attempt	Notify user + update DB
`customer.subscription.updated`	Status becomes `past_due`	Optional: restrict access
`invoice.paid`	Successful retry / manual update	Restore `active` status
`customer.subscription.deleted`	All retries exhausted	Cancel flow + win-back email

Implementation Cost

Webhook handler: 2-3 hours
Resend email: 1-2 hours
Billing Portal setup + button: 30 min

Total: 4-6 hours to auto-recover failed payments.

Full implementation walkthrough (Japanese) → masatoman.net

Build in Public Week 0: Resetting My Indie Strategy to ¥100K in 3 Months

masato — Fri, 17 Jul 2026 19:21:06 +0000

TL;DR

Goal: ¥100,000 ($670) in total revenue by 2026-07-16
Strategy: One Product Hunt launch on June 9, aiming $149 × 7 = ~¥105,000
Starting line: 47 weekly sessions on my blog, 50 X followers, 0 paid sales
Burn: ¥3,170/month (~$21). I can stay alive for 3 years if this fails.

I reset my indie strategy this week. Here is the raw data from the kickoff of Phase A.

Phase A / B / C

Phase	Dates	Human	Agents (Claude Crew)
A - Prep	4/16 – 5/31	English LP + demo video + Upcoming page	Japanese articles / CTAs / PDCA
B - Launch	6/1 – 6/15	Live on PH, June 9	Post-mortem write-ups
C - Long tail	6/16 – 7/16	Depends on result	Autopilot sales

The whole 3-month plan is engineered so that one day (June 9) decides the entire outcome. I do not spread attention across multiple channels.

Starting line numbers

Blog (masatoman.net)

35 articles published (28 free + 7 paid)
47 sessions / week
Zero paid article sales
Zero newsletter signups

Lesson: Writing more does not create traffic. Google had not indexed the site. So instead of more articles, I need external channels (Zenn, Qiita, X, Dev.to) to feed traffic.

X (Japanese indie dev account)

Metric	Week 1 (3/31)	Week 2 (4/6)
Followers	3	~50
Total likes	—	44
Total views	—	1,933
Top post ER	—	6.2%

Engagement rate by content type (Week 2):

Original + personal story: ER 7.1% (top)
Original + explainer: ER 4.3%
News recap (with label): ER 2.8%
News repost (no label): ER 0.0%

→ Phase A decision: kill all news reposts. Only ship original personal stories.

Fixed cost

Vercel Hobby        ¥0
Supabase Free       ¥0
Resend Free         ¥0
Claude Pro          ¥3,000
Domain              ~¥170 ($13/year ÷ 12)
---
Total               ¥3,170 / month (~$21)

At ~$21/month I can keep iterating for 3 years if Phase A fails. This "immortal strategy" is the real foundation.

Why I am betting on one Product Hunt launch

Japanese indie devs are too good at building. If I ship a template SaaS, they just build their own. I watched my Stripe sessions climb to 33 with zero conversions.

Overseas, there is a "buy time" culture. $149 for a template that saves a month of work is easy math. So I am repositioning:

Japan side: sell operational know-how via a monthly membership (¥1,980/mo)
Overseas side: sell a template SaaS bundle via Gumroad, launched on Product Hunt

Bottlenecks with 52 days left

I am behind schedule. The 5 blockers:

English landing page not shipped
60–90s demo video not recorded
Product Hunt Upcoming page not public
Zero Dev.to reach in English (this post is the first move)
No list of 200 launch-day supporters

Human time is 100% on those five. Everything Japanese (blog posts, SEO, CTA tuning) is fully delegated to a Claude Crew of agents that run every night.

Next week

Mon–Wed: English LP wireframe + v1 copy
Thu–Fri: Publish Product Hunt Upcoming page
Sat: Week 1 Build in Public log (my blog)

Follow the journey

I will post weekly build logs every Saturday. If you want the full 3-month plan, revenue targets, and the Product Hunt launch checklist I am using, read the master version on my blog.

👉 Build in Public: Phase A Kickoff (full Japanese post)

I Raised My Price 3x and Revenue Grew 3.6x — Indie Dev Pricing Guide 2026

masato — Fri, 17 Jul 2026 19:21:05 +0000

The Numbers First

Same content. Same audience. Just a price change.

Metric	Before	After
Price	¥980 (~$6.50)	¥2,980 (~$20)
Monthly sales	5 units	6 units
Monthly revenue	¥4,900	¥17,880
Revenue change	baseline	+264% (3.6x)

Sales count barely changed. Revenue tripled.

This isn't a one-off. It's what happens when you stop underpricing.

Why Engineers Underprice Everything

Mistake 1: Cost-based pricing

Engineers love to calculate: hours_spent × hourly_rate = price

5 hours × $20/hr = $100 → feels too high → price at $10

The problem: buyers don't care about your costs. They care about the value they get.

The right formula: value_created_for_buyer × 0.1~0.3 = price

Example: Your auth template saves a developer 2 days of work.

2 days × $50/hr × 8hrs = $800 saved
Fair price: $800 × 0.15 = $120

You were selling it for $10.

Mistake 2: Racing to the free tier

"There's a free version on GitHub, so I'll price at $5."

Your version has:

Setup documentation
Support
Real-world usage validation
Bug fixes

If you've differentiated, don't match the free tier's price.

Mistake 3: Fear of rejection

The most common reason for underpricing.

Price is a signal. A $5 product and a $20 product with the same features — buyers perceive the $20 version as more serious. Underpricing can hurt conversions.

The 3-Step Pricing Framework

Step 1: Calculate the buyer's "savings cost"

Define your target precisely:

❌ "developers" (too broad)
✅ "employed engineers building a side-project SaaS who waste 2+ days on auth/payments every time"

Savings calculation:
Hourly rate: $50
Time saved: 16 hours (2 days)
Total savings: $800

Appropriate price zone: $80–$240 (10–30% of savings)

Step 2: Create 3-tier pricing

Use the "compromise effect" — people tend to pick the middle option.

Basic    $15  │ Core content only (slightly underwhelming)
Standard $49  │ Core + docs + Q&A ← make this the obvious choice
Premium  $149 │ Full support + 1-on-1 (for people in a hurry)

Design Standard to look like the clear value winner.

Step 3: Raise prices after 10 sales

Signals to raise prices:

Lots of inbound questions (demand > supply of attention)
Few competitors at your price tier
Support is eating too much time

Process:

Notify existing buyers ("price increases in 1 week")
Create urgency with deadline
Raise the price
Monitor conversion rate — if it barely drops, you're still underpriced

2026 Indie Dev Price Reference

Category	Reasonable Range
UI components / simple tools	$5–$30
SaaS starter kits	$30–$200
Auth + payments full implementation	$50–$300
Technical guides (single)	$5–$15
In-depth practical course	$50–$500
SaaS monthly (consumer)	$5–$30/mo
SaaS monthly (business)	$50–$500/mo

TL;DR

Price = (value created for buyer) × 10–30%, not (your cost)
Add Basic/Standard/Premium tiers to anchor the middle
Raise prices after 10 sales — you won't lose as many customers as you fear
Cheap prices signal cheap quality

Stop undercharging. Your product is probably worth more than you think.

Full guide with templates and negotiation scripts (Japanese): masatoman.net

Auth for Indie Hackers 2026: Clerk vs Supabase Auth vs NextAuth v5

masato — Fri, 17 Jul 2026 08:10:58 +0000

TL;DR

Stop building your own auth. In 2026, pick one of these three:

Clerk — 30 lines of code, beautiful UI, 10,000 free MAU
Supabase Auth — DB-native, RLS integration, 50,000 free MAU
NextAuth v5 — OSS, full control, free forever

Why You Shouldn't Build Your Own Auth

Hashing passwords. Email verification. Password reset. Session management. OAuth. 2FA.

I tried to roll my own. Spent 3 days. Gave up. Switched to Supabase Auth. Done in 30 minutes.

Your time is the one resource you can't scale. Don't waste it on problems that are 100% solved.

1. Clerk — Fastest to Ship

// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs';

export default function RootLayout({ children }) {
  return (
    <ClerkProvider>
      <html>{children}</html>
    </ClerkProvider>
  );
}

// app/sign-in/[[...sign-in]]/page.tsx
import { SignIn } from '@clerk/nextjs';
export default () => <SignIn />;

Ship in 10 minutes. Beautiful default UI. Organizations built-in for B2B SaaS.

Free tier: 10,000 MAU. Pro: $25/month.

2. Supabase Auth — Best for SaaS

import { createClient } from '@supabase/supabase-js';

export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

// Sign up
await supabase.auth.signUp({ email, password });

// OAuth
await supabase.auth.signInWithOAuth({ provider: 'google' });

UI is your job (or use @supabase/auth-ui-react).

Killer feature: Row Level Security. Gate paid features with SQL policies:

CREATE POLICY "paid_users_only" ON premium_feature
  FOR SELECT USING (
    EXISTS (
      SELECT 1 FROM subscriptions
      WHERE user_id = auth.uid() AND status = 'active'
    )
  );

Free tier: 50,000 MAU. Pro: $25/month (includes DB).

3. NextAuth v5 — Full Control

import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';

export const { auth, handlers, signIn, signOut } = NextAuth({
  providers: [Google],
  session: { strategy: 'jwt' }
});

20+ providers. Your DB. Your rules.

Free tier: Infinite (OSS). You pay for the DB separately.

Decision Flowchart

Building a SaaS with subscriptions?
  YES → Supabase Auth (RLS + Stripe = 🔥)
  NO  → Does UI polish matter more than control?
         YES → Clerk
         NO  → NextAuth

Vendor Lock-in

Service	Lock-in	Migration cost
Clerk	High	All users must re-register
Supabase Auth	Medium	Rewrite auth layer
NextAuth	Low	Swap providers freely

For indie devs, high lock-in is fine early on. Shipping > optimizing.

Monetization Path

Auth is just the beginning. The real play:

User signs up (auth)
    ↓
Free tier (RLS gate open)
    ↓
Hits a limit / wants premium (Stripe Checkout)
    ↓
RLS gate opens for paid features
    ↓
💰

At ~100 signups → 10 paying users × $5/month = $50/month. Realistic starting point.

Full guide (Japanese)

For detailed pricing, code comparisons, and revenue simulation, see the full guide on masatoman.net (Japanese).

How to Build a Secure Paywall with Supabase RLS — Patterns and Pitfalls

masato — Mon, 04 May 2026 11:57:06 +0000

Why RLS Is the Core of Any Paywall

The scariest scenario for a paid content service:

Someone who hasn't paid can see your content.

If you control access with if (purchased) { showContent() } on the client side, an attacker can bypass it by disabling JavaScript or hitting your API directly.

Even if you check on the server, accidentally exposing an API that fetches all users' purchase history will sink you.

Supabase Row Level Security (RLS) solves this at the database layer.

The database itself decides "this user can/cannot see this row" — so application-level bugs can't bypass it.

I use RLS on this blog's paid articles. Even if there's a bug in the Next.js access control logic, the database layer blocks it. Defense in depth.

What you'll learn:

RLS concepts and 2-layer defense design
RLS policy design for purchase history tables
When to use Service Role Key vs. Anon Key
How to bypass RLS correctly from Webhooks
N+1-safe purchase check patterns
Efficient RLS queries in Server Components

RLS Basics: Row-Level Access Control

Normal table permissions grant access to the entire table:

GRANT SELECT ON article_purchases TO authenticated;

This lets every authenticated user read everyone's purchase history.

RLS lets you write SQL that defines which rows a user can see:

ALTER TABLE article_purchases ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can view own purchases"
  ON article_purchases
  FOR SELECT
  USING (auth.uid() = user_id);

Now every query through Supabase automatically gets WHERE user_id = 'current_user_id' appended. Trying to fetch another user's purchases returns an empty result.

Design Pattern: Purchase History Table RLS

Base Table Definition

CREATE TABLE article_purchases (
  id TEXT PRIMARY KEY,                    -- Stripe Checkout Session ID
  user_id UUID REFERENCES auth.users(id),
  customer_email TEXT,
  article_slug TEXT NOT NULL,
  amount INTEGER NOT NULL DEFAULT 0,
  currency TEXT NOT NULL DEFAULT 'usd',
  status TEXT NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Layered RLS Policies

Step 1: Enable RLS

ALTER TABLE article_purchases ENABLE ROW LEVEL SECURITY;

With RLS enabled but no policies defined, the default is deny all.

Step 2: SELECT policy

CREATE POLICY "Users can view own purchases"
  ON article_purchases
  FOR SELECT
  USING (auth.uid() = user_id);

Users can only read their own purchase history.

Step 3: Intentionally no INSERT/UPDATE policies

-- Do NOT create INSERT or UPDATE policies
-- This rejects all writes from the Anon Key

Design decision: Purchase records must never be written by the client. They're written via Webhook using the Service Role Key.

Using the Service Role Key Correctly

Anon Key vs. Service Role Key

Key Type	RLS	Use Case
Anon Key	Applied	Client-side, authenticated user access
Service Role Key	Bypassed	Server-side, Webhooks, admin operations

The Service Role Key completely ignores RLS. Never expose it to the client.

Writing from a Webhook

// lib/supabase/server.ts
export async function createAdminClient() {
  const cookieStore = await cookies();
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!,  // ← Service Role Key
    {
      cookies: {
        getAll() { return cookieStore.getAll(); },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {}
        },
      },
    }
  );
}

Inside your Webhook handler, use createAdminClient():

// app/api/webhooks/stripe/route.ts
const supabase = await createAdminClient();

await supabase.from("article_purchases").upsert({
  id: session.id,
  user_id: session.metadata?.user_id,
  article_slug: session.metadata?.article_slug,
  status: "completed",
});

This bypasses RLS and writes the record.

Critical Pitfall: Service Role Key Leakage

Any environment variable prefixed with NEXT_PUBLIC_ gets bundled into client JavaScript.

❌ Never do this:

NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=eyJ...

✅ Correct:

SUPABASE_SERVICE_ROLE_KEY=eyJ...

Leaking the Service Role Key gives anyone full database access with no restrictions.

Purchase Check Implementation

Basic Pattern in a Server Component

// Article page (Server Component)
const supabase = await createClient();  // ← Anon Key (RLS applied)
const { data: { user } } = await supabase.auth.getUser();

if (!user) {
  return <Paywall />;
}

const { data: purchase } = await supabase
  .from('article_purchases')
  .select('id')
  .eq('user_id', user.id)
  .eq('article_slug', slug)
  .eq('status', 'completed')
  .single();

if (!purchase) {
  return <Paywall />;
}

return <FullArticle />;

Key points:

createClient() uses the Anon Key → RLS is applied
Explicitly write eq('user_id', user.id) (RLS handles it, but explicit is faster)
.single() for existence check

Avoiding N+1 Queries

When showing a list of paid articles with "purchased" badges, you might be tempted to query each article individually.

❌ Bad (N+1):

const articles = getAllArticles();
const purchased = await Promise.all(
  articles.map(a =>
    supabase.from('article_purchases')
      .select('id')
      .eq('article_slug', a.slug)
      .single()
  )
);

This fires one query per article.

✅ Good (1 query):

const articles = getAllArticles();
const slugs = articles.filter(a => a.frontmatter.premium).map(a => a.slug);

const { data: purchases } = await supabase
  .from('article_purchases')
  .select('article_slug')
  .in('article_slug', slugs)
  .eq('status', 'completed');

const purchasedSet = new Set(purchases?.map(p => p.article_slug) ?? []);

// Use purchasedSet.has(slug) in your articles.map

One query with IN, O(1) lookup with Set.

Index Design

Purchase checks run on every article page load. Without proper indexes, queries slow down as purchases grow.

Recommended Index

-- Composite partial index on user_id + article_slug
CREATE INDEX idx_article_purchases_user_slug
  ON article_purchases(user_id, article_slug)
  WHERE status = 'completed';

Why:

Composite index speeds up eq('user_id', x).eq('article_slug', y)
Partial index (WHERE status = 'completed') excludes pending purchases, reducing index size

Verify with EXPLAIN

EXPLAIN ANALYZE
SELECT id FROM article_purchases
WHERE user_id = 'xxx' AND article_slug = 'yyy' AND status = 'completed';

You want to see Index Scan using idx_article_purchases_user_slug. If you see Seq Scan, the index isn't being used.

Caching Strategy

Using Next.js `unstable_cache`

Hitting the DB on every request is wasteful. Purchase checks for the same user can be cached for a few seconds.

import { unstable_cache } from 'next/cache';

const checkPurchase = unstable_cache(
  async (userId: string, slug: string) => {
    const supabase = await createClient();
    const { data } = await supabase
      .from('article_purchases')
      .select('id')
      .eq('user_id', userId)
      .eq('article_slug', slug)
      .eq('status', 'completed')
      .single();
    return !!data;
  },
  ['article-purchase-check'],
  { revalidate: 60, tags: ['article-purchase'] }  // 60s cache
);

Call revalidateTag('article-purchase') on purchase completion to invalidate immediately.

Testing RLS

Role Switching in Supabase SQL Editor

-- Run query as authenticated user A
SET LOCAL ROLE authenticated;
SET LOCAL request.jwt.claim.sub = 'user-A-uuid';

SELECT * FROM article_purchases;
-- → Only rows with user_id = 'user-A-uuid' appear

Verify with curl

# Try to fetch another user's purchases with Anon Key
curl "https://xxx.supabase.co/rest/v1/article_purchases?user_id=eq.OTHER_USER_ID" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer USER_A_JWT"
# → []

If RLS is working, another user's data returns empty.

Production Checklist

[ ] ALTER TABLE ... ENABLE ROW LEVEL SECURITY on all tables
[ ] SELECT policies defined with minimum permissions
[ ] No INSERT/UPDATE/DELETE policies (or strictly restricted)
[ ] Service Role Key stored without NEXT_PUBLIC_ prefix
[ ] Service Role Key only used server-side (API Routes, Server Actions, Webhooks)
[ ] Composite + partial index created for purchase checks
[ ] Visually confirm RLS is enabled on all tables in Supabase Dashboard → Policies tab

Summary

RLS is a mindset shift: defense at the database layer.

Even if application-layer checks are bypassed, the database stops it. Defense in depth — code bugs and misconfigurations don't leak data.

If you're handling paid content, RLS isn't "nice to have" — it's mandatory.

The design principles:

Default deny: Enable RLS first, then add minimum policies
Writes via Service Role Key: Never let clients write purchase records
Don't forget indexes: 80% of slow RLS queries are missing indexes

Implement this and your "non-paying users seeing paid content" risk drops to near zero.

Building a Next.js + Supabase + Stripe SaaS from scratch? I've packaged this RLS pattern — along with auth, payments, and subscription management — into LaunchKit, a production-ready boilerplate for indie developers.

Copy-Paste Ready: Auto-Export GA4 + Search Console Data with TypeScript

masato — Thu, 09 Apr 2026 17:02:33 +0000

Still manually exporting CSVs from GA4 and Search Console?

TL;DR: Two TypeScript files + GitHub Actions = fully automated weekly data export. Service Account setup takes 15 minutes, code is copy-paste ready.

Architecture

GitHub Actions (weekly cron)
  ├── search_console_tracker.ts → search-console-latest.csv
  └── ga4_tracker.ts            → ga4-pages-latest.csv
                                  ga4-acquisition-latest.csv

Prerequisites (15 min one-time setup)

Create a Google Cloud project
Enable Search Console API + Google Analytics Data API
Create a Service Account → download JSON key
Add the Service Account to Search Console ("Restricted") and GA4 ("Viewer")

Search Console Tracker

import { google } from "googleapis";
import { writeFileSync, mkdirSync, existsSync } from "fs";

const SERVICE_ACCOUNT_JSON = process.env.GOOGLE_SERVICE_ACCOUNT_JSON ?? "";
const SITE_URL = process.env.SEARCH_CONSOLE_SITE_URL ?? "";
const OUTPUT_DIR = process.env.ANALYTICS_OUTPUT_DIR || "./analytics";

function getClient() {
  const credentials = JSON.parse(SERVICE_ACCOUNT_JSON);
  const auth = new google.auth.GoogleAuth({
    credentials,
    scopes: ["https://www.googleapis.com/auth/webmasters.readonly"],
  });
  return google.searchconsole({ version: "v1", auth });
}

async function main() {
  const client = getClient();
  const now = new Date();
  const endDate = new Date(now.getTime() - 3 * 86400000); // 3 days ago (data lag)
  const startDate = new Date(endDate.getTime() - 28 * 86400000);
  const fmt = (d: Date) => d.toISOString().split("T")[0];

  const res = await client.searchanalytics.query({
    siteUrl: SITE_URL,
    requestBody: {
      startDate: fmt(startDate),
      endDate: fmt(endDate),
      dimensions: ["query"],
      rowLimit: 500,
    },
  });

  const rows = res.data.rows ?? [];
  if (!existsSync(OUTPUT_DIR)) mkdirSync(OUTPUT_DIR, { recursive: true });

  const csv = [
    "Query,Clicks,Impressions,CTR,Position",
    ...rows.map((r) =>
      `"${(r.keys?.[0] ?? "").replace(/"/g, '""')}",${r.clicks},${r.impressions},${((r.ctr ?? 0) * 100).toFixed(2)}%,${(r.position ?? 0).toFixed(1)}`
    ),
  ].join("\n");

  writeFileSync(`${OUTPUT_DIR}/search-console-latest.csv`, csv, "utf-8");
  console.log(`Saved ${rows.length} queries`);
}

main();

GA4 Tracker

import { google } from "googleapis";
import { writeFileSync, mkdirSync, existsSync } from "fs";

const SERVICE_ACCOUNT_JSON = process.env.GOOGLE_SERVICE_ACCOUNT_JSON ?? "";
const PROPERTY_ID = process.env.GA4_PROPERTY_ID ?? "";
const OUTPUT_DIR = process.env.ANALYTICS_OUTPUT_DIR || "./analytics";

function getClient() {
  const credentials = JSON.parse(SERVICE_ACCOUNT_JSON);
  const auth = new google.auth.GoogleAuth({
    credentials,
    scopes: ["https://www.googleapis.com/auth/analytics.readonly"],
  });
  return google.analyticsdata({ version: "v1beta", auth });
}

async function main() {
  const client = getClient();
  if (!existsSync(OUTPUT_DIR)) mkdirSync(OUTPUT_DIR, { recursive: true });

  const res = await client.properties.runReport({
    property: `properties/${PROPERTY_ID}`,
    requestBody: {
      dateRanges: [{ startDate: "28daysAgo", endDate: "yesterday" }],
      dimensions: [{ name: "pagePath" }],
      metrics: [
        { name: "screenPageViews" },
        { name: "averageSessionDuration" },
        { name: "bounceRate" },
      ],
      orderBys: [{ metric: { metricName: "screenPageViews" }, desc: true }],
      limit: 100,
    },
  });

  const rows = res.data.rows ?? [];
  const csv = [
    "Page path,Views,Avg engagement time (sec),Bounce rate",
    ...rows.map((r) => {
      const path = r.dimensionValues?.[0]?.value ?? "";
      const views = r.metricValues?.[0]?.value ?? "0";
      const time = parseFloat(r.metricValues?.[1]?.value ?? "0").toFixed(1);
      const bounce = (parseFloat(r.metricValues?.[2]?.value ?? "0") * 100).toFixed(1);
      return `"${path}",${views},${time},${bounce}%`;
    }),
  ].join("\n");

  writeFileSync(`${OUTPUT_DIR}/ga4-pages-latest.csv`, csv, "utf-8");
  console.log(`Pages: ${rows.length} rows`);
}

main();

GitHub Actions

name: Analytics Tracker
on:
  schedule:
    - cron: '0 1 * * 1'  # Every Monday
  workflow_dispatch:
permissions:
  contents: write
jobs:
  track:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci || npm install
      - run: mkdir -p analytics-output
      - name: Search Console
        env:
          GOOGLE_SERVICE_ACCOUNT_JSON: ${{ secrets.GOOGLE_SERVICE_ACCOUNT_JSON }}
          SEARCH_CONSOLE_SITE_URL: https://your-site.com
          ANALYTICS_OUTPUT_DIR: ./analytics-output
        run: npx tsx search_console_tracker.ts
      - name: GA4
        env:
          GOOGLE_SERVICE_ACCOUNT_JSON: ${{ secrets.GOOGLE_SERVICE_ACCOUNT_JSON }}
          GA4_PROPERTY_ID: ${{ secrets.GA4_PROPERTY_ID }}
          ANALYTICS_OUTPUT_DIR: ./analytics-output
        run: npx tsx ga4_tracker.ts
      - run: |
          git config user.name "bot"
          git config user.email "bot@example.com"
          git add analytics-output/*.csv
          git diff --cached --quiet || git commit -m "data: update analytics"
          git push

Dependencies

npm install googleapis tsx

Bonus: Feed It to AI

Once CSVs auto-update, you can ask Claude Code:

"Read search-console-latest.csv and list keywords with high clicks but ranking below position 10."

"Find pages with high PV but low engagement time."

Automated data + AI analysis = SEO on autopilot.

Summary

Step	Time
Service Account setup	15 min (one-time)
Copy-paste code	2 min
GitHub Actions runs weekly	0 min

No more manual exports.

I Almost Leaked Session Cookies to GitHub — Here's How I Made It Impossible

masato — Thu, 09 Apr 2026 17:02:24 +0000

Have you ever pushed to GitHub and thought, "Wait, did I just commit something sensitive?"

TL;DR: .gitignore alone won't save you. A pre-commit hook that scans for secret patterns will physically prevent accidental leaks. Setup takes 3 minutes.

What Happened

I run 11 AI agents for automated SNS operations. One agent saved browser session cookies to a JSON file for auto-posting to a blogging platform:

{
  "cookies": [
    {
      "name": "_session_v5",
      "value": "626f63e8bc9a23c20a455bb4...",
      "httpOnly": true,
      "secure": true
    }
  ]
}

This file wasn't in .gitignore. I caught it in git status right before pushing.

Why .gitignore Isn't Enough

.gitignore only blocks files you already know about. It can't protect against:

Credentials generated by tools at runtime
Downloaded Service Account JSON keys
Auth state files created by automation scripts

The Fix: Pre-commit Hook

Save this as .git/hooks/pre-commit:

#!/bin/bash
BLOCKED=0
FILES=$(git diff --cached --name-only --diff-filter=ACM)

if [ -z "$FILES" ]; then exit 0; fi

# Dangerous filename patterns
for FILE in $FILES; do
  if echo "$FILE" | grep -qE "\.pem$|\.key$|\.p12$|credentials\.json|service.account.*\.json|client_secret.*\.json|token\.json|state\.json|_cookies\.json|\.env$|\.env\."; then
    echo "BLOCKED: $FILE (dangerous filename)"
    BLOCKED=1
  fi
done

# Secret content patterns
for FILE in $FILES; do
  if [ ! -f "$FILE" ]; then continue; fi
  if file "$FILE" 2>/dev/null | grep -q "binary"; then continue; fi
  if git diff --cached -- "$FILE" | grep -qE "PRIVATE KEY|BEGIN.*KEY|sk_live_|sk_test_|ghp_[a-zA-Z0-9]{36}|\"type\":.*\"service_account\""; then
    echo "BLOCKED: $FILE contains secret pattern"
    BLOCKED=1
  fi
done

if [ $BLOCKED -ne 0 ]; then
  echo "Commit blocked. Potential secrets detected."
  echo "To override: git commit --no-verify"
  exit 1
fi
exit 0

chmod +x .git/hooks/pre-commit

Test It

echo 'sk_live_fake1234567890abcdef' > test-leak.txt
git add test-leak.txt
git commit -m "test"
# → BLOCKED: test-leak.txt contains secret pattern

Commit is rejected. Crisis averted.

Also: Harden Your .gitignore

*.pem
*.key
*.p12
*-credentials.json
service-account*.json
client_secret*.json
token.json
credentials.json
.env
.env.*
*_cookies.json

Summary

Layer	What it does	Setup time
.gitignore	Blocks known patterns	1 min
Pre-commit hook	Detects unknown patterns, blocks commit	2 min
Total	Two-layer protection	3 min