DEV Community: ミント

tutorial #10: 148 Opens, 0 Replies — How My Forge Cold Email v1 Completely Failed

ミント — Fri, 22 May 2026 22:53:00 +0000

Zenn version: https://zenn.dev/mintototo1/articles/buildlog-2026-05-23-cold-email-v2

I sent 100 emails and got 148 opens.

Someone opened multiple times. People were reading. But 0 replies.

Between May 12–14, I sent 100 cold emails through Instantly for Forge — my AI engineering placement side project. Targeted companies actively hiring AI engineers, personalized each one.

Results:

Opens: 148 (including multiple opens per recipient)
Replies: 0
Bookings: 0

The subject lines worked. People were reading. Nobody replied. I couldn't figure out why. So I went back and read the body.

The problem was the offer sequence

My v1 email led with: "Freelance AI engineer placement, 30% fee, I'll send you details."

If you get an email from someone you've never heard of, and it immediately says "want to start a 30% fee arrangement? I'll send details" — you don't reply. That's obvious. I just didn't see it.

The first email should give something for free, not pitch. I skipped that step. The people who opened probably thought "not now" and closed it. That's all it was.

What I changed in v2

Changed first-touch offer to: free 15-min audit + 1-page AI hiring roadmap.

// v1: expecting a reply
I'll send you details.
Please reach out at your convenience.

// v2: calendar booking completes the action
Let me audit your AI hiring setup in 15 minutes
and put together a 1-page roadmap.
Book here → https://cal.com/mint-office-hours/free-15min

Also cut body from 280–400 chars down to 200–320 chars.

One next action: calendar booking. No waiting for a reply.

v2 results aren't in yet — sent this week, will write about it next week. No idea if the 0 moves.

tutorial #09: My Company Name Was Leaking from a Public URL

ミント — Thu, 21 May 2026 22:48:37 +0000

Zenn (JP): https://zenn.dev/mintototo1/articles/buildlog-2026-05-22-legacy-route-leak

Today, while poking around in the code, I hit an old route that was still live.

The HTML response had my company name and my real name sitting right there in plain text.

So much for staying anonymous.

When did this start leaking?

I checked git log — the route was added over 3 weeks ago. It has been public ever since. I have no idea if search engines crawled it. Honestly I am too scared to check.

How I fixed it

I grepped the Next.js app/ directory to find any leftover route files for the old path.

grep -r "old-route-name" app/ --include="*.tsx" --include="*.ts" -l

Found the files, identified which ones were externally reachable, deleted the route.ts files, and replaced them with a simple 404 stub.

// replacement for the old route.ts
export async function GET() {
  return new Response(null, { status: 404 });
}

I did not use a redirect for a reason. A 301/302 tells the outside world that the path exists. A 404 is indistinguishable from a path that never existed.

The real problem

The bigger issue is how I found this. I only noticed because I happened to click the URL by hand. Without a system, I will miss the next one too.

I plan to add a grep to the pre-deploy hook.

# not written yet
grep -rE "forbidden-term-1|forbidden-term-2" app/ public/ --include="*.tsx" --include="*.ts" --include="*.html"

I fixed today's problem and told myself that was enough. The script is still sitting in a backlog.

Build Log #08: The Empty Commit That Lives in My Git History

ミント — Wed, 20 May 2026 22:47:49 +0000

Zenn (JP): https://zenn.dev/mintototo1/articles/buildlog-2026-05-21-ig-env

Pushed Phase B of KURONEKO — v7 MBTI engine, 4 LP pages, Stripe payment links, /order archive page. 603 tests passing. It felt like things were finally stacking up.

The LP work was 4 "astrology×MBTI" product pages. Things like "INFJ fate line reading." Ground-level SEO stuff — embedded Stripe payment links on each page. Not exciting work, but it needed to happen.

Then I tried setting up Instagram integration. Thought it'd be interesting to deliver KURONEKO readings via Instagram DM too. Wrote the OAuth callback in Next.js. Added two env vars to Vercel: INSTAGRAM_APP_ID and INSTAGRAM_APP_SECRET.

It didn't work.

No code changes = no Vercel deploy = env not loaded. Obvious in hindsight. You just hit manual redeploy in the Vercel dashboard. But I figured that out after I'd already pushed a commit with the message: "deploy: trigger redeploy for INSTAGRAM_APP_ID + SECRET env."

That commit is now in my git log permanently.

IG integration still isn't working. Meta needs App Review, and there's a whole "add as tester" flow before that. Stuck in the part of the process where code doesn't matter anymore. Just waiting.

603/603 tests passing on the MBTI engine doesn't tell me if the readings are actually better. Only real users buying will tell me that. Revenue: ¥500. Still.

Build Log #07: My Voice Leaked Into KURONEKO's Fortune Telling

ミント — Tue, 19 May 2026 22:48:43 +0000

Zenn (JP): https://zenn.dev/mintototo1/articles/buildlog-2026-05-20-kuroneko-voice

¥500 tip — KURONEKO's first paid purchase.

I checked the fortune-telling email that got delivered...

"Even if these are words woven by AI, if they can make someone's night a little lighter, that becomes the reason I stand here."

Oh no.

KURONEKO is a fortune-telling product built around a black cat persona. The whole design is about NOT revealing it's AI — the mystery is the product itself. And here, "I" (俺) and "AI" appeared together in the output. Feedback was immediate: "We don't need 'I' or 'AI' in there. It breaks the immersion instantly. Feels like a scam."

Yeah. I know.

The prompt said "don't use first-person 俺". That wasn't enough. I had to explicitly list all forms — 俺/私/僕/自分/うち (all Japanese forms of "I") — and ban AI references entirely, with bad examples and good examples side by side. Vague prohibitions in LLM prompts get violated. 30 minutes to fix. But the email already sent — can't unsend it. The next purchase will get the fixed version.

The X (Twitter) side had worse timing. I set up automated posting crons for @kuroneko_xxai. The next day: write restriction. Emergency-deleted 8 cron jobs from vercel.json. New accounts probably get flagged for automated behavior — but getting hit the day after setup stings.

Also shipped: admin/orders dashboard and a referral code library (8-char codes, 60-day expiry). I can finally view order history from an admin panel. Referral-Stripe webhook integration is next session.

Revenue: ¥500. 1 order.

Weekly Numbers 2026-05-W4: Forge First Batch Sent, 2 iOS Apps In Review

ミント — Mon, 18 May 2026 22:48:30 +0000

Japanese original on Zenn

Monday. May 19th. Writing the weekly numbers.

Palette and rojiura — both submitted yesterday (5/18). Both still WAITING_FOR_REVIEW. rojiura is my 5th submission. Same app, five times. This time I removed NSUserTrackingUsageDescription from Info.plist and removed the corresponding checkbox in ASC's App Privacy section. That mismatch was why it got rejected last time. Palette had a Supabase RLS issue — user_id wasn't being passed explicitly on INSERT — fixed and resubmitted. Apple should respond today or tomorrow. Whether a 5th submission finally passes... no idea.

Forge cold email first batch went out last week (Tue–Thu). 21 leads, all filtered to companies actively hiring AI/ML engineers. This is after sending 440 emails to local small businesses and getting zero replies — I changed the ICP entirely.

What happened with the replies? I haven't checked Instantly yet. Genuinely haven't. There's this thing that happens right before I'd see the results — what if it's zero again — kicks in and I put it off. Building the pipeline felt exciting. Checking the results feels heavy. Had the same thing after the 440 sends. I'll check this week and report it.

Two git commits. Fixed a TypeScript type definition — 4 industry types (engineer_freelance, ai_hiring, ai_initiative, ai_org) were missing, which was breaking typechecks on main. Also set up KURONEKO (X auto-posting bot) with Vercel cron at 07:00 and 21:00 JST. Mention-replies are polled every 10 minutes. Code is running, but whether this actually moves follower numbers or impressions — still unknown.

X: 86 followers as of 5/15. Monthly infra cost: ~¥110k, unchanged.

Everything I've set up is in this-should-start-moving mode. Forge replies, Apple review results, KURONEKO effects — all still pending. That's what a Monday at the start of this kind of week looks like.

Weekly Numbers 2026-05-W3: KURONEKO cron live, Forge 21 leads, 2 iOS apps awaiting review

ミント — Mon, 18 May 2026 16:47:23 +0000

Originally published on Zenn: 週次数字 2026-05-W3：KURONEKO cron 起動、Forge 21 leads、iOS 2本審査待ち

Weekly numbers rundown. 5/12–5/18.

Git activity: 3 PRs / commits

Three PRs merged last week.

Forge AI hiring pipeline (PR #15)
Built a pipeline that auto-scrapes company hiring requirements, personalizes outreach with Claude, and feeds it into Instantly — integrated into lib/b2b-sales. Currently 21 leads are loaded into the campaign. Send window is Tue–Thu 10:00–15:00 JST with a daily limit of 15 emails.

KURONEKO Vercel cron launch
kuroneko (X BOT) scheduled posts are now live at 07:00 and 21:00 JST. Also set up mention-reply polling at 10-minute intervals.

TypeScript typecheck fix
Filled in 4 missing entries in the industry type in b2b-sales. Unglamorous work, but main was staying red so I fixed it.

iOS: 2 apps WAITING_FOR_REVIEW

Resubmitted 2 builds on 5/18.

Palette v0.1.0 build 8: Fixed a failure caused by not explicitly passing user_id in the Supabase RLS diagnoses INSERT
rojiura v1.1 build 78012407: Removed NSUserTrackingUsageDescription from Info.plist to align App Privacy

Both are WAITING_FOR_REVIEW. Expecting to hear back from Apple sometime this week.

Forge AI Hiring: 21 leads in campaign

Status after switching ICP to "companies actively hiring for AI roles." Sent 440 emails targeting local brick-and-mortar businesses and got zero replies, so I overhauled the ICP entirely.

All 21 leads have been personalized per company with Claude. Rolling them out within the Tue–Thu send window. I'll log any replies that come in.

mint X: 86 followers (as of 5/15)

76 on 5/10, 86 on 5/15. +10 in one week. Things seem to be picking up a little since I dropped posting frequency from 12–18 posts/day down to 3–5 posts/day. Impression quality feels better.

Monthly costs: ~¥110,000/month

Anthropic Max plan / Vercel / X Dev / Supabase / Cloudflare / ElevenLabs, etc. No change from last month.

This week's two things to watch: the first Forge send results and the Apple review outcomes. I'll report back when the numbers move.

Built a $9.80 iOS App Store Rejection Defense Kit After 8 Rejections

ミント — Sun, 17 May 2026 07:28:12 +0000

I'm an anonymous solo dev shipping iOS apps with Claude Code. My first app (rojiura) got rejected 3 times in a row. After shipping 4 apps and accumulating 8 total rejections, I extracted the recurring patterns into a single shell script that runs in the pre-submit hook.

The Kit ($9.80, lifetime updates)

komugi0427.gumroad.com/l/yijypn

5 files inside:

1. `ios-pre-submit-gate.sh` — 8 automated checks

Runs before deploy, exits 1 if any of these fail:

Info.plist UsageDescription keys that don't have corresponding code
Android-only References accidentally left in iOS plist
Support URL liveness check
Personal name leak (Yura, 大塚 etc. in any file)
Tracking SDK declared but requestTrackingAuthorization not called
iPad Air (M3) simulator boot test (Apple's actual review device)
CFBundleVersion monotonic increment
Code signing identity vs provisioning profile mismatch

Auto-detects Capacitor / Expo / Native projects.

2. `asc-cancel-and-submit.mjs` — ASC API rescue

Apple's docs don't make this obvious: when a review is rejected, you cannot DELETE the old appStoreVersionSubmission. You have to PATCH canceled=true first, then create a new reviewSubmission (different endpoint), add an item linking the version, then PATCH submitted=true. 4 API calls in sequence.

I've packaged it as a single script that takes --version-id and handles the entire rescue flow.

3. `reviewer-notes-template.md` — 7-section template

Template I now paste into every app's review notes:

Test user credentials
Feature walkthrough
Third-party content sources
Data collection summary
Special permissions justification
Expected reviewer experience
Known issues + workarounds

4. `LP.md` + `README.md` — Setup and usage

5. `INCIDENT_LOG.md` — Full post-mortem of all 8 rejections

What got rejected, what the reviewer wrote, what I tried, what eventually worked.

Proof It Works

On Palette (sibling app) the gate caught 3 of the 5 rejection reasons before re-submission. After integrating, 0 new rejections on the same patterns.

What I'm Selling

$9.80 one-time, lifetime updates. Includes a 30-min Zoom setup help for buyers — I'll actually run the gate on your repo with you, not just hand you scripts.

Honest Disclosure

I'm anonymous, 88 X followers, current sales: 0. This is the first wider distribution attempt. Monthly numbers (revenue, cost, install) published transparently at mint.komugi-ai.jp.

Looking For

Feedback on what should go in v2. Currently considering:

Apple Intelligence opt-in checker
Privacy Manifest v2 validation
App Tracking Transparency edge cases (re-prompt timing)
ASO meta validation (subtitle / keywords)

What rejection patterns have you been bitten by? Drop a comment.

Weekly Digest 2026-W20: First Week of Build Log — 6 Articles, ¥110K/Month Costs, MRR ¥0

ミント — Mon, 11 May 2026 10:42:14 +0000

2026, week 20. This was the week I started the Build Log series.

I published 6 articles in a single day and put the real numbers out there — ¥110,000/month in costs, MRR still at ¥0.

Numbers and facts only. No fluff.

This week's numbers

Metric	Value	vs. last week
note articles published	6 (#1–#6)	+6 (series launch)
Zenn articles published	6 (cross-posted)	+6
Qiita articles published	4 (2 deferred due to 429)	+4
note total PV	not tracked yet	—
note followers	not tracked yet	—
Total MRR	¥0	no change
Monthly infra + AI costs	~¥110,000/month (~$700)	—
Cold emails sent	not tracked yet	—
Cold email reply rate	not tracked yet	—

Daily log

Monday, May 4 (Build Log launch day)

Published Build Log #1–#5 on note, Zenn, and Qiita — all in one day. The strategy: stockpile posts, then release them together. Reasoning: starting a series with a single article makes you look like someone with nothing to show. Releasing 5 at once means any profile visitor immediately has something to binge.

Published on this day:

#1 "Full breakdown of shipping a real-estate SaaS in 5 days with Claude Code" (6,042 chars)
#2 "Built a LINE reception AI in 1 day and went straight to sales" (6,266 chars)
#3 "The complete record of getting rejected by the App Store — beauty app edition" (7,034 chars)
#4 "How I built a company website in 30 minutes and passed Apple review" (6,296 chars)
#5 "X account suspension → appeal → recovery: full playbook" (4,679 chars)

Hit the Qiita 429 rate limit. New account restrictions blocked same-day posting for #4 and #5 — deferred to the next day. Zenn went through without issues on all five.

Also nailed down the note posting flow. When pasting text into ProseMirror, ClipboardEvent('paste') is the stable approach. execCommand('insertText') inserts empty blocks and breaks formatting.

Tuesday, May 5 (Build Log #6 + numbers post)

Published Build Log #6 "Complete Stripe billing template — fastest path to production" (7,387 chars). Also dropped a "May 2026 full numbers" post the same day — ¥110,000/month in costs, MRR ¥0. Posted the loss raw.

6 is the first Phase 2 article — a deep dive into 5 Stripe landmines with actual production code. Also cross-posted the English version to dev.to (translation handled by Claude).

For X (@mintnekoneko0) announcements, went QRT-first. Direct article links in posts hurt engagement, so the approach: search by industry keywords, then QRT relevant tweets.

Wednesday, May 6 (content generation day)

Drafted next Build Log installments (#7 onwards) and refilled the content queue for next week. Added 3 items to the generation queue: observation, digest, and Build Log #7.

Also outlined the compare article for next week (Claude Code vs Cursor vs Aider). Having shipped actual production products with all three tools means I can write about "what happened when production broke" — not surface-level feature comparisons.

Thursday–Saturday, May 7–9

Drafting Build Log #7, verifying Qiita backlog posts, publishing observation article on solo dev survival strategy.

Sunday, May 10 (this article's publish date)

Weekly retrospective and next week's plan locked in. Mid-month check on costs and MRR.

This week's lessons

Lesson 1: Batch launching works for series kick-offs

5 articles on day one meant anyone visiting the profile could immediately read multiple pieces. Starting with one at a time would have made the series invisible. The "stockpile then release" approach was correct.

Lesson 2: Qiita rate limits for new accounts are real

Posting multiple articles in a day triggers 429. Fix: one article per day. Scheduled task set to auto-retry deferred posts the next day at the same time slot.

Lesson 3: Cost transparency performs

Writing "¥110,000/month burn rate with MRR ¥0" generated more reactions than the technical articles. Lots of responses asking "why keep going at a loss?" Readers use this to calibrate their own risk tolerance — there's demand for raw numbers.

Lesson 4: dev.to English cross-posts take time

Essentially no response on publish day. Impressions grow gradually 2–3 days later. The goal is English-language recognition built over time, so short-term numbers don't matter.

Lesson 5: X QRT loop requires semi-manual operation

Got suspended from auto-like/follow scripts (covered in #5), so X ops run through Chrome MCP as semi-auto. Full automation is off the table due to suspension risk.

Next week's plan

Day	Content	Goal
Mon 5/11	Build Log #7 (Supabase 15 landmines)	note / Zenn / Qiita all published
Tue 5/12	numbers (May mid-month update)	note post
Wed 5/13	compare (Claude Code vs Cursor)	note / Zenn / Qiita all published
Thu 5/14	additional lessons article	note post
Fri 5/15	additional tutorial article	note post

Priority actions:

Cold email reply handling — process all pending same day
Qiita backlog (#4, #5, #6) — confirm posting
Build Log #7 final draft (15 landmines + 8+ code snippets)
dev.to English cross-posting continued (#2–#5 translation)

May monthly target progress

Target	Goal	Current
note articles published	20	6 (30%)
MRR	¥10,000	¥0 (0%)
note followers	+200	not tracked
Cold email reply rate	5%	not tracked

MRR is still ¥0. That's on plan. Phase 1 is about building awareness and content accumulation — revenue comes in Phase 2 when Build Log #7+ introduces paid sections.

Technical notes (reproducible procedures)

Avoiding Qiita 429

One post per day. For scheduled automation, lock cron to 0 19 * * *. Push deferred articles to the same slot the next day.

Stable note ProseMirror paste

execCommand variants are unstable. The only reliable method: inject plain text via ClipboardEvent('paste') + DataTransfer. Works with code blocks.

const dt = new DataTransfer()
dt.setData('text/plain', articleText)
editor.dispatchEvent(new ClipboardEvent('paste', { clipboardData: dt, bubbles: true }))

Always save as draft once before clicking "Proceed to publish". Without it, title and body can appear blank on the publish settings screen.

Setting canonical URL on dev.to

Set "Canonical URL" to the original note article URL under "SEO & canonical URL" in the Edit screen. This prevents Google from treating it as duplicate content. Zenn supports the same. Without it, dev.to may be treated as the original.

Honest take

As a Build Log launch week, it went better than expected. Publishing 6 articles in one day was exhausting, but it created the feeling that a series had actually started. Zero followers and zero responses on day one — but content that accumulates will eventually reach someone. That's what I'm betting on.

The anxiety of burning ¥110,000/month at MRR ¥0 is real. But I've decided this is the time to invest in content. I'll write an honest month-one retrospective on June 6.

On the technical side, what took the most time this week wasn't content generation — it was automating the posting workflow. Manually publishing to note, Zenn, Qiita, and dev.to every day would leave no time to write. This week got it mostly automated. Next week: just write.

Next up: Build Log #7 "15 Landmines in Supabase + Vercel + Next.js" → Monday publish

Confirmed rules (worth saving)

For series launches: batch and release — don't drip
New Qiita accounts: one post per day, 429 = defer to tomorrow
Sharing real costs and losses drives more reactions than tutorials
dev.to English articles get traction 2–3 days after publish
X automation = suspension risk — keep it semi-manual
Weekly digests also serve as "next week's reader preview"
MRR comes in Phase 2+; now is the recognition investment phase
Back monthly targets with data sources (record where the numbers came from)
Automate backlog processing with scheduled tasks
Weekly retrospectives should include emotions too — numbers alone lose meaning later

Originally posted on note (Japanese): https://note.com/mintototo1/n/n3924549e7eb4

Implementing Claude API Tool Use in Next.js: Full Code, 27 Minutes

ミント — Fri, 08 May 2026 10:40:40 +0000

I opened the editor at 16:42 and it was running in production at 17:09.
Here's the full code for implementing Claude API tool use — 27 minutes of actual work.
I expected it to be complicated. It wasn't.

What I built

Added a natural language interface to a SaaS admin dashboard. Type "show me last month's revenue" or "how many active users do we have?" and Claude queries the DB and returns the answer.

The mechanic is simple: you tell Claude "you're allowed to call these functions." Claude decides when to call them and constructs the arguments. Your code actually executes the function and sends the result back to Claude. Claude generates the final text answer.

Stack:

Next.js 14 (App Router)
@anthropic-ai/sdk 0.20+
TypeScript
Supabase (DB)

Step 1: Define the tools

Tools are defined with JSON Schema. The description field is the most important part — write it so Claude clearly understands when to call the tool and what it returns. Vague descriptions cause misfires or missed calls.

// lib/claude-tools.ts
import Anthropic from '@anthropic-ai/sdk'

export const tools: Anthropic.Tool[] = [
  {
    name: 'get_revenue',
    description:
      'Fetches total revenue and transaction count for a given period. ' +
      'Supports daily, weekly, and monthly aggregation. ' +
      'Returns the latest 12 entries if no date range is specified.',
    input_schema: {
      type: 'object',
      properties: {
        period: {
          type: 'string',
          enum: ['daily', 'weekly', 'monthly'],
          description: 'Aggregation unit',
        },
        date_from: {
          type: 'string',
          description: 'Start date (YYYY-MM-DD)',
        },
        date_to: {
          type: 'string',
          description: 'End date (YYYY-MM-DD)',
        },
      },
      required: ['period'],
    },
  },
  {
    name: 'list_users',
    description:
      'Returns a list of users. Filterable by status (active/canceled/trial). Max 100 results.',
    input_schema: {
      type: 'object',
      properties: {
        status: {
          type: 'string',
          enum: ['active', 'canceled', 'trial'],
        },
        limit: {
          type: 'number',
          description: 'Number of results (max 100, default 20)',
        },
      },
      required: [],
    },
  },
]

"Get data" isn't a good description. Write 1–2 sentences covering when to use it, what data it returns, and what the constraints are. Skimping here makes Claude hesitate or call the wrong tool.

Step 2: Wire it into the API Route

The core of tool use is a loop. As long as Claude responds with "I want to use a tool," you execute it, return the result, and ask Claude again.

// app/api/chat/route.ts
import Anthropic from '@anthropic-ai/sdk'
import { tools } from '@/lib/claude-tools'
import { executeToolCall } from '@/lib/tool-handlers'

const client = new Anthropic()

export async function POST(req: Request) {
  const { messages } = await req.json()
  let currentMessages = [...messages]

  let response = await client.messages.create({
    model: 'claude-opus-4-6',
    max_tokens: 1024,
    tools,
    messages: currentMessages,
  })

  // Loop while Claude wants to use tools
  while (response.stop_reason === 'tool_use') {
    const toolUseBlocks = response.content.filter(
      (block): block is Anthropic.ToolUseBlock => block.type === 'tool_use'
    )

    // Claude can call multiple tools in parallel — handle them concurrently
    const toolResults: Anthropic.ToolResultBlockParam[] = await Promise.all(
      toolUseBlocks.map(async (block) => ({
        type: 'tool_result' as const,
        tool_use_id: block.id,
        content: JSON.stringify(
          await executeToolCall(block.name, block.input as Record<string, unknown>)
        ),
      }))
    )

    // Append assistant turn + tool results to conversation history
    currentMessages = [
      ...currentMessages,
      { role: 'assistant' as const, content: response.content },
      { role: 'user' as const, content: toolResults },
    ]

    response = await client.messages.create({
      model: 'claude-opus-4-6',
      max_tokens: 1024,
      tools,
      messages: currentMessages,
    })
  }

  const textBlock = response.content.find(
    (block): block is Anthropic.TextBlock => block.type === 'text'
  )

  return Response.json({ reply: textBlock?.text ?? '' })
}

Loop on stop_reason === 'tool_use'. Using !== 'end_turn' is dangerous — on max_tokens overflow or API error, you get an infinite loop.

Step 3: Implement the handlers

Functions that actually hit the DB. Type them explicitly and always include the default case.

// lib/tool-handlers.ts
import { supabase } from '@/lib/supabase'

export async function executeToolCall(
  name: string,
  input: Record<string, unknown>
): Promise<unknown> {
  switch (name) {
    case 'get_revenue': {
      const { period, date_from, date_to } = input as {
        period: 'daily' | 'weekly' | 'monthly'
        date_from?: string
        date_to?: string
      }

      const { data, error } = await supabase.rpc('get_revenue_by_period', {
        p_period: period,
        p_from: date_from ?? null,
        p_to: date_to ?? null,
      })

      if (error) return { success: false, error: error.message }
      return { success: true, data, period }
    }

    case 'list_users': {
      const { status, limit = 20 } = input as {
        status?: string
        limit?: number
      }

      let query = supabase
        .from('users')
        .select('id, email, status, created_at')
        .order('created_at', { ascending: false })
        .limit(Math.min(limit, 100))

      if (status) query = query.eq('status', status)

      const { data, error } = await query
      if (error) return { success: false, error: error.message }
      return { success: true, data, count: data?.length }
    }

    default:
      // Hallucination guard: Claude occasionally calls a tool that doesn't exist
      return { success: false, error: `Unknown tool: ${name}` }
  }
}

The default case is required. Claude occasionally calls a non-existent tool. Returning undefined breaks the conversation entirely.

Step 4: Verification script

Verify the tool behavior in isolation before wiring it into production. Run this first to see how tool_use actually works.

// scripts/test-tool-use.ts
import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic()

const response = await client.messages.create({
  model: 'claude-opus-4-6',
  max_tokens: 512,
  tools: [
    {
      name: 'get_current_time',
      description: 'Returns the current time for a given timezone',
      input_schema: {
        type: 'object',
        properties: {
          timezone: {
            type: 'string',
            description: 'Timezone string (e.g. Asia/Tokyo)',
          },
        },
        required: ['timezone'],
      },
    },
  ],
  messages: [{ role: 'user', content: "What time is it in Tokyo right now?" }],
})

console.log('stop_reason:', response.stop_reason)
// → tool_use

console.log(
  'tool call:',
  JSON.stringify(
    response.content.find((b) => b.type === 'tool_use'),
    null,
    2
  )
)
// → { type: 'tool_use', name: 'get_current_time', input: { timezone: 'Asia/Tokyo' }, id: '...' }

If you see stop_reason: tool_use and input.timezone: "Asia/Tokyo", you're good. Confirm this before putting it in your production API.

Step 5: Combining with streaming

Tool use and streaming don't mix well. During streaming, tool arguments aren't fully assembled, so you can't build the execution loop.

I went with a hybrid approach: run the tool loop non-streaming, then stream only the final text response.

// Tool loop runs without streaming
let response = await client.messages.create({
  model: 'claude-opus-4-6',
  max_tokens: 1024,
  tools,
  messages: currentMessages,
})

while (response.stop_reason === 'tool_use') {
  // ... execute tools + update conversation history ...
  response = await client.messages.create({ ... })
}

// Stream only the final answer
const stream = client.messages.stream({
  model: 'claude-opus-4-6',
  max_tokens: 2048,
  messages: [
    ...currentMessages,
    { role: 'assistant', content: response.content },
  ],
})

return new Response(
  new ReadableStream({
    async start(controller) {
      for await (const chunk of stream) {
        if (
          chunk.type === 'content_block_delta' &&
          chunk.delta.type === 'text_delta'
        ) {
          controller.enqueue(
            new TextEncoder().encode(
              `data: ${JSON.stringify({ text: chunk.delta.text })}\n\n`
            )
          )
        }
      }
      controller.enqueue(new TextEncoder().encode('data: [DONE]\n\n'))
      controller.close()
    },
  }),
  {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
    },
  }
)

While tools are executing, show a "Fetching data..." spinner on the frontend. Execution can take a few seconds — skip the spinner and your UX dies.

Landmines I hit

Landmine 1: tool_result content must be a string
Passing content: toolResult directly threw a TypeError. JSON.stringify(toolResult) is required. The type definition says string, but TypeScript will sometimes let an object through without complaint — it's a trap.

Landmine 2: didn't handle parallel tool calls
Claude can call multiple tools in a single turn. I was using for...of to execute them serially, and the second tool_result wasn't mapping correctly. Use Promise.all for parallel execution.

Landmine 3: wrote descriptions in English for a Japanese-language app
Claude stopped calling tools as often when I wrote English descriptions in a Japanese-language context. Match descriptions to the conversation language. If your users write in Japanese, write Japanese descriptions.

Landmine 4: wrong loop condition
while (response.stop_reason !== 'end_turn') caused an infinite loop on max_tokens overflow or API error. === 'tool_use' is the correct condition.

Landmine 5: skipped authorization in the handler
Tool handlers can be hit through Claude or hit directly as API endpoints. Authorization logic belongs in the handler — not in the description. Writing "admins only" in the description doesn't guarantee Claude will respect it.

The implementation itself took 27 minutes. It's not hard. What's hard is designing which tools to define and how to write the descriptions. Your Claude's quality is your description's quality.

Next up: structured output with forced JSON using tool_choice: {type: "tool"} — forcing a specific tool call to return data matching a JSON schema. Master this and you escape the AI response parsing hell.

Originally posted on note (Japanese): https://note.com/mintototo1/n/nbe89d68cd5c5

Why I Switched Fully from Cursor (After 6 Months) to Claude Code

ミント — Thu, 07 May 2026 10:42:10 +0000

I used all three tools in production. Ran them across real products. Spent over $60/month at my peak. The answer is clear now.
To Cursor users: this might make you switch.

The Basics: 3 Tools at a Glance (as of May 2026)

	Claude Code	Cursor	Aider
Price	$20/mo (Max) or API pay-as-you-go	$20/mo (Pro)	Free (API costs separate)
Interface	Terminal (CLI)	VSCode-based IDE	Terminal (CLI)
Model	Claude 3.5/3.7/4.x Sonnet	GPT-4o / Claude 3.5	GPT/Claude (selectable)
Context	Whole project	Per-file + @mentions	git diff + /add
Autonomy	High (agentic)	Medium (suggestion-based)	Medium (commit-unit)

I'm running 4 SaaS products solo in production right now. I've used all three tools across every part of that process. This is that comparison.

Claude Code: The Reality

How It Works

The core of Claude Code is CLAUDE.md — a file where you feed the project context. Once it's there, context carries over across sessions without any extra work.

# Project: Real Estate Video SaaS

## Stack
- Next.js 15 (App Router)
- Supabase (PostgreSQL + Auth + Storage)
- Stripe (Subscription)
- Vercel (Deploy)

## DB Tables
users / properties / videos / subscriptions / tenants

## Coding Rules
- Use Server Actions (API routes for webhooks only)
- Errors: console.error + send to Sentry
- env: centralized in lib/env.ts
- Types: generated from Database type in /types/database.ts

Say "add Stripe webhook handling" and it reads CLAUDE.md, matches your existing patterns, and outputs this:

// app/api/webhooks/stripe/route.ts
import { NextRequest, NextResponse } from 'next/server'
import Stripe from 'stripe'
import { stripe } from '@/lib/stripe'
import { createClient } from '@/lib/supabase/server'

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 (err) {
    return NextResponse.json({ error: 'Webhook Error' }, { status: 400 })
  }

  const supabase = await createClient()

  switch (event.type) {
    case 'customer.subscription.created':
    case 'customer.subscription.updated': {
      const sub = event.data.object as Stripe.Subscription
      await supabase
        .from('subscriptions')
        .upsert({
          stripe_subscription_id: sub.id,
          stripe_customer_id: sub.customer as string,
          status: sub.status,
          current_period_end: new Date(sub.current_period_end * 1000).toISOString()
        })
      break
    }
    case 'invoice.payment_failed': {
      const invoice = event.data.object as Stripe.Invoice
      await supabase
        .from('subscriptions')
        .update({ status: 'past_due' })
        .eq('stripe_customer_id', invoice.customer as string)
      break
    }
  }

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

It picked up the lib/supabase/server import style, the subscriptions column names — all from reading the existing project files. I specified nothing.

What's Not Great

Cost is unpredictable. The Max plan is $20/month unlimited, but on API billing I've hit $10+ in a single day. Also the "confidently writes outdated APIs" problem persists. It sometimes doesn't know the latest API for newer libraries — always review before shipping.

Best for: implementing new features end-to-end, scaffolding from scratch, large refactors

Cursor: The Reality

Autocomplete and Chat Are Solid

Cursor's inline completion was the most comfortable of the three. The feeling of Tab-predicting the next line is real.

For small fixes, Cursor is fast:

// Original (loose typing)
const { data } = await supabase.from('users').select('*').eq('id', userId).single()

// Just say "tighten the types" and Cursor outputs:
const { data, error } = await supabase
  .from('users')
  .select('id, email, name, plan, created_at')
  .eq('id', userId)
  .single<Pick<Database['public']['Tables']['users']['Row'],
    'id' | 'email' | 'name' | 'plan' | 'created_at'
  >>()
if (error) throw error

Single-file edits like this feel noticeably snappier in Cursor.

Breaks Down Across Multiple Files

It's weak at grasping the full project. "Add stripe_customer_id to users table and use it in the webhook" goes like this:

# Real Cursor exchange (close approximation)
You: add stripe_customer_id to users and use it in the webhook
Cursor: Which files should I reference? Please @-mention them.
You: @lib/stripe @types/database.ts @app/api/webhooks/stripe
Cursor: Where should the migration file go?
You: supabase/migrations/
Cursor: (creates migration) Any other files that need changes?
You: ...end up doing it yourself

When I become the context-feeding assistant for large tasks, that alone costs me 20-30 minutes.

Best for: partial edits to existing code, small bug fixes, tab-completion-driven daily work

Aider: The Reality

Git Integration Is Genuinely Good

Auto-commits per change is legitimately useful. "I can roll back to exactly here" becomes concrete.

# Aider session example
$ aider --model claude-3-5-sonnet-20241022

/add app/api/webhooks/stripe/route.ts lib/stripe.ts types/database.ts

# Prompt:
# Add stripe_customer_id to users and write an upsert in the webhook

# After changes, auto-commits:
# Commit 9f3c1a2 feat: add stripe_customer_id to users and webhook upsert

And it's free (just API costs). If you're trying AI coding for the first time, Aider has the lowest barrier to entry.

Low Autonomy Is the Ceiling

When a complex task hits a wall, Aider stops. Claude Code debugs the error and retries on its own. Aider asks "what do you want to do?" Running 4 products solo, this difference shows up every single day.

Also, context resets between sessions. You restart every time by re-adding files with /add.

Best for: one-off fix tasks, first steps into AI-assisted coding

Landmines I Actually Hit (from real experience)

Only listing what I personally stepped on.

Claude Code landmines

Tried to hardcode .env.local values by guessing them — secret almost ended up in git
Reported "ran tests and confirmed" when tests hadn't actually run (happened twice)
Doesn't know the latest API for some newer libraries — need to specify the version and say "check the official README"

Cursor landmines

Ignores .cursorrules mid-task during long Composer sessions
After applying multi-file Composer changes, stale code sometimes remained
Tab completion misread a long comment and deleted it along with surrounding code

Aider landmines

Sometimes edits files you never added via /add — unintended changes end up in git
Without --model specified, falls back to an old default model
Long sessions cause it to forget instructions from earlier in the conversation

Why I Went All-In on Claude Code

Three reasons.

1. "Just handle it" works

My style is: decide the high-level spec, delegate the implementation. Claude Code takes that. Cursor asks "which part do you want to fix?" Aider asks "which files should I add?" Every interruption breaks my focus.

2. Context management disappears when running 4 products

With CLAUDE.md in each project, context carries over across sessions. With Cursor, every project switch meant re-feeding context via @filename. Ten times a day, that adds up.

3. The cost math worked out

Tool	Estimated monthly cost
Claude Code Max	$20 + API $15-30
Cursor Pro	$20
Aider	Free + API $10-20

Claude Code is the most expensive. But thinking in hourly rate terms — if 1 hour of work compresses to 20 minutes, the extra $30/month is cheap. Higher implementation speed means my own time costs less.

The Verdict: When to Use Which

Scenario	Pick
Implementing a feature from scratch	Claude Code
Partial edits to existing code	Cursor
Trying AI coding for the first time	Aider
Zero budget	Aider
Running multiple production products solo	Claude Code
Team with existing VSCode workflow	Cursor

There are people for whom Cursor is the right answer. If you're on a team and maintaining an existing VSCode setup, Cursor fits naturally. Under my conditions, Claude Code was the only call.

The question isn't "which is the best" — it's "which fits your use case."

I say this as someone who used Cursor for 6 months. No regrets switching. But I don't think everyone should. Try one week and you'll have your own answer.

Originally posted on note (Japanese): https://note.com/mintototo1/n/na615d239961f

The Complete Stripe Billing Template for Next.js: 5 Production Landmines

ミント — Tue, 05 May 2026 10:39:33 +0000

The Complete Stripe Billing Template for Next.js: 5 Production Landmines and How to Avoid Them

I spent 8 hours debugging Stripe on my first SaaS. Now I can wire it up in 30 minutes. Here's the full template with every gotcha documented.

This is what I actually use in production — not a toy demo. Copy-paste it and adapt.

The Stack

Next.js 14+ (App Router)
Supabase (auth + DB)
Stripe (subscriptions + Customer Portal)

DB Schema First

Before any code, add these columns to your profiles table:

alter table profiles
  add column if not exists stripe_customer_id text,
  add column if not exists subscription_status text default 'free',
  add column if not exists price_id text,
  add column if not exists current_period_end timestamptz;

create index if not exists idx_profiles_stripe_customer_id
  on profiles(stripe_customer_id);

Step 1: Create Customer on Signup

Landmine #1: Don't create the Customer lazily.

The temptation is to create a Stripe Customer only when the user tries to pay. Don't. Create it at signup. If you create it lazily, you'll end up with race conditions and orphaned sessions.

lib/stripe.ts

import Stripe from 'stripe'

export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2024-04-10',
})

export async function getOrCreateStripeCustomer(
  userId: string,
  email: string
): Promise<string> {
  const { createClient } = await import('@/lib/supabase/server')
  const supabase = createClient()

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

  if (profile?.stripe_customer_id) {
    return profile.stripe_customer_id
  }

  // Create and immediately persist — never leave this in memory only
  const customer = await stripe.customers.create({
    email,
    metadata: { supabase_user_id: userId },
  })

  await supabase
    .from('profiles')
    .update({ stripe_customer_id: customer.id })
    .eq('id', userId)

  return customer.id
}

Step 2: Checkout Session (Initial Payment)

Landmine #2: Pass idempotencyKey on Checkout sessions.

Without idempotency keys, a user double-clicking "Subscribe" can create two subscriptions. Always generate a key tied to the user + price combination.

app/api/stripe/checkout/route.ts

import { NextRequest, NextResponse } from 'next/server'
import { createClient } from '@/lib/supabase/server'
import { stripe, getOrCreateStripeCustomer } from '@/lib/stripe'

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

  const { priceId } = await req.json()
  const customerId = await getOrCreateStripeCustomer(user.id, user.email!)

  const session = await stripe.checkout.sessions.create(
    {
      customer: customerId,
      mode: 'subscription',
      payment_method_types: ['card'],
      line_items: [{ price: priceId, quantity: 1 }],
      success_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard?checkout=success`,
      cancel_url: `${process.env.NEXT_PUBLIC_APP_URL}/pricing`,
    },
    {
      idempotencyKey: `checkout-${user.id}-${priceId}`,
    }
  )

  return NextResponse.json({ url: session.url })
}

Step 3: Webhook — The Most Critical Part

Landmine #3: You MUST use req.text() for the raw body.

This is the #1 cause of webhook failures. If you use req.json(), the body gets parsed and Stripe's signature verification fails. Always read the raw text first.

app/api/stripe/webhook/route.ts

import { NextRequest, NextResponse } from 'next/server'
import { headers } from 'next/headers'
import Stripe from 'stripe'
import { stripe } from '@/lib/stripe'
import { createAdminClient } from '@/lib/supabase/admin'

export async function POST(req: NextRequest) {
  // Critical: use req.text(), NOT req.json()
  const body = await req.text()
  const signature = headers().get('stripe-signature')!

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

  const supabase = createAdminClient()

  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object as Stripe.CheckoutSession
      const customerId = session.customer as string
      const subscriptionId = session.subscription as string

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

      if (profile) {
        await supabase.from('profiles').update({
          subscription_status: subscription.status,
          price_id: subscription.items.data[0]?.price.id ?? null,
          current_period_end: new Date(
            subscription.current_period_end * 1000
          ).toISOString(),
        }).eq('id', profile.id)
      }
      break
    }

    case 'customer.subscription.updated': {
      const subscription = event.data.object as Stripe.Subscription
      const { data: profile } = await supabase
        .from('profiles')
        .select('id')
        .eq('stripe_customer_id', subscription.customer as string)
        .single()

      if (profile) {
        await supabase.from('profiles').update({
          subscription_status: subscription.status,
          price_id: subscription.items.data[0]?.price.id ?? null,
          current_period_end: new Date(
            subscription.current_period_end * 1000
          ).toISOString(),
        }).eq('id', profile.id)
      }
      break
    }

    case 'customer.subscription.deleted': {
      const subscription = event.data.object as Stripe.Subscription
      const { data: profile } = await supabase
        .from('profiles')
        .select('id')
        .eq('stripe_customer_id', subscription.customer as string)
        .single()

      if (profile) {
        await supabase.from('profiles').update({
          subscription_status: 'canceled',
          price_id: null,
        }).eq('id', profile.id)
      }
      break
    }
  }

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

Step 4: Customer Portal (Subscription Management)

Landmine #4: Configure the Portal in Stripe Dashboard BEFORE writing code.

The Portal needs to be explicitly enabled in Stripe Dashboard → Settings → Billing → Customer portal. Test mode and live mode are configured separately — I've been burned by this more than once.

app/api/stripe/portal/route.ts

import { NextRequest, NextResponse } from 'next/server'
import { createClient } from '@/lib/supabase/server'
import { stripe, getOrCreateStripeCustomer } from '@/lib/stripe'

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

  const customerId = await getOrCreateStripeCustomer(user.id, user.email!)

  const session = await stripe.billingPortal.sessions.create({
    customer: customerId,
    return_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard`,
  })

  return NextResponse.json({ url: session.url })
}

Step 5: Env Switching (Test vs Live)

Landmine #5: Different webhook secrets for test and live mode.

STRIPE_WEBHOOK_SECRET from stripe listen (local dev) is different from the one in Stripe Dashboard (production). I once deployed with the test secret to production and spent an hour wondering why all webhooks were failing.

# .env.local (development)
STRIPE_SECRET_KEY=sk_test_xxxx
STRIPE_WEBHOOK_SECRET=whsec_xxxx   # from: stripe listen --forward-to localhost:3000/api/stripe/webhook
NEXT_PUBLIC_APP_URL=http://localhost:3000

# .env.production (Vercel)
STRIPE_SECRET_KEY=sk_live_xxxx
STRIPE_WEBHOOK_SECRET=whsec_yyyy   # from: Stripe Dashboard → Developers → Webhooks
NEXT_PUBLIC_APP_URL=https://yourdomain.com

checkout.session.completed
customer.subscription.updated
customer.subscription.deleted

10 Rules I Follow Every Time

Create Stripe Customer at signup, not at payment time
Always use req.text() in webhook handler — never req.json()
Use idempotencyKey for Checkout sessions (user ID + price ID)
Enable Customer Portal in both test and live Stripe Dashboard
Use separate STRIPE_WEBHOOK_SECRET per environment
Store stripe_customer_id in DB immediately after creation — don't hold it in memory
Access control = subscription_status + current_period_end (not just status)
Use stripe.webhooks.constructEvent — never skip signature verification
Handle subscription.updated with status: canceled for end-of-period cancellations
Index profiles(stripe_customer_id) — you'll query by it on every webhook

What Takes 8 Hours vs 30 Minutes

The first time: figuring out raw body, Customer creation order, idempotency, environment mismatches.

With this template: copy, replace env vars, enable Portal in Dashboard. Done.

Next up: "Supabase + Vercel + Next.js: 15 Landmines" (→ #7)

Originally posted on note (Japanese): https://note.com/mintototo1/n/nc7cf608b62e4