The Codex + Moonchild Workflow For Building Apps That Don’t Look Vibe-Coded.

Most builders are still shipping AI apps that look like AI apps. The kind every user spots in two seconds.

Some are paying designers $5K to $10K per project just to keep their UI from looking like slop.

And then there’s a small group of agencies and solo builders who figured out the real fix. It isn’t a better prompt. It isn’t a better model. It’s a system underneath the model.

At @ignytlabs we have shipped 60+ MVPs in the last 1.5 years. Across every single project, the part that decided whether the app shipped on time or dragged for weeks was the same. The design system underneath it.

We learned this the hard way. Now we run it on every client.

If you read my last Moonchild article, you saw the full Codex + Moonchild workflow we run end to end. The first step in that workflow was simple. Build your design system before you touch a screen.

Almost every reply on that article asked the same question.

Okay, but how do I actually build a great one?

This article is the answer.

For this walkthrough I built Pulse, a fitness and wellness tracking mobile app. Full design system in under 30 minutes. Every component. Every variant. Every token. Ready to feed straight into Codex.

This is the playbook we now run on every client at @ignytlabs.

Here is the full breakdown.

All the screens of Pulse. The running example for this walkthrough.

All the screens of Pulse. The running example for this walkthrough.

What Moonchild Actually Is (Quick Refresher)

If you missed the first article, fast version.

Moonchild is a chat-powered design canvas built around your design system. Not a blank prompt. Not a screenshot. Your actual system.

You bring a system in. You paste a PRD. It generates full screens against the system. Then it ships those designs straight into Codex through an MCP connection. Codex reads structured design data and writes the code.

Article 1 covered the full workflow. This article zooms into the part nobody else has explained well. How you actually build a great design system inside Moonchild in the first place.

Moonchild design system on the left. Codex CLI on the right. Both connected via MCP.

Moonchild design system on the left. Codex CLI on the right. Both connected via MCP.

Why Apps Look Vibe-Coded

Here is what most builders get wrong.

They think the reason their app looks vibe-coded is the AI. So they switch models. They prompt harder. They paste reference screenshots. The output gets slightly better. Then drifts again on the next screen.

The model isn’t the problem.

Codex has no idea what your design language is. Every prompt is a fresh context. Every screen is a guess. Every component drifts from the last one. The colors shift. The typography shifts. The spacing shifts. By the fifth screen the app looks like five different products stitched together.

This is what people see when they say an app looks AI-generated.

The fix is upstream of the prompt. You give Codex a real system to follow. Then you give it the actual design to build.

Most workflows give it one or the other. Moonchild plus the MCP connection gives it both.

But none of that works if the system itself is weak.

Which brings us to the real question.

What A Real Design System Actually Is

Most builders think they have a design system. They don’t.

A Figma file with three color tokens and two button styles is not a system. A Notion doc with brand guidelines is not a system. A screenshot of a Dribbble shot you liked is definitely not a system.

A real design system has four layers:

→ Tokens. Your color palette, typography scale, spacing scale, and elevation rules. The atomic decisions everything else builds on.

→ Component library. Every interactive piece your app needs, designed once and reused everywhere. Buttons, cards, badges, inputs, navigation, modals. Each one with its full set of variants.

→ Gallery view. Every variant of every component rendered side by side so you can see the family at once. This is the part 95% of builders skip and it’s the single biggest unlock.

→ Rules. When to use the primary button vs the secondary. When a card gets an elevation. When a badge is solid vs outline. The decisions that keep your app consistent across 50 screens.

If you have all four, you have a system. If you only have tokens, you have a starting point. Most builders never get past the starting point.

Moonchild’s job is to get you all four in 30 minutes.

Here’s how.

Step 1: Pick Your Input Path

This is where most builders freeze. You don’t need to start from scratch every time. Moonchild gives you five paths in.

→ Import from Figma. If you already have a Figma file with tokens and components, paste the link. Moonchild reads the structure and imports it as a unified system.

→ Import from GitHub. If your design tokens or component library lives in a repo, point Moonchild at it. Same idea.

→ Import from a live URL. Drop in any production website or app. Moonchild extracts the visual language and rebuilds it as a system inside the canvas.

→ Drop in design inspiration. Three to five screenshots from Dribbble, Mobbin, or any source you like. Moonchild extracts the design language from the references and builds the system from scratch. This is what I used in Article 1 for Haven.

→ Use the Agentic Design System Builder. Describe your brand to Moonchild. It generates the full system from a written brief. Best when you don’t have a starting reference yet.

For Pulse I went with the Agentic Design System Builder. Pulse is a fitness brand and I had a clear written brief in my head. Bold and dark-first energy. Warm cream canvas. Dark charcoal cards floating on top. Vibrant orange as the energy color, reserved only for CTAs, progress, and achievements. Satoshi as the typeface for sharp contemporary feel. Photo-led hero blocks. Premium athletic vibe. I dropped that brief into Moonchild and let it generate.

The brief took me 30 seconds to write. The system took Moonchild about 4 minutes to generate.

The agentic design system builder in action.

The agentic design system builder in action.

Step 2: Generate The Foundation

Once your input is in, Moonchild generates the foundation.

This is the layer everything else stands on. Get it right and the rest of the system clicks. Get it wrong and every screen will fight you.

For Pulse, Moonchild generated:

→ Color palette. Two surface contexts. A warm cream canvas (sand tones from off-white through soft beige) for the light side, and dark charcoal (near black) for cards and containers that sit on top. Vibrant orange as the single energy color, reserved for CTAs, progress fills, and active states. Status colors deliberately sit outside the orange family: teal for success, amber for warnings, red for errors. Every color came back with a hex value and a semantic name (primary, accent, surface, danger) so I could reference them by purpose, not by color.

→ Typography scale. Display, H1, H2, H3, body large, body, caption. Each with line heights, weights, and letter spacing baked in. Satoshi as the family throughout. Sharp contemporary feel with a great weight range that handles everything from tiny labels to oversized hero stats.

→ Spacing scale. A clean 4px-based scale (4, 8, 12, 16, 24, 32, 48, 64, 96). Every margin and padding in the rest of the system pulls from this scale. No magic numbers.

→ Elevation system. Five elevation levels with pre-defined shadow rules. So a card at elevation 1 looks the same on every screen.

What surprised me is how previewable the foundation is. Most AI tools, including Stitch in my older article, hand you a flat token file. Colors. Fonts. Maybe spacing. Moonchild does something different. It renders the foundation against real components so you can see how it will actually feel. You spot weak contrast or off-balance scales before they ship.

This is the moment you make corrections. I bumped Pulse’s charcoal cards a touch darker for stronger contrast against the cream canvas, and pulled the orange accent slightly more saturated so it punches harder on dark surfaces. Two-line edit. Whole system updated.

Pulse design system | Foundation + Colors + Typography.

Pulse design system | Foundation + Colors + Typography.

Step 3: Build Out The Component Library

The foundation is the floor. The component library is the room.

This is where most builders fall apart. They generate three buttons and call it a system. Moonchild generates the full library at once. For Pulse that meant:

→ Buttons (primary, secondary, ghost, destructive, plus icon-only and sizes)

→ Cards (workout card, achievement card, leaderboard card, stat card, profile card)

→ Badges (active, completed, locked, streak, intensity, plus all sizes)

→ Inputs (text, number, dropdown, search, plus all states: default, focus, error, success, disabled)

→ Navigation (bottom tab, top app bar, segmented control, breadcrumb)

→ Lists (workout history, friend list, exercise list, plus dividers and grouped variants)

→ Charts (progress ring, line chart, bar chart, heatmap)

→ Modals and sheets (bottom sheet, full-screen modal, toast, alert)

Every component came back with its full set of variants and every state pre-rendered.

The unlock here is that Moonchild doesn’t just draw the components. It builds them as live, interactive elements. You click a button, it animates. You hover a card, the elevation changes. You can test the interaction patterns before any screen is generated.

For Pulse I spent about 12 minutes refining components after they were generated. Made the workout card image taller. Added a streak count to the achievement card. Tightened the spacing on the leaderboard. Each refinement updated the component everywhere it was used. No manual cleanup.

This is what a real component library does. You design once. Reuse everywhere. Refine in one place. Updates propagate.

Pulse design system after the first generation. Buttons, cards, badges, every component rendered live.

Pulse design system after the first generation. Buttons, cards, badges, every component rendered live.

Refined V1 after talking back and forth with the Agentic Design System Builder until it landed. Spend at least 10 minutes here. It saves you hours later. Below is what V2 looks like.

Same library after 12 minutes of refinement. Tighter spacing, sharper variants, ready to feed screens.

Same library after 12 minutes of refinement. Tighter spacing, sharper variants, ready to feed screens.

Step 4: Use The Gallery To Validate

This is the step that separates a real system from a fancy token sheet.

Moonchild has a Gallery view that renders every variant of every component side by side. Every badge. Every card. Every button. Every input state. The whole family in one frame.

The gallery is where you spot problems before they compound.

For Pulse, looking at the badge gallery side by side, I caught two issues immediately.

The streak badge orange was glowing too hot against the cream canvas. Fixed it by softening the badge background to the lighter orange step in the scale.

The locked state and the completed state looked too similar at small sizes on dark cards. Fixed it by changing the locked state to a thinner outline style with a muted charcoal stroke.

Both fixes took 30 seconds. If I had caught them on screen 40 instead of in the gallery, I would have had to update every screen the badge appeared on.

This is the unlock most builders never see. You make informed design decisions before a single screen gets generated. You’re not guessing what a badge should look like in context. You’re seeing the full family at once and judging the system as a whole.

Click any component in the gallery and you also see the live code below it. JavaScript, CSS, examples, dependencies. Ready to pull into the codebase. The same code Codex will read through the MCP connection later.

It is the difference between a style sheet and a real working system.

The Gallery view. Every badge and avatar variant rendered side by side. Fastest way to spot inconsistencies before they ship.

The Gallery view. Every badge and avatar variant rendered side by side. Fastest way to spot inconsistencies before they ship.

Click any component and the live JavaScript and CSS shows up below.

Click any component and the live JavaScript and CSS shows up below.

Handing Off To Codex

Once the system is solid, the rest of the workflow is exactly what I covered in the first article.

You connect Moonchild to Codex via MCP. You paste your PRD. You generate the screens. You hand them off to Codex and Codex writes production code that matches the design exactly. No drift. No slop. Same component library on every screen.

If you haven’t read the full handoff workflow, the deep dive is in my previous Moonchild article.

The short version. With the design system already in place, the actual screen generation and the code shipping take about 90 minutes total for a full mobile MVP. Without the system, the same work takes a designer two weeks and a developer another two weeks of interpretation cycles.

This is the leverage. The design system is the upfront investment. Everything downstream gets faster.

Moonchild design on the left. Shipped Codex code on the right.

Moonchild design on the left. Shipped Codex code on the right.

Bonus: The Same Workflow Works For Web Apps

Quick note before we close.

This article ran the workflow on Pulse, a mobile app. The same exact workflow works for SaaS dashboards and web apps.

We just shipped a B2B analytics dashboard at @ignytlabs using the same Moonchild plus Codex setup. The design system layer is identical. The component library is bigger because dashboards have more density (data tables, filters, sidebars, chart containers), but the build process is the same. Foundation, components, gallery, MCP to Codex, ship.

If you build for web, the workflow scales. Mobile or desktop, the design system is the moat.

SaaS dashboard built with the same Moonchild + Codex workflow.

SaaS dashboard built with the same Moonchild + Codex workflow.

When To Build A Real Design System

This isn’t the right move for every project. Be honest about when it fits.

Build a real system when:

→ You’re shipping any product that lives more than 30 days

→ You expect more than 5 screens

→ Brand consistency matters (it almost always does)

→ You’re charging clients for the work and your reputation is on the line

Skip the system when:

→ Weekend hackathons

→ Throwaway prototypes you’ll never ship

→ Single-screen tools that will never grow

→ Internal experiments where the visual quality genuinely doesn’t matter

For 95% of real projects, building the system upfront pays back inside the first week.

What To Watch Out For

Four honest flags before you run this on real work.

Garbage inputs equal garbage system. A vague brief or three blurry Dribbble screenshots will produce a weak system. Spend 5 minutes on the brief. It pays back across every screen.

Don’t over-engineer the system before you have the product. A 200-component system you never use is worse than a 30-component system you actually ship with. Build for the screens you need now. Extend the system as the product grows.

Updating mid-project will break screens if you’re careless. When you change a foundation token (a color, a font weight, a spacing value), every screen that uses it updates. Most updates are good. Some break the layout of specific screens. Always preview before committing big changes.

The system is your taste, not the tool’s. Moonchild generates a strong starting point. Picking the right variant, refining the spacing, killing the components you don’t need, that part is on you. The tool produces. You direct. Skip the curation step and you’re back to vibe-designing.

What This Actually Means

Here’s my honest take.

Apps that don’t look vibe-coded aren’t accidents. They have systems behind them. Tokens, components, gallery rules, taste applied at scale. That used to be a designer’s job, then a design team’s job, then a Figma library’s job. It cost weeks and thousands of dollars per project.

Moonchild collapsed the cost of building one. Codex collapsed the cost of shipping it as code. Together, they collapse the gap between what a funded team can ship and what a solo builder can ship.

At @ignytlabs we used to budget two weeks for design across every client MVP. Hire a designer. Wait on Figma files. Watch the developer interpret it. Cycle.

Now we run Moonchild on the design system upfront, feed PRDs to Moonchild as they come in, and hand the output to Codex through the MCP. What used to take two weeks now takes two days. Same quality. Higher margin.

This is the workflow funded teams already have with their Figma plus designer plus developer pipelines. The difference is now solo builders, indie agencies, and small studios get the same leverage without the headcount.

2026 is going to be UNFAIR for builders who figure this out first.

TLDR

→ Apps that look vibe-coded aren’t an AI problem. They are a missing system problem.

→ A real design system has 4 layers: tokens, component library, gallery view, rules.

→ Step 1: Pick your input path inside Moonchild. Figma import, GitHub, live URL, inspiration drop, or the Agentic Design System Builder.

→ Step 2: Generate the foundation. Color palette, typography scale, spacing scale, elevation. Get this layer right and everything stacks on it.

→ Step 3: Build out the full component library. Every component, every variant, every state.

→ Step 4: Use the Gallery view to validate the system before any screen ships. This is the step 95% of builders skip.

→ Hand off to Codex via MCP. Production code with zero drift across screens.

→ Same workflow scales to web apps and SaaS dashboards.

→ Build the system when you’re shipping for real. Skip it for throwaway prototypes.

→ The design system is the moat. Moonchild plus Codex collapses the cost of having one.

LFG.