CosmicKeysA consumer typing platform, built end-to-end with an AI coding partner — to measure what the new paradigm actually ships in production.

After wrapping a long corporate engineering engagement, the question worth answering was: what can an AI coding partner actually ship in production, end-to-end, under realistic engineering discipline? Not in a demo. Not in a tutorial. In a real consumer product with real users, real payments, real regional infrastructure, real failure modes.

CosmicKeys is the experiment's test bed. The page below is the result.

Product selection criteria

For the experiment to mean anything, the product had to satisfy four constraints simultaneously:

Why typing

Touch typing fits all four criteria precisely. It's universal — every computer user types every day, in every language, in every profession. It's multi-language not as an afterthought but as the core product (typing in German is a different motion from typing in English; typing on a Swedish keyboard exercises different muscles than on an American one). It needs payments to be sustainable without ads. It needs to scale from 1 to billions because typing won't go away. And it's consumer-facing in the most demanding way: typists feel latency, animation jitter, and audio drift in milliseconds because their own hands are providing the input ground truth.

Most consumer products would test the AI partner on one or two dimensions. Typing — done seriously — tests it on all of them. The rest of this page is the answer to whether the AI partner could actually ship under that brief.

The methodology — the Tango Development Pattern (TDP)

Click to enlarge

The Tango Development Pattern (TDP) — each section's Human / AI Partner / The Tango card trio illustrates this dance at a specific design moment. The lead alternates: human leads the product vision and judgment calls; AI partner leads the implementation depth and breadth-of-knowledge moves. Neither is the sole author of anything.

Let's give the dance a name: the Tango Development Pattern, or TDP if it catches on (and if it doesn't, you still got a useful mental model out of the bargain — coined here, free to take). Here's the bet behind the term: most engineers building with AI today are already doing some version of this dance, knowingly or unknowingly. The ones who get fluent in the choreography are the ones whose AI partner ships production-grade work; the ones who don't get fluent end up with impressive-but-fragile demos that fall apart at the edges.

The trick isn't extracting more out of AI. The trick is knowing when to lead (product vision, judgment calls, rejecting a “good enough” answer that isn't really good, drawing the line on what NOT to build) and when to let AI lead (implementation depth across 20 specialties, breadth-of-knowledge moves you couldn't do alone in six months even if you tried). Learn the steps and the lead-swap, and you can ship pretty much any consumer product under a brief like this one. CosmicKeys is the worked example; TDP is the technique.

For 25 years pre-AI, a consumer product of this scope would have required a team — product manager, designer, frontend, backend, DevOps, DBA, QA, security, localization, content, growth. A team of 5 to 8 people, working for 12 to 18 months, optimistically.

Under the brief, one experienced engineer plus one AI coding partner shipped it in 6 months — wearing 20 professional hats simultaneously, some carrying 20+ years of deep personal expertise (🎯), others where the human knew abstractly enough to lead the dance while AI brought the implementation depth (🤝).

The real superpower anyone building with AI as a partner needs isn't expertise in 20 domains. It's the ability to formulate the right question, evaluate AI's answer against the product vision, and make the final judgment call. That's the meta-skill that makes the tango work — and it's the skill that matters most in any role where AI is a force multiplier.

Neither the human alone nor the AI alone could have shipped CosmicKeys. It took both. Dancing.

The touch-typing category is a graveyard of clumsy interfaces glued together with banner ads, gated at $9.99/month for features that should be free, and almost never localized beyond a translated UI string. The market accepts mediocrity because typing apps are seen as commodity software — pick one, suffer the ads, move on.

CosmicKeys is the counter-example the brief produced. When the engineering discipline says “treat architecture, UX, and rich functionality as non-negotiable from day one — no trade-offs against each other,” the result looks structurally different from what the category typically ships.

The first foundational decision after the brief was the visual identity, deliberately spec'd before any component code was written. The first surface a visitor sees isn't a screen — it's a URL. The product had to live at a domain that hinted at the theme before the user landed: cosmickeys.app, picked deliberately over generic options like typing.io or typingpractice.com because the cosmic frame was the product's differentiator from the category's sea of bland white-and-blue UIs.

The visual identity reduces to three primitives that show up on every surface across the 196 production components (counted as .tsx files across frontend/components, contexts, hooks, and the App Router routes — verifiable by anyone with the repo):

🪐

Theme — cosmic

Deep slate background, cyan-and-purple nebula gradients, dark surfaces with subtle light (the swirls and starlight you see inside this card are the cosmic palette running live). Picked because typing apps are used for long focused sessions; dark reduces eye strain and the cosmic palette signals depth where the category typically signals utilitarianism.

Logo — a typewriter keycap emerging from the cosmos (shown left, the actual mark)

Its edge glows as if catching starlight (the soft purple aurora pulsing behind it on this card is exactly the effect the logo reads as in context); the cosmic radial gradient lives inside the keycap itself. Reads at every size from the 16px favicon to the 1200px share-card watermark — a single mark the eye recognizes whether it's a browser tab or a social preview.

💎

Recurring design primitive — the prismatic card

A translucent surface with a soft glowing light bleeding from its edges (like this card itself — the green halo around its rim is the prismatic-card primitive rendered at full strength), used everywhere from lesson tiles to analytics widgets to social-share previews. When you see the prismatic glow in a screenshot, you're looking at a CosmicKeys artifact.

The style guide spec'd these decisions explicitly up front, so the AI coding partner had a constrained visual palette to execute against rather than improvising component-by-component. Every screen across 196 production components reads as part of the same family because the AI partner had rails to run on. Without the up-front spec, the same AI partner would have shipped a dozen subtly-inconsistent variations of the same card pattern — coherence is what disciplined direction produces, not what AI volunteers.

With the brief defined and the visual identity locked, the third foundational decision is the technology stack. Each choice was made to optimize for one of two things: ship velocity (so the AI partner could move fast without re-deriving common patterns) or response latency (because typing apps live or die on input-to-paint time). The choices below aren't name-brand defaults; each was the answer to a specific question this product asked.

The latency principle — local-first, sync-second

Typing is the most latency-sensitive interaction in any application. A user pressing J expects the J to appear instantly — anything over 50ms feels broken. So CosmicKeys uses a local-first architecture: every typing-session interaction (keystroke registration, WPM calculation, accuracy tracking) happens client-side first, with the result rendered immediately. Data is then batched and synced to the backend in the background, encrypted in localStorage during the gap.

• Client-side WPM + accuracy computation on every keystroke — no server round-trip during typing. The number you see is the truth as of this exact millisecond, not as of the last ack.
• Per-session analytics buffered in XOR-encrypted localStorage — keystroke events accumulate locally during practice.
• Batched DB sync at natural break points (lesson complete, page navigation, idle threshold) — the server gets aggregated facts, never the raw keystroke stream.
• Privacy bonus: the server never sees what users actually typed (custom-lesson content lives only in localStorage; the database stores derived metrics, not source text).
• Offline tolerance: a user can practice through a 5-minute internet outage and have their progress sync when the connection returns.

The principle isn't “make the network faster” — it's “remove the network from the critical path.” That's what makes the app feel native rather than web-app-y. The 9 sections of the Platform Tour below each apply this principle wherever input latency matters; the design-system and latency-principle callouts inside each section flag the specific instances.

Whether you're curious how the product looks, evaluating the work without creating an account, or studying the build for your own AI-native project — the whole platform is captured below. Click any section header to expand it, then click any screenshot inside to open it at full size in a modal viewer with horizontal and vertical scroll for the larger images.

37 screenshots across 9 feature areas. Skim the section headings, expand the ones that matter to you, decide whether the architecture deep-dive below is worth your time.

▶🚪1 · Landing & Sign-In

The landing page is the first surface where the Cosmic Identity and the Tech Stack established above meet a real user. The visual frame is the prismatic-card pattern; the input latency feel comes from local-first state. Both are intentional. What the user actually does on this page is two things: pick a language, then choose how to sign in.

The landing page auto-detects the user's preferred language from their computer settings and uses it as the default — about 99% of visitors never touch the dropdown because the system-detected language is correct. The dropdown is there for the other 1%: users who want to switch to one of the other 7 selector entries (the dropdown shows 8 in total because English splits into US and UK, each with its own default keyboard layout). The chosen language is then tied to the account going forward — typing-history analytics are scoped per-language, so switching languages mid-account is intentionally awkward (use a separate account if you actively practice multiple).

Sign-in offers 5 paths so the user picks the path of least friction for them: 3 OAuth providers (Google, GitHub, Microsoft — no userid/password to remember, nothing for CosmicKeys to store or leak), Magic Link via Resend (one-tap sign-in via email link, no password ever set), and a fully-functional Guest mode where the user practices with zero account at all — their entire history lives in XOR-encrypted localStorage and migrates atomically to a real account on sign-up if they decide to stay.

🧑 Human

Product Manager + UX Designer + Security Reviewer

Defined the friction-free entry: 7 first-class language tiles as the landing hero (auto-detected via navigator.language, override-able), then 5 sign-in paths — 3 OAuth providers + Magic Link via Resend + a fully-functional Guest mode where the user's entire practice history lives in XOR-encrypted localStorage. Decided that the language choice should pre-configure not just UI strings but the voice family AND the keyboard layout (matched to OS + region detected by the pre-signin endpoint), so the first lesson loads in the correct visual + audio context with zero configuration wizard. Account-bound language means a German user who signs up in German sees German voice, German keyboard, German lesson content — consistency per learner, not per device.

🤖 AI Partner

Implementation Engineer

Generated the landing-page layout, the 3-OAuth-provider plumbing with their different scope and redirect patterns, the Resend magic-link send / verify / callback flow with localized email templates per language, and the guest phantom-user system whose XOR-encrypted localStorage progress migrates atomically to a real account on sign-up. Built the BROWSER_LANGUAGE_MAP detection layer with fallback through navigator.languages array, and the pre-signin endpoint that detects OS, keyboard type (ANSI/ISO), and language in parallel.

💃 The Tango

The human wrote the “5 methods, zero passwords, guest progress migrates” spec in 4 bullets. AI generated the implementation in one pass. Gemini partner-review flagged that the migration path lacked an anti-abuse guard for delete-then-restore cycles. Codex partner-review confirmed the session cookie was SameSite=Strict. The human triaged findings, iterated 3 rounds, and locked the friction at actually zero — not just “low.” The whole sign-in surface (5 paths + guest mode + 7-language pre-config + 3-AI security audit) shipped in 9 commits over 4 days; that throughput is the human-AI tango's signature.

Click to enlarge

Homepage with language selector open — English (US), English (UK), German, Swiss German, Danish, Spanish, Norwegian, Swedish. English splits into US and UK because UK defaults to an ISO keyboard layout while US defaults to ANSI.

Why this screen exists

The first 5 seconds on the landing page decide whether a visitor stays or bounces. CosmicKeys leads with 7 first-class languages as a top-of-page commitment rather than a buried settings toggle — that signals localization is baked in, not bolted on. The cosmic dark-space-with-cyan-and-purple-nebula palette signals visual confidence on a category dominated by sterile white-with-blue-accent typing apps, and the typing brand promise is implicit because nothing else is fighting for attention.

▶Design nuances most visitors miss(6)

• Each of the 8 selector entries maps not just to a UI translation but to a specific TTS voice family (14 voices total — male + female per content language; English content is shared between the US and UK entries because the only difference is the default keyboard layout) and a curated set of regional keyboard layouts. Picking a language pre-configures the whole product, not just the chrome.
• Pre-signin language detection runs before the user clicks anything: navigator.language → BROWSER_LANGUAGE_MAP → SUPPORTED_LANGUAGES[code] with a fallback through navigator.languages array; the user's best-match language is visually highlighted so they know the app already heard them.
• In parallel with language detection, the pre-signin endpoint also detects OS (Mac/Windows) and keyboard type (ANSI/ISO), so by the time the user picks a language, the keyboard layout for the first lesson is already correct — no configuration wizard, no “first lesson in wrong layout” embarrassment.
• The palette (deep slate background, cyan/purple nebula gradients) was chosen before a single React component was written — Sam locked the brand before the code so AI's generic dark-mode defaults got rejected on principle until they actually felt cosmic.
• No cookie modal, no email-capture popover, no “rate our beta” toast on first visit — those exist but are deferred; the language hero is a deliberate inversion of the modern web's default of accosting the user before they've seen the product.
• The page is server-rendered with the detected locale already applied, so the first paint shows the user's language — not a flash of English that swaps to German half a second later.

▶What each hat contributed(6)

• 🎯#1 Product Manager · Decided that language is a first-class onboarding decision, not a settings-screen afterthought — the alternative (default English, change later) would have lost the multilingual user before they typed a single key.
• 🎯#2 Creative Director · Locked the cosmic theme + nebula palette pre-code as a brand decision; rejected AI's generic “dark mode” defaults until the page actually felt like a typing platform for stargazers rather than a Bootstrap landing template.
• 🤝#3 UX / UI Designer · Designed the language-tiles-as-hero pattern with each tile sized so a desktop visitor sees all 7 at once, and a mobile visitor — typically a prospect evaluating the product before coming back on their computer for actual typing practice — sees at least 4 above the fold. Same hierarchy, scaled to each device's real role.
• 🤝#11 Localization Lead · Owned the entire 7-language matrix: UI strings, voice mappings, keyboard layouts, custom-lesson templates, locale-aware SEO routing, currency mapping — every layer of the product is localized, not just the words on this page.
• 🎯#13 Security Engineer · Reviewed the pre-signin detection endpoint to confirm no PII leaks during the OS/keyboard/language detection — the IP and User-Agent never reach the database, only their derived facts (OS, ANSI/ISO).
• 🤝#16 Privacy & Compliance Officer · GDPR consent banner is deferred to after the first interaction so the hero remains uncluttered — but it's mandatory before any localStorage writes happen, so consent is genuinely informed, not coerced.

Click to enlarge

Sign-in screen with passwordless and social auth options

Why this screen exists

The biggest adoption blocker in the typing-app category is the sign-up wall — most users want to try the product before committing an account. CosmicKeys offers 5 sign-in paths so each user picks the path of least friction for them, and crucially, Guest mode lets them practice with zero account at all, their progress kept in XOR-encrypted localStorage and migratable to a real account later if they decide to stay. The signal to the user is: we're confident enough in the product that we don't need to trap you behind a form.

▶Design nuances most visitors miss(6)

• The 3 OAuth providers (Google, GitHub, Microsoft) cover almost the entire population that already has some account at a major identity provider — Microsoft is non-optional for European/enterprise users where Microsoft accounts dominate.
• Magic Link uses Resend as the email-send vendor rather than the enterprise defaults (SendGrid, Postmark, SES) — Resend's developer-first API and Tailwind email templates suit a solo developer's stack, a pragmatic vendor pick that beats the enterprise default for this use case.
• Guest mode creates a phantom user whose XOR-encrypted localStorage progress migrates atomically to a real account on signup — an explicit Sam intervention added an anti-abuse guard so that delete-then-restore cycles can't be used to game guest privileges back into the account model.
• “Try without sign-up” is visually equal to the OAuth buttons — no dark pattern relegating it to small grey text below the fold; the platform genuinely wants you to take this path if it's lowest friction for you.
• After the user picks any path, the pre-signin intelligence (OS, keyboard, language) is already in the session, so the first lesson loads with correct keyboard layout and voice — no configuration wizard interrupts the flow.
• All 5 paths land the user on the same dashboard with the same state — auth method is a transport concern, not a feature toggle; a guest who signs up later doesn't see a different product.

▶What each hat contributed(5)

• 🎯#1 Product Manager · Designed the Guest → Registered → Subscriber state machine and insisted Guest mode be a first-class path, not a buried “skip for now” — iterated 3 rounds with AI until the anti-abuse guard for delete/restore cycles was in.
• 🤝#11 Localization Lead · Translated every label, error string, and email template (magic-link subject, body, button copy) into all 7 languages so a German user who clicks “forgot password” gets a German email, not an English one with their name in it.
• 🎯#13 Security Engineer · Ran 3-AI security audits on the auth module (Claude + Gemini + Codex independent passes) and triaged findings — accepted 4 real issues, rejected 2 false positives; e.g., the session-cookie SameSite policy was confirmed strict.
• 🤝#15 Integration Engineer · Integrated all 5 auth surfaces: 3 OAuth providers with different scope and redirect patterns, the Resend magic-link send/verify/callback flow, and the guest phantom-user creation path with XOR localStorage migration.
• 🤝#16 Privacy & Compliance Officer · Built explicit consent capture for the account creation path (account, IP, UA, document-version) so the GDPR audit trail can answer “what did this user consent to and when” for any regulator request.

Every screenshot above. Every architectural decision below. Every line of those 155,000 lines. Producing a platform of this scope solo requires wearing 20 professional hats simultaneously. Each one shows up in the codebase as concrete artifacts — components, modules, infrastructure, tests, lessons, voices, legal pages. Here are the hats this particular build needed.

But not every hat represents twenty years of personal expertise — and that's the point of the tango. Some hats can only be worn by someone with deep personal experience (🎯). Others require knowing the domain abstractly enough to lead the dance while AI brings the implementation depth (🤝 — the human provides the goal and the judgment, AI provides the domain depth). The mix below is what one specific build looked like; the mix for a different product would be different.

All 20 Hats · Each a Verse in the Dance

The 20 hats above explain the choreography. This section explains the tools that made executing the dance at production scale possible — custom skills, multi-AI code review, and an institutional memory that survives session crashes.

14 Custom Claude Code Skills · Replacing a Team

Each skill is a reusable automation workflow triggered by natural language. Together they cover what a traditional 5-person team would distribute across roles.

10 of the 14 shown. Each replaces a workflow that a 5-person team would distribute across roles.

The LLM Council · Three Models, One Voting Bench

I call this pattern the LLM Council: Claude Code is the primary architect and code-generation agent that produces the work; Gemini and Codex are engaged as LLM reviewers on what Claude Code generated. Three different models trained on different data with different priorities — their blind spots don't overlap, which is the whole point. Before every major deployment, the ai-partner-review skill delegates the diff to the Council and synthesizes the consensus; I triage the findings the way a tech lead triages PR comments. This is the entire LLM-usage story for CosmicKeys — happens at development time, never deployed. The one runtime LLM call the deployed app makes is Google Gemini for support-ticket translation, and that's treated like any other external API integration (Stripe, Resend) — not as LLM SDK plumbing.

Session Recovery · Crash-Proof Development

Claude Code sessions have finite context windows. When a session hits its limit or crashes, the next one can resume exactly where the previous one stopped by reading four sources:

• .claude/SESSION_STATE.md — current work state, files changed, verification checklist
• .ai-context/diagrams/*.md — 21 mermaid diagrams providing architectural context
• CLAUDE.md — project root instructions, full orientation for a new session
• ~/.claude/projects/<path>/memory/ — user-specific context that persists across all sessions

A new Claude session reads all four and can resume mid-deployment — including verifying a deploy that the crashed session was monitoring. This replaces the “team wiki + onboarding doc” overhead that traditional teams maintain.

Most consumer products either ship ads or paywall the experience. CosmicKeys does neither. The economics are intentional.

What This Looks Like In the Product

The actual subscription management screen — clear pricing, instant downgrade, no dark patterns. Click to enlarge.

Click to enlarge

Manage Subscriptions — the tiers, the prices, and a single click to change between them

Why this screen exists

Two things are happening on a subscription page that often get conflated: the user wants to change their billing state (upgrade, downgrade, cancel), and the company wants to keep PCI scope as small as possible. Most apps optimize the first against the user (friction-as-retention) and ignore the second until they get audited. The cleaner design separates them: the page itself should remove every dark pattern between the user and the action they came to take, and the payment data path should stay outside your servers entirely via a hosted checkout like Stripe Checkout. Those two decisions compound — the simpler the page, the easier it is to keep PCI scope minimal because there's less custom code to audit.

▶Design nuances most visitors miss(5)

• Current plan is highlighted with a check + “Your plan” label so the user always knows where they are; available plans show their price and feature delta from current, not a marketing comparison table.
• Downgrade is a one-click action with one confirmation (“Are you sure? Your subscription will end on X”) — no retention survey, no “Wait! Here's a 50% discount” popup, no dark-pattern friction designed to trap the user.
• Upgrade flows through Stripe Checkout (no custom payment form), so the user's card data never touches CosmicKeys' servers — keeping PCI scope minimal by staying out of the payment data path, which is what solo developers should do unless they have a specific reason not to.
• Multi-currency pricing is automatic via MaxMind GeoIP (embedded in Docker) — a German user sees EUR, a Norwegian user sees NOK, a Swiss user sees CHF, a US user sees USD, with regional pricing power-parity adjustments calibrated to the seven supported-language markets.
• Invoice history is listed below current plan with one-click PDF download via Stripe — every charge is documented and accessible without a support ticket, which is rare in the consumer-SaaS world.

▶What each hat contributed(4)

• 🎯#1 Product Manager · Drew the line on no retention-survey dark patterns even if it costs short-term retention — the page's simplicity is itself a trust signal that compounds across every other surface in the product.
• 🤝#3 UX / UI Designer · Designed the “Your plan” highlight + plan-delta comparison so the user can see at a glance what changes if they upgrade or downgrade — no marketing-table arms race with feature checkmarks.
• 🤝#15 Integration Engineer · Integrated Stripe Checkout + webhooks for the upgrade path and Stripe Customer Portal for invoice download — leveraging Stripe's infrastructure rather than rebuilding billing UI from scratch.
• 🤝#16 Privacy & Compliance Officer · Confirmed that subscription-cancellation triggers GDPR-compliant data-retention rules — billing info is retained for 7 years for tax compliance, typing analytics fall under the standard 30-day deletion window if the user also deletes account.

You've now seen the surface — the lessons, the analytics, the polish. When people visit cosmickeys.app they see a beautiful typing practice platform with animated finger guides. What they don't see is the production architecture underneath: a multi-region setup across three Cloud Run regions (US, EU, Asia), a voice narration pipeline that pre-generates audio lessons in seven languages (ElevenLabs TTS, baked at content-release time), a client-side analytics layer that captures every keystroke and persists it to both localStorage and the database, and a deterministic adaptive-lesson selector that scores curriculum candidates against each learner's stored error patterns.

This is the part most engineers wave off with “just put it behind Cloudflare.” That works until you have stateful services, database write consistency, and region-specific localization. I designed a deliberate routing strategy that handles all three.

Three Problems the Traffic Cop Solves

Localization is usually treated as an afterthought — a post-launch “internationalization” project. I designed it as a first-class architectural concern from day one because retrofitting i18n into a typing platform (where literally every character on the screen has to localize) is a nightmare.

The Languages (8 selector entries · 7 base languages)

Source of truth: SUPPORTED_LANGUAGES in frontend/lib/languageDetection.ts — the 8 entries map to 7 base languages because English has separate US and UK variants (each with its own default keyboard layout: ANSI for US, ISO for UK).

Localization Scope — Beyond UI Strings

One of the features that gets zero credit from first-time visitors is the voice narration system. Every instructional prompt — “place your left index finger on F, your right index on J” — has a professionally-generated audio variant in every supported language.

Every keystroke is captured in the browser. WPM, accuracy, error patterns, and per-key heatmaps are all computed client-side — instantly, with zero network round-trip — and rendered to the UI as you type. The same data is persisted twice: in localStorage for session resilience, and in the backend database for cross-device access and long-term analytics.

The Capture & Persistence Pipeline

What Gets Captured and Persisted

Up front: there is no runtime LLM call in this loop. The deployed app does not make any inference calls for lesson recommendation — the “adaptive” behavior is deterministic code consuming rich analytics that are computed in the browser and persisted to the lesson_attemptstable at lesson completion. The intelligence lives in the analytics design and the curriculum, not in an inference call.

(Claude is part of the dev-time workflow — Claude Code as Sam's primary architect and code-generation agent in the LLM Council pattern (Claude Code as primary + Gemini and Codex as LLM reviewers) — but none of these are invoked at runtime by the deployed CosmicKeys app. The deployed app's one external AI-related call is to Google Gemini for support-ticket translation only; details in the support flow above.)

Most of failover on CosmicKeys is “GCP handles it within the region.” The interesting part — the part that's actually a design decision rather than a vendor-provided default — is the one place we deliberately chose data integrity over cross-region failover. Here's what each layer actually does when something breaks.

A handful of architectural choices that distinguish “built a thing” from “built a thing the right way” — the kind of decisions that don't show up in a feature list but do show up in a postmortem when the wrong one was made.