Tiglit: From "Real Tamagotchi" to a Tiger Cub, Forced by Apple

Before the beginning: what "day one" actually looked like

The earliest available sessions are all labeled "Toddler advice app" — but even the earliest one already shows a fully working product called Real Tamagotchi: a live app with sign-in, a database, payments, and a Claude-powered "describe your toddler's behavior, get research-backed advice" engine already functioning, mid-conversation confirming a real $49 lifetime-plan payment had just succeeded. Whatever conversation produced the original idea and the first working build isn't in any retrievable transcript. The best available anchor for "day one" is the repo itself, timestamped June 2, 2026 — that's the date this devlog treats as the effective start.

Phase 1 — Core build-out: logo, payments, and the first real feature fights

By the earliest readable point, the app already had sign-in, a user/history system, subscriptions, and a Claude-based behavior analyzer with voice, text, and video input. Real bugs surfaced by actual use, not code review: a usage counter that didn't decrement, a sign-out link pointing at a route that didn't exist, verification emails landing in spam, a speech-recognition API that silently stopped listening after a few seconds.

The mascot went through several complete redesigns in this window — a glossy lavender egg with a cartoon hatchling face, then a baby silhouette inside the egg — before being abandoned entirely. None of it survived to the current brand.

A whole session died mid-task on a hard usage-limit error and never recovered. The fix that came out of that dead end mattered more than the loss: a memory file, written into the project so a fresh session could pick up the same momentum. That pattern — a memory file plus a copy-paste handoff prompt for the next session — recurs for the rest of the project's life, across web, iOS, and at least one deliberate model switch to manage cost.

Phase 2 — Growth hustle: Reels, an affiliate program, and two audits that found the same bug

An affiliate program for parent-creator influencers shipped, then immediately started collecting spam bot signups — dozens a day, each one burning email-sending reputation. Fixed with a honeypot field and a minimum fill-time check, both failing silently so bots don't adapt.

Two independent UX audits, weeks apart, run by sessions that hadn't seen each other's findings, both rediscovered the same critical bug: the demo's text input unmounted itself the instant you typed a character — silently breaking the single most important conversion path on the site, for weeks, until an agent tried to actually use it like a visitor would. One audit initially flagged a different issue as a P0 retention killer, then walked that back on a second pass with actual code inspection — reported as a correction rather than left as a false alarm.

Phase 3 — Feelings Song, and the deploy saga that wouldn't die

The second tool — an AI-generated song from a child's name, feeling, and lesson — ran into a genuine multi-session ordeal: the project lived in a cloud-synced folder, and that sync's file locking made deployment intermittently hang. This got expensive and confusing enough that a fresh session, on a different model, was brought in cold specifically to re-diagnose from scratch rather than trust the first session's theory — and it found a real root cause the first session had missed. A good example of a second opinion catching what the first one didn't.

Phase 5 — Story Studio: the most-iterated feature by far

Personalized illustrated storybooks absorbed more rework than any other single feature. A root-cause debugging moment worth quoting: a generated story that was nonsensical and about 20 seconds long turned out not to be a prompt-quality problem — it was the app's silent fallback template firing because the story data had failed to parse. An explicit cost callout — burning real money with no working example yet — prompted a guard against re-triggering an identical generation while one was already in progress.

A deep research pass was run before touching prompts again: real research into picture-book craft, child literacy frameworks, and illustration principles, then applied across the prompts. Two more honest bugs: character appearance drifting between pages (fixed by anchoring every page to the cover image), and narration not matching the page on screen (the text-to-speech was literally reading the app's own instruction text aloud).

A "network error 3+ times before it works" complaint got its own dedicated diagnosis: story generation was a single serial request capped at a hard function time limit, and when the story ran long, the code silently made a second full ~40-second call to retry — stacking two long calls inside one budget window. Fixed with a shared generation core, a single larger-budget call, and idempotency tokens so a retry can't create duplicate stories. Honest postscript: the very next real-world test still failed once and needed a retry — reported as "seems more robust," not "fixed."

A physical hardware integration — printing storybook strips from a Bluetooth receipt printer — uncovered a genuine platform wall, not a bug: no browser on iOS supports the needed Bluetooth API, because every iOS browser runs on the same underlying engine. The workaround kept direct printing on Android/desktop and generated a shareable image to hand off to the printer's own app on iOS.

Phase 6 — The iOS app and three rounds with Apple

App Store Connect had a build-selection bug that resisted diagnosis for a long stretch — every uploaded build showed as greyed-out and unselectable, escalating all the way to an actual phone call with the platform's developer support. The root cause was a misconfigured CI workflow setting hidden behind a save button that silently hadn't saved.

Once submitted, three rounds of review followed. The second is the one that mattered most: the app's own name was flagged — a real trademark concern against an existing, well-known toy property the original name referenced. That rejection is the direct, documented trigger for the full rebrand: new name, new tiger-cub mascot, replacing what had, until then, been a hamster-face icon left over from the original concept. The next review dropped that issue entirely, confirming the rebrand cleared it.

Phase 7 — The rebrand itself

Triggered by the trademark rejection, the rebrand touched the domain, the color system, and — expensively — auth. The color system was iterated live and by feel over several rounds: an initial dark-brown chrome read as muddy, replaced with teal chosen specifically as a complementary contrast to the orange tiger cub. Auth broke twice during the domain migration, because production auth keys are domain-locked — switching the primary domain silently issued a brand-new key that had to be manually copied and rebuilt, and a separate OAuth redirect had to be manually updated. Both were diagnosed by reading the live browser console rather than guessing.

Phase 8 — The blog: a fully autonomous, twice-weekly pipeline

Since mid-June, a scheduled task has researched, written, and published a blog post roughly twice a week — deliberately architected to avoid the sync problem entirely by writing straight into a database rather than through git. Each run dedupes against the last 50 posts, searches for a citable current angle from at least two reputable sources, writes 600–1,000 words in a consistent voice, publishes, and verifies the live URL actually renders before reporting done.