01

"Claude Code is so powerful now — can't you just have it write the subscription logic?"

I get the thinking. Before I built subscriptions myself, I thought the same thing.

My previous setup was one-time payments with a pure credits system — buy N times, pay a fixed amount, credits never expire. That's genuinely simple. No billing cycles, no permission resets, no tier resets. AI handled it just fine — describe it clearly, hand it over, and the code comes back fast. Looks like it works. Looks correct.

And yes, Claude writes code impressively well these days. But subscriptions are different. Subscriptions have lifecycles, state transitions, and complex chains of business logic. It's not enough for the database to be correct and the code to not throw errors — you also need to verify that everything is aligned with what the payment platform thinks the user's subscription state is.

The 2 subscription modules in Pay4SaaS were built with AI, but the quality was something I painstakingly refined — not something it delivered in one shot.

Every edge case, every exception scenario — I went back and forth with it, cross-referencing industry best practices, business logic, and user experience, confirming, revising, and retesting, round after round, before anything was finalized.

02

The reason I don't fully trust Claude Code is that anyone who uses it frequently will notice these problems.

1. AI Is Forgetful

Plenty of people in dev communities have complained about this — Claude Code has a habit of dropping things.

For straightforward, self-contained tasks it's fine. Build a page, integrate Fumadocs for docs/blog, set up analytics — all doable in half a day. But the moment things involve multiple dependencies and complex logic, the forgetfulness shows. It misses one check early on, and the whole chain breaks downstream — and the break isn't always where you'd expect to find it.

This forgetfulness is like having a coworker who's occasionally careless and sometimes hallucinates. In something as serious as payments, that should raise a red flag. And here's the scary part:

Just one or two oversights are enough to leave a subscription flow incomplete. And an incomplete flow will almost certainly produce errors — that's just inevitable.

It tells us the tests pass, but when you actually test, there's still a pile of issues. AI's job ends the moment it outputs code. Everything after that is on us.

2. AI Doesn't Know Your Business Logic

For example: should a downgrade take effect immediately, or at the next billing cycle? AI will most likely just update the plan_type directly. But the user paid for a premium tier this month — an immediate downgrade means swallowing the price difference.

I use pending_plan_* fields to record the change, then only switch when the renewal webhook arrives. AI wouldn't think of that — I got it working correctly through repeated testing and iteration.

And some decisions have no standard answer — they depend on your product strategy. AI can only guess. When it guesses wrong, the code runs, the logic is skewed, users feel it, and you might not even know where the problem is.

3. AI Can't Cover Edge Cases

And edge cases are exactly where payments break most often.

The code it generates looks runnable and the logic seems sound, but it doesn't always anticipate the boundaries. For example:

• It doesn't know that PayPal and Creem trial products actually need to be created as 2 separate products — otherwise users end up in an infinite trial loop.

• Two requests arrive almost simultaneously — one is a successful renewal webhook, the other is a manual cancellation from the user. AI doesn't account for this race condition, so the final state depends on which one writes to the database last — pure luck.

These scenarios go uncovered, and we might not catch them either — until a real user hits the problem. By then, it's too late.

03

Since AI can't be fully relied on, we have to own it ourselves.

Payments are the last gate of your product. The moment a user hands over their money is the moment of highest trust — and the most fragile. If this gate breaks, everything you built before it is wasted.

Users have near-zero tolerance for payment issues. Nobody is willing to compromise when it comes to their money.

04

In real-world professional development, the standard process works the same way — requirements, product design, UI, development, testing. Tests pass before you ship. Writing the code isn't the finish line.

And testing payments isn't just clicking around a few times to see if it runs. For subscriptions alone: normal flows need testing, error flows need testing, edge cases need testing, webhooks need testing, upgrades and downgrades need testing, annual-to-monthly switches need testing, and every trial period scenario needs testing.

When I put it all together, just the subscription portion had over 60 test cases. Every single one had to pass. Not one could be skipped.

Only after all of that is it truly done — and done right.