Hi, I'm tsuzuki817 (@tsuzuki817), an iOS engineer at ZOZOTOWN.

My day job is working on a large-scale app, but when I tried to take my indie apps global, one particular task was so hopelessly tedious that it nearly broke me.

Yes: "making localized screenshots".

"If you're an engineer, you should automate this kind of grunt work."

With that one thought in mind, I built ScreenNative, a localization SaaS powered by AI (Gemini 3 Pro), pair programming with AI (Claude Code).

In this post I'll share what went on behind the scenes: how I built it, and the "robust architecture" I was particular about on the technical side.

Why I built it: a pain only iOS engineers understand

To take an app global, you have to upload screenshots for every language to App Store Connect. But if you try to do this properly, you're in for hell.

I thought, "This isn't a job for a human."

The team: me (CTO) × AI (lead engineer)

For this project, I decided the spec as CTO and PM, and the AI (Claude Code) implemented it as lead engineer.

I didn't just have it write code. I bounced ideas off the AI starting from the architecture design.

By speeding up the spec → implementation cycle as far as it would go, I was able to take a SaaS with payments all the way to deployment in effectively three days.

Tech stack and architecture

I didn't cut corners just because it was an indie project. I aimed for security and scalability at a level a company could adopt.

How the systems connect

Next.js API Routes act as the gateway, and the actual processing happens in a secure backend (Admin SDK).

┌─────────────────┐    ID Token    ┌─────────────────┐
│  Client/Next.js │ ─────────────▶ │   API Routes    │
└─────────────────┘                └─────────────────┘
                                          │
                    ┌─────────────────────┼─────────────────────┐
                    │                     │                     │
                    ▼                     ▼                     ▼
            ┌─────────────┐       ┌─────────────┐       ┌─────────────┐
            │  Firestore  │       │ Gemini API  │       │   Stripe    │
            │  (Admin SDK)│       │             │       │             │
            └─────────────┘       └─────────────┘       └─────────────┘
                    │                                          │
                    │              Webhook                     │
                    │ ◀────────────────────────────────────────┘
                    ▼
            ┌─────────────────────────────┐
            │  Cloud Functions (Gen 2)   │
            │  - Transaction handling    │
            └─────────────────────────────┘

Where I got particular on the technical side

1. Zero-trust design with security first

I stuck rigorously to "never trust the client (the browser)".

Firestore Security Rules

Users can't write to the users collection at all (allow write: if false). Credit consumption and plan changes always go through server-side API Routes, using the Admin SDK.

Magic byte verification

When an image is uploaded, I check not just the file extension but the start of the binary (the magic number), so disguised files get rejected.

2. A payment system with guaranteed idempotency

Webhooks from Stripe can arrive more than once because of things like network errors.

So I track event IDs in a stripeWebhooks collection and implemented logic that never processes a payment event twice once it's been handled (idempotency).

Credit consumption also uses a Firestore Transaction, so "generation succeeded" and "credits deducted" stay perfectly in sync.

3. Type safety and DX (Developer Experience)

To keep development efficient, I was strict about having a "Single Source of Truth".

Deriving types from constants

The "supported languages list" and "plan definitions" are defined as constants, and the TypeScript types (LanguageCode, PlanId) are generated from them automatically (typeof ...). That way, when I add a plan, every place that needs fixing shows up immediately as a type error.

Double validation with Zod

I use Zod to validate API request bodies, keeping the TypeScript type definitions and runtime validation in sync.

Wrapping up

ScreenNative is a product where an iOS engineer seriously built the thing he wanted for himself.

• Support for RTL (right-to-left) layouts such as Arabic
• Recommended status bar cleanup (9:41 / 100%)
• Automatic device frame compositing

I packed it with the kind of attention to detail only an app developer would care about.

Thanks for reading all the way to the end.
If even one more developer escapes "screenshot hell", nothing would make me happier.