When Stripe’s “Test payment succeeded” notification popped up, my hands were shaking.

I’m not exaggerating. They were literally shaking. I typed in the test card 4242 4242 4242 4242, the webhook fired, and the user status in the database flipped to premium. On the screen, “Payment Succeeded” was glowing.

It worked. It actually worked.

But what I felt in that moment wasn’t a sense of accomplishment — it was the raw fear of “What if this breaks in production?”

I’ve written before about building five apps and shipping a fortune-telling app to the Play Store in three days. But this story is fundamentally different. It’s about crossing from the “building” phase into the “delivering” phase — stepping out of the world of building for free and using for free, into the world of asking people to pay.

This post is a complete record of what that transition felt like — what I did, and what scared me.

The Wall Between Free and Paid — The Terror of Charging Money

Everything I’d built until now was free.

Class progress tracking, travel expense calculator, seating shuffler — all tools I made because I needed them. All I had to do was hand them to colleagues and say, “Give it a try.” If there were bugs, a quick “Sorry, I’ll fix it” was enough. Getting thanked felt good, and if nobody used them, no big deal.

But asking someone to pay is an entirely different act.

Suddenly, you’re responsible for quality. “I paid for this and it doesn’t work” is unacceptable. A bug that’s forgivable in a free tool becomes borderline fraud in a paid product.

Let me be honest. When I got Stripe integrated and the payment flow actually working, the strongest emotion I felt was “Who would actually buy this?” — pure lack of confidence.

Everything worked perfectly in the test environment. I ran test card payments dozens of times — webhook processing, status updates, cancellation flow — all verified. But production is a different world. The test card 4242 4242 4242 4242 isn’t a real credit card number.

My finger hesitated over the button to switch to production. “Once I flip this, there’s no going back.” The feeling was strangely similar to the nervousness I felt the first time I stood at a podium to teach.

And sure enough, bugs appeared right after launch.

Issues that only surfaced in production. Behavior the test environment never caught. A case where payments didn’t process correctly. Email notifications that failed to send.

“What if this had happened after someone paid —”

Late-night hotfixes. Nobody even knew the service existed yet, but my hands were shaking from the urgency. It’s strange, being this terrified when you have zero users. That’s when I truly understood the weight of charging money.

Star Oracle — How a Fortune-Telling App Became a Web Service

In a previous post, I wrote about building Star Oracle as a mobile app and shipping it to the Play Store in three days. Back then, I was riding the high of “building is fun.”

But after finishing the mobile version, something kept nagging at me: “I want to do this on the web too.”

Apps are great for daily use. But the web has something apps don’t — the frictionlessness of a single URL. Tap a link shared on social media and you’re in, no installation required. That zero-friction access is a real advantage.

That’s how Star Oracle Web (currently on hiatus) was born. I rebuilt it from scratch with Next.js as a completely separate codebase from the mobile version, integrated Stripe payments, and deployed it on Vercel.

Guardian Tarot Reading

At the heart of Star Oracle is the Guardian Tarot Reading. Enter your birthday and discover your personal guardian tarot card.

The vision is to create a culture where people share their guardian card like they share their MBTI type — “My guardian tarot is The Moon” on social media. Not fortune-telling per se, but tarot as a way to discover something about yourself.

Tarot Readings

Of course, there’s also full tarot reading. One-card oracle, three-card spread, Celtic Cross — three spread types. I designed it for daily use: pull one card each morning as a guide for the day.

The basic features are free. Premium (980 yen/month, roughly $7) unlocks the full 78-card deck, all spreads, and detailed love and career readings. The philosophy: “Try it free, go deeper if you like it.”

Honestly, users are still few. But completing a service with a revenue mechanism built in from day one — that alone was a huge step for me.

Wrestling with Claude Code’s Context Window

Star Oracle Web was built almost entirely with Claude Code. Authentication, payments, database, APIs — there’s no way I could have built a web service of this scale without it, since I can’t write code.

But it wasn’t all smooth sailing.

As development intensified, conversations grew longer. Read files, make changes, test, fix again — repeat this cycle enough times, and at some point, Claude Code suddenly starts acting strange.

It forgets the project structure it understood perfectly moments ago. It touches files I never mentioned. It repeats the same mistakes. In the worst cases, it asks “Can you tell me about this project’s structure?” Your partner, who was just designing the architecture with you, suddenly has amnesia.

“Do I really have to explain everything from scratch again?”

If you’ve done vibe coding, I bet you know this frustration.

The cause is clear: context window compression. Claude Code has a conversation length limit. As you approach it, earlier parts of the conversation get compressed. In that instant, accumulated context — “this file works like this,” “don’t touch that part” — partially vanishes. Your partner’s brain suddenly resets.

After getting burned enough times, I finally learned how to work with it:

• Write a solid CLAUDE.md — The project’s “user manual.” Tech stack, commands, files that must never be touched. Even when the context gets compressed, CLAUDE.md is always loaded, preserving a minimum baseline of context.
• Use /compact proactively — Instead of waiting for automatic compression, compress on your own terms. “Summarize everything so far” — controlling the timing yourself yields better results.
• One task, one session — “Implement auth” and “implement payments” are separate sessions. Don’t try to do everything in a single conversation.
• Delegate research to sub-agents — Let separate agents handle file searches and exploration, saving the main context for what matters.

The interesting part is that this is project management, plain and simple. Break tasks down, organize context, write documentation. The same things human dev teams need to do.

Working with AI isn’t about having an “infinite partner.” It’s about working with a brilliant colleague who has limited memory. Understand the constraints, design your workflow around them. Claude Code forced me to get a little better at project management.

Two Pillars — Monetizing Across App and Web

While Star Oracle Web was going live, something else was happening in parallel.

fortune-app (Star Oracle’s mobile version) had been submitted for Google Play Store production review.

A mobile app built with React Native and Expo SDK 54. After closed testing, I finally submitted it for production review. If it passes, it goes live in 177 regions worldwide.

The mobile app has a different pricing model from the web version. While the web runs on subscriptions (980 yen/month), the app uses one-time purchases. Love advice at 250 yen, career advice at 250 yen, three-card spread at 350 yen, Celtic Cross at 480 yen — buy once, use forever.

There’s a reason I chose different models for each channel. The web is easy to update — you can deploy instantly without review, making it well-suited for delivering ongoing subscription value. Apps embed themselves into daily routines. Wake up, open your phone, pull a tarot card. For that kind of habit, a one-time payment feels more natural.

In other words, web subscription revenue and app one-time purchases — two pillars rising at the same time.

“Try it free on the web, and if you like it, use the app too.” Neither channel is strong enough alone. Together, they create more touchpoints with users.

If you told me six months ago, “You’ll be running a service with two revenue channels,” I wouldn’t have believed you. Of course, I still don’t know if the review will pass. Even if it does, money won’t start flowing in immediately. But the fact that I built a state where revenue can happen — nobody can take that away.

From “Building” to “Delivering”

Looking back, my indie dev journey has gone through three phases.

Phase 1: Building for myself. Class progress tracker, travel expense app, seating shuffler. Built to solve my own problems. I can’t write code, but if I can articulate what I need, AI shapes it into reality. Just knowing that changed my world.

Phase 2: Building for fun. Shipping a fortune-telling app in three days, assembling a blog agent team. The “building itself is fun” phase. It’d be great if someone used what I made, but curiosity was the core motivation.

Phase 3: Building to deliver. Star Oracle Web. The first thing I designed from the ground up with “delivering to someone and being paid for it” as the premise.

Honestly, Phase 3 is harder than Phases 1 and 2.

There are walls that fun alone can’t get you over. The tedium of running Stripe payment tests dozens of times. The pressure of “this error handling involves money — it absolutely cannot fail.” The cold sweat when bugs surface after launch.

But hard doesn’t mean unpleasant.

“Someone might actually pay for what I built” — just having that possibility changes how I feel when I wake up in the morning.

I can’t write code. Still can’t. But I’ve come this far: articulating problems, shaping solutions with AI, and delivering them to the world. Right now, revenue is essentially zero. Even if the Play Store review passes, I don’t expect instant sales.

But the shift itself — from “build and done” to “build and deliver” — that’s growth for me.

I’m scared. But I’m excited. I think that feeling is probably the right one.

See ya!