DEV Community: AurinAilean

Der Pivot um 04:30 — Eine Solo-Dev-Nacht mit KI

AurinAilean — Sat, 20 Jun 2026 07:31:00 +0000

Gestern Abend hatte ich keine Unity-Installation und einen Schreck mit einer 59 €-Token-Rechnung. Heute Morgen um 06:00 läuft ein Götter-Spiel mit einem Affen-Avatar, einem Marmor-Tempel und einer Vision, die schärfer ist als alles, was ich je auf Papier gebracht habe.

Das ist die Geschichte einer 9-Stunden-Solo-Nacht, in der ich mehr über Game-Design gelernt habe als in den letzten zwölf Monaten. Vor allem über mich und meinen AI-Partner.

20:00 — Wo es begann

API-Key-Leak in einem Railway-Deployment, Bot-Crawler triggerten Übersetzungen, 59 USD weg. Key revoke'd, Spend-Limits gesetzt, durchgeatmet.

Status: Mac, Claude Max-Plan, eine Idee. Ein Götter-Spiel inspiriert von Black & White (Lionhead, 2001), mit 6 mythologischen Tier-Avataren — Affe (Hanuman-Geist), Wolf (Anubis), Löwe (Sphinx), Elefant (Ganesha), Ochse (Minotaurus), Jaguar (Maya).

Plan: Unity installieren, Charaktere mit Meshy.ai generieren, Claude Code als Coding-Partner, Claude Chat als Architekt und Sparring.

02:00 — Der Affe steht im Tempel

In sechs Stunden lief das hier durch:

Unity Hub + Unity 6.5 + iOS/Android/WebGL-Module
Claude Code 2.1 (Max-Plan, kein API-Cost extra)
24 Charaktere via Meshy, je vier Moral-Varianten
~80 Animationen pro Charakter (Kampf, Tanz, Akrobatik, Sozial)
Unity-Projekt mit 17 Namespaces, asmdef-sauber, keine Cycles
34 C#-Skripte mit ScriptableObject-Pattern und GOBT-AI-Stub
Fünf Docs: CLAUDE.md, ARCHITECTURE.md, ROADMAP.md, CONVENTIONS.md, PERFORMANCE.md
Eine IDENTITY.md mit Farb-Trias, Anti-Patterns und kulturellen Respekt-Regeln

Um 02:00 lief der erste Play-Mode: weißer Marmor-Tempel auf grüner Wiese, ein Goldfinial drauf, zwei Affen daneben, Faith-Counter zeigt „Glaube 0".

A-Pose noch. Aber sichtbar. Es funktionierte.

04:30 — Der Pivot

Ich wurde übermütig. Bat Claude um eine vollständige Asset-Liste: „Häuser, Werkstätten, Berufe, Schulen, alles."

Bekam ein 601-Zeilen-Dokument zurück: 53 Gebäude, 18 Berufe, 12 Ressourcen, eine Wirtschafts-Kette von Erz über Schmiede zu Werkzeug, eine 7-Phasen-Roadmap über 12 Monate. Mit recherchiertem Hintergrund aus Black & White 2, Settlers, Banished, Manor Lords, Anno 1800.

Erst war ich begeistert. Vollständig! Tabellen! Phasen!

Dann las ich es nochmal — und es klickte: Das war kein Götter-Spiel. Das war Settlers mit Mythologie-Skin.

Ich schrieb zurück: „Analysier alles nochmal und sag mir, was wirklich nötig ist, um den Kern von NUMEN hervorzuheben. Inklusive Lob und Kritik an dem, was du gerade getan hast."

Claudes Antwort begann mit: „Du hast recht. Ich hab dich in den Settlers-Modus gezogen."

Es folgte eine selbstkritische Analyse plus eine überraschende Erkenntnis:

NUMEN's Kern-Verb ist nicht TUN. Es ist ZEUGE SEIN.

Animal Crossing, Tamagotchi, Black & White — alle bauen auf einer Welt mit Gedächtnis. Du bist nicht Chef, du bist Zeuge. Das ist die Marktlücke. Das ist NUMEN.

06:00 — Was bleibt

Nach dem Pivot:

53 Gebäude → 6 Gebäude (Tempel, Hütte, Schrein, Versammlungsplatz, Avatar-Statue, Friedhof)
18 Berufe → 2 Rollen (Bewohner + Erwachte)
12 Ressourcen → 1 Ressource (Glaube)
7 Phasen → 4 Phasen, 12 Monate bis Release
Eine schlanke CORE_VISION.md ersetzt das aufgeblähte alte Doc
Ein Master-Prompt für Claude Code mit eingebautem Filter: „Dient dieses Feature dem Bezeugen?" — vor jedem Feature anzuwenden

Die fünf Säulen, die NUMEN tragen sollen:

Ein Kern-Verb: gesture-and-watch
Eine Welt mit Gedächtnis (NPCs erinnern sich)
Stille zwischen Aktionen ist erlaubt (Aquarium-Modus)
Visuelle Transformation statt XP/Coins
Kulturelle Tiefe als Identität, nicht als Skin

Was ich aus dieser Nacht mitnehme

AI-Tools machen Solo-Dev brutal schnell — aber sie biasen Richtung Feature-Stapeln. LLMs wollen helfen, indem sie Listen liefern. Du musst aktiv „weniger" sagen, sonst kriegst du ein Verwaltungs-Strategiespiel statt deiner Vision.

Der schwerste Teil von Game-Design ist nicht das Bauen. Es ist das Streichen.

Behandle deinen AI-Partner wie einen Design-Sparrings-Partner, nicht wie einen Code-Generator. Frag „was ist wirklich wichtig?" und „was war schlecht?" — nicht nur „bau mir X". Das beste Ergebnis kam aus dem Moment, in dem ich Claude widersprach.

Vertrau dem Bauchgefühl. Wenn die KI dir eine schöne Tabelle gibt und du fühlst dich trotzdem unwohl — push back. Hörbarer Widerstand vom Menschen ist genau der Input, den ein guter AI-Partner braucht, um besser zu werden.

Phase 1 wird heute Abend fertig (Mac-Build). Phase 2 startet morgen früh.

NUMEN bezeugt. NUMEN baut nicht.

Wenn du das Projekt verfolgen willst: ich werde unregelmäßig Devlogs hier posten. Frage, Kritik, Mitfiebern alles willkommen.

I'm a web dev who has never touched 3D. Here's my first creature.

AurinAilean — Sun, 14 Jun 2026 18:56:04 +0000

New project, and I'm starting it the same way I start everything: slightly out of my depth, in public.

I build web things. TypeScript, the browser, 2D canvas — that's home. The new project, NUMEN, is a god-game: you raise a creature and a little world grows around it. Which means for the first time I need 3D. And I have never made a single 3D model in my life.

So this post isn't a tutorial. It's day one.

The first thing I did was generate a creature with Meshy — text and an image in, a .glb model out. A cow, in three versions: gentle, neutral, and a darker one for when the creature gets raised badly. Twenty minutes ago they didn't exist; now they're sitting in my assets folder, rotating in a viewer, looking back at me.

Here's the honest part, the thing I want to remember when this gets hard: getting a model out was easy. That's not the work.

Two things hit me immediately:

One model isn't a world. A cow that looks great alone means nothing if the temple, the trees, and the terrain all look like they came from different games. The actual skill I have to learn isn't "generate a creature" — it's keeping a whole world consistent. One style, every asset, or it's just a bag of mismatched outputs.
It's not even in the game yet. My renderer is still a 2D placeholder. These .glb files are raw material, not a running scene. Wiring them into an actual 3D engine is the next mountain, and I haven't climbed it.

So I'm not going to pretend I've "added 3D to my game." I made one creature. The renderer's still 2D. I don't know yet if I can pull the art of a whole world together as a solo dev who learned 3D yesterday.

But there's a cow standing in 3D space that wasn't there this morning. For day one, that's enough to keep going.

If you've made the jump from 2D/web into 3D: what's the thing you wish someone had told you on day one?

My analysis engine has two brains now

AurinAilean — Sat, 13 Jun 2026 18:19:50 +0000

The thing I'm building, App Store Analyzer, is a website that does one thing: it reads an iOS niche and writes a deep market analysis for indie devs. For a long time that analysis had one brain — and it spoke German.

That made sense at the start. German is my home market and my own language, so I built the analysis logic in German first. I could actually feel whether the output was good or garbage, section by section, because I was reading it in the language I think in. It got deep. Reliable. I trusted it.

Then it started to hurt.

Every time I wanted the analysis in another language, I was basically running the whole expensive thinking step again from scratch. German code, German slugs, German routes, German everything — and a goal of serving 14 languages. The whole thing fought itself.

So I rebuilt the brain in English. Not "translated the code" — rebuilt the canonical brain so English is the one source of truth. Now the engine thinks once in native English, and that single analysis gets translated and cached into 13 other languages. Generate once, translate many.

It was not a clean ride.

The lows. A refactor left a pile of undefined names and quietly 500'd my detail pages — live, in production, while I thought everything was fine. I misread a normal cache warm-up window as a dead backend more than once and "fixed" things that were never broken. I spent an embarrassing stretch hammering an endpoint with a wrong key, watching 403 scroll by, before realizing my terminal had eaten the line that set the key. Small things. Hours each.

The highs. Two of them I didn't expect:

It got cheaper, not just cleaner. I'm not paying for a full deep analysis per language anymore — one real generation, then lightweight translations. For a solo dev watching every API cent, that's the whole game.

And the English brain was actually sharper. I ran the old German output against the new English one side by side, fully expecting English to be the weaker copy. It wasn't. In a few sections it was tighter and clearer than the original. The German one stays native too — home market, my voice — but English is now the spine everything hangs off.

I'm not going to pretend I planned this cleanly. This is my first real project and I'm building it with AI as my pair, learning the architecture as I trip over it. The "one canonical language, translate outward" idea is obvious in hindsight. It was not obvious at 11pm three deploys deep with production throwing 500s.

If you're building something solo and multilingual: pick your canonical brain early. Future-you will thank present-you.

Building in public — would love to hear how others handle the multi-language cost problem. 🌍

Coming back to your own project after a week feels like onboarding a stranger

AurinAilean — Fri, 12 Jun 2026 18:07:35 +0000

You take a week off. You come back, open the repo, and for about twenty minutes you are a complete beginner in a codebase you wrote yourself. The function names look vaguely familiar. You're sure past-you had a plan. You just can't remember what it was, or which of the seventeen markdown files on your desktop is the one that's actually current.

If you build solo, especially with AI assistants doing a lot of the typing, this feeling is sharper than it used to be. The code moves fast. Your memory of why it moves does not.

Here's what I've learned: the thing you lost over the week isn't skill. It's context. And context is recoverable if you treat it like a first-class artifact instead of something that lives only in your head.

The trap: trusting your own notes

I keep a checkpoint document. After every session I write down where things stand, what's next, and the open threads. Coming back, that doc is the single most valuable file in the project. It is also a liar.

Not on purpose. It just goes stale. I came back this week, opened the checkpoint, and it told me a specific cleanup job had ~215 items left in one place and ~154 in two others. Concrete numbers. Easy to plan around.

So I almost planned around them. Then I ran the actual check against the code instead of the note. The real numbers were lower. Work had continued after the note was written, and the note never caught up. If I'd trusted it, I'd have scoped a sprint against figures that were days out of date, and wondered later why nothing added up.

The lesson isn't "stop taking notes." Notes are how you rebuild context in minutes instead of hours. The lesson is: a note is a hypothesis, not a fact. Coming back from a break is exactly when you're most tempted to skip verification, because the note feels like memory. It isn't. It's a snapshot of a moving thing.

A re-onboarding ritual

After a few of these returns, I stopped winging it and made the first 30 minutes a fixed routine:

Read the checkpoint. Get the story back: what shipped, what's next, what's blocked.
Diff your branch against the source of truth. git log HEAD..origin/main. Your local state is almost always behind where you think it is. This one command erases half the confusion.
Verify the top one or two claims against the code or production — not the note. Pick the things your next decisions depend on and check them at the source. This is where the stale-note traps get caught.
Ship the smallest real slice you can. Don't start with the scary architectural item. Find one bounded, self-contained piece, finish it end to end, and merge it. You're not doing it for the feature. You're doing it to get your hands back on the wheel.

That last step is the underrated one. The newbie feeling doesn't go away by reading more. It goes away by shipping something small and watching it work. Momentum is a context-recovery tool.

For the AI-assisted builder specifically

If an assistant is writing a lot of your code, your leverage is no longer typing speed. It's the quality of the context you can hand back to yourself — and to the model — when you sit down again. The builders who stay fast across breaks aren't the ones with the best memory. They're the ones with the best re-onboarding ritual and a checkpoint doc they're disciplined enough to distrust.

So write the checkpoint. Then, every time you return, verify the part that matters against the code before you build on it. The twenty minutes of feeling like a stranger is unavoidable. Spending the next twenty acting on a stale note is not.

Take the week off. Just don't trust the version of the project that existed before you left.

I shipped the product. I have no idea how to launch it. Tell me about your first time.

AurinAilean — Sat, 06 Jun 2026 13:43:11 +0000

For the past two weeks I've been head-down in code. 5400 lines refactored across 20+ PRs. Persistent job queue migrated to Postgres. Rate-limiting deployed. Voice-source pipelines fixed (two of them had been silently returning zero for months — that was a fun discovery). API documentation polished. Test coverage on the testable logic up to 70%.

The engineering work, I get. I can sit down with Claude Code at 1 AM and have a sensible PR in the morning. I can read a stack trace. I can grep my way out of any backend mystery in about 20 minutes. Code is a language I speak fluently enough.

What I cannot do — and I'm two weeks pre-launch on App Store Analyzer realizing this — is launch a product to actual humans.

I don't know where people who would care about my tool hang out, or how to get there without being the guy who shows up to a community for the first time with a link. I don't know the cadence — post how often, where, when. I don't know what works and what just looks like work. Even with AI assistance, the launch playbook isn't something I can grep my way through. There's no error message that says "you posted on the wrong subreddit at the wrong hour."

So I want to ask the indie devs here who've already been through this:

Tell me about your first launch.

Not the success-story-clip-version. The actual version:

What did you do in the week BEFORE launching that you'd do again?
What did you try that completely flopped — and you laugh about now?
Where did your first 10 real users come from? (And how did you know they were real and not curious tourists?)
What surprised you about how it actually felt — better than expected, worse, weirder?
If you could go back to the week before your first launch and tell yourself one thing, what would it be?

I'm asking because I think I can build a useful tool. App Store Analyzer aggregates demand signals across 20 App Store markets and 50+ niches for indie iOS devs deciding what to build next. The engineering is solid now. But solid engineering doesn't find users.

And honestly: launch stories are the kind of thing I think most of us love to tell once enough time has passed. The good parts, the embarrassing parts, what you'd do differently. There's no advice or research that beats hearing what someone actually went through. So this isn't really a "give me tips" post — it's a "tell me your story" post.

Drop yours. Long or short. First project, second, third — doesn't matter. I'll read every one. And in two weeks I'll write a follow-up with the patterns I see: what looked completely different across stories, and what was weirdly the same.

— Aurin

My Next.js 16 button was visible and completely dead in production. Here's why.

AurinAilean — Fri, 05 Jun 2026 21:55:21 +0000

I added a tiny test page to confirm my error monitoring was capturing frontend crashes. A title, a paragraph, one red button that throws an error on click. The kind of code you'd send to a code review and apologize for being trivial.

Locally: worked perfectly. Click, error, captured, done.

In production: the button rendered. Click did nothing. No error in the console. No network request. No visible feedback. Just dead HTML that looked exactly like a button.

I'm a solo dev building an iOS market intelligence tool, and this bug burned an hour of my pre-launch sprint. The cause is a real Next.js 16 trap. The fix is well-documented. The path between "this should work" and "ah, it's this" is what I want to write about — because the same shape of bug is going to bite a lot of people once Next 16 spreads.

What I had

"use client"
import { useSearchParams } from "next/navigation"

export default function SentryTestPage() {
  const key = useSearchParams().get("key")

  if (!key) return <LockedScreen />

  return (
    <button onClick={() => { throw new Error("test crash") }}>
      Trigger crash
    </button>
  )
}

A page that reads a ?key= query param. If the key is missing, it shows a locked screen. If present, it shows the button. Trivial.

In production with ?key=... in the URL, the button rendered. But nothing happened on click. No event, no error, no log. The button was a div pretending to be a button.

What I tried first (and why each was wrong)

Theory 1: The env variable isn't set.

I thought maybe NEXT_PUBLIC_SENTRY_DSN wasn't actually present in the build. So Sentry never initialized, so when I threw an error there was no one to catch it. I checked Vercel. The variable was there. I re-deployed without build cache to make sure. Still dead.

This was the right thing to check — NEXT_PUBLIC_* vars are inlined at build time, and adding them later doesn't help unless you rebuild. But it wasn't the bug.

Theory 2: A floating widget is overlaying the button.

The app has a feedback button fixed to the bottom-right corner. Z-index issues are a classic source of invisible click eaters. I inspected. The button received pointer-events: auto. Nothing was on top. Not it.

Theory 3: The build is stale.

Hard-reload with Cmd + Shift + R. Then incognito. The button still didn't respond. Not the cache.

Theory 4: React just isn't hydrating the page.

This was closer. If React fails to hydrate a subtree, the HTML is there but the JavaScript event handlers never attach. That'd look exactly like what I was seeing.

What the actual bug is

Next.js 16 (and 13+, but it's stricter in 16) requires that any component reading useSearchParams() be wrapped in a <Suspense> boundary. Without it, here's what happens:

During server-side rendering, useSearchParams() returns an empty params object. The component renders the "no key" branch (<LockedScreen />).
On the client, the URL has ?key=..., so useSearchParams() returns the params, and the component wants to render the "button" branch.
React tries to hydrate the server HTML and finds a mismatch: the server rendered <LockedScreen />, the client wants to render the button.
React aborts hydration for that subtree. It logs a warning during development (if you're watching the console) but in production it just stops.
The HTML the server sent — including whichever branch happened to be there — stays in the DOM. But no event handlers ever attach.

That last point is the cruel part. In my case the server had rendered the locked screen, but my browser then swapped to the button in the DOM via... actually I'm not entirely sure how the button appeared at all, given the hydration was supposed to be aborted. I suspect a streaming SSR quirk where the client did render the button but React refused to wire it up. Either way: the button I saw was dead HTML.

It worked locally because dev mode uses a different hydration strategy that is more forgiving of mismatches — it logs the warning and patches the DOM. Production mode does not.

The fix

The documented Next.js 16 pattern is to put the useSearchParams() call inside a child component, and wrap that child in <Suspense>:

"use client"
import { Suspense } from "react"
import { useSearchParams } from "next/navigation"

function PageContent() {
  const key = useSearchParams().get("key")
  if (!key) return <LockedScreen />
  return (
    <button onClick={() => { throw new Error("test crash") }}>
      Trigger crash
    </button>
  )
}

export default function SentryTestPage() {
  return (
    <Suspense fallback={null}>
      <PageContent />
    </Suspense>
  )
}

Why this works: <Suspense> tells React that the wrapped content might not be ready during initial server render. The server emits the fallback (null), and the client renders the real content. Because the server doesn't commit to a branch, there's no mismatch to resolve. The client takes over cleanly, the button hydrates, the onClick attaches.

After this fix the button worked on the first deploy.

What I should have done first

The build log was actually telling me. Next.js prints a warning during production builds when a page uses useSearchParams() without <Suspense>:

Entire page deopted into client-side rendering. Read more: ...

I didn't see it because I was looking at runtime logs, not build logs. If I'd grep'd the build output for deopted, I would have found this bug in 30 seconds instead of an hour.

So the rule I'm internalizing:

When something works locally and breaks in production, read the build log first. The framework probably already told you what's wrong. You're just not looking where it told you.

A close second:

When a React event handler doesn't fire, suspect hydration before suspecting your code. The button isn't broken — the path from rendered HTML to JavaScript-wired DOM is broken. Different debug target, different fix.

The pattern that made this worse than it needed to be

I had an AI pair (Claude Code) writing most of the actual edits during this sprint. The AI is very good at producing plausible code fast. When I told it to add a test page with useSearchParams() and a button, it wrote code that worked in dev mode — which is what AI training data is full of, because most demo apps run in dev.

The Suspense boundary requirement is the kind of detail that lives in framework upgrade guides, not in tutorials. Training data doesn't catch it. I have to.

The lesson isn't "AI bad." The lesson is that AI is great at execution and dangerous at diagnosis. It can write the next line of code as fast as I can read it. But when something is wrong, it tends to confidently propose plausible explanations. If I act on the plausible ones without verifying, I waste an hour. If I reproduce first — actually click the button, actually read the build log — the wrong explanations get killed in three minutes.

That's been the meta-pattern across every bug in this sprint. Plausible was wrong. Reproduction was right. Three minutes of curl/click/grep beat three hours of "let me try this fix."

Why I'm writing this

I'm Aurin. I'm building AppStoreAnalyzer — a tool that scores 50+ iOS app niches across 20 markets, so indie devs can see which niches have room before they spend three months coding. It's pre-launch. I'm writing a build-in-public log as I get to launch.

This is post one. If you build iOS apps and want to look at niche data, the explorer is free and there's no signup wall. If you ever hit a Next.js 16 hydration bug, hopefully this post saved you an hour.

More posts as the launch gets closer. If this bug made you wince in recognition, we'd get along.