Previously
In Part 5: Evolution, I wrote about building the entire "sales engine" myself — Stripe payments, a landing page, and automated email delivery.
The product was complete. Sales had begun. But then I hit a technical wall.
The Limits of GAS
The Kagemusha system ran on Google Apps Script (GAS). GAS is a free scripting environment provided by Google that makes it easy to integrate with Spreadsheets, Calendar, and other Google services.
At first, it was more than enough. But as I operated it as a real product, the limitations became clear.
- Execution time limit — Each execution maxes out at 6 minutes. Heavy processing simply times out
- Speed — Slow response times. Users are left waiting
- Concurrency limits — Multiple simultaneous users cause bottlenecks
- Deployment complexity — Every update requires a manual deployment
None of this would have mattered for a tool only I used. But for a product serving multiple users, these were dealbreakers.
The Decision to Migrate
Honestly, when I heard "Cloudflare Workers," I had no idea what it meant.
Here's how Claude Code explained it:
Runs on a single Google server
Google processes every request
Slow when the user is far away
6-minute execution time limit
Free but heavily restricted
Runs in 300+ locations worldwide
The nearest server handles the request
Blazing fast (single-digit milliseconds)
Much more relaxed execution time limits
Generous free tier
Put very simply, it's like moving from "a single local shop (GAS)" to "a nationwide franchise (Workers)." Customers are served at the nearest location, so wait times drop dramatically.
The Terror of Server Migration as a Beginner
Can you imagine how frightening this decision was?
Moving a live system to a completely different environment. Done by someone who had never written code before. One wrong step, and existing users' systems go down.
Claude Code broke the migration into five phases and guided me through each one step by step.
Phase 1: API Foundation
Set up the new Workers environment and build the basic API endpoints (the communication layer).
Phase 2: Authentication & Security Migration
Move user authentication and security mechanisms to Workers.
Phase 3: Core Feature Migration
Rewrite the core attendance management features to run on Workers.
Phase 4: Payment & Email Integration Migration
Connect Stripe Webhooks and email systems to Workers.
Phase 5: Full GAS Decommission
Shut down the old environment and run everything on Workers.
Rather than doing it all at once, we moved one piece at a time, verifying each step. Test in the new environment, switch over if everything checks out. Keep the old environment running as a fallback in case anything goes wrong.
Even as someone with zero programming experience, this "careful, phased" approach gave me the confidence to push through the fear.
The Current Tech Stack
Now that the migration is complete, here's how the Kagemusha system is built:
| Role | Technology | What It Does (In Simple Terms) |
|---|---|---|
| Server Processing | Cloudflare Workers | API processing, authentication, payment integration |
| User Data | Google Spreadsheet | Storing attendance records (within each user's account) |
| Calendar Integration | Google Calendar API | Reading lesson schedules |
| Payments | Stripe | Monthly subscription management |
| Landing Page & Blog | Cloudflare Pages | Website hosting |
| Initial Setup | Google Apps Script | Automated user environment setup (the only part still on GAS) |
What It Means for a Beginner to Make Technology Decisions
Here's the interesting part: someone with zero programming experience — me — is making "technology decisions."
GAS or Workers. Firebase Hosting or Cloudflare Pages. REST API or Webhooks.
These are decisions traditionally made by a CTO or tech lead. But AI explains the pros and cons of each option and makes recommendations based on the current challenges.
I make the final call. But AI provides all the information I need to decide.
This is the reality of software development in 2026.
Next Time
Part 7: The Finale — Present and Future — Where a SaaS built by a non-programmer stands today. And where it's headed next. The conclusion of this series.
Still managing tutor attendance manually?
Discover Kagemusha System