AI Generated App Examples: the six reference apps mk0r was calibrated against
Almost every page about this topic shows you a stock screenshot grid, slaps a hero gradient on top, and calls it a gallery. mk0r took the opposite trade. Six fully rendered reference apps live as real React functions inside our landing page tree, each one a specific UI archetype the generator was tuned to reproduce. This guide opens the file and walks through them, one by one.
The cheap way to do this and the expensive way
The cheap version of an example gallery is a folder of pretty PNGs and a paragraph next to each one. It looks fine. It tells you nothing about whether the generator behind the page can actually produce the thing in the picture, because nobody can see what was in the prompt or what came out the other side.
The expensive version is to publish the actual reference designs in your own codebase, name the file, and let anyone read the Tailwind classes and SVG math to check that what we promise lines up with what we ship. That is what this page is. The file is src/components/landing-content.tsx. Open it in any editor, scroll to line 172, and follow along.
The single line that defines the showcase
Past the imports and stat block, the showcase compresses to one array. Six entries. Each entry pairs a title and a description with a Mockup component imported from the same file. This is the visual contract the generator inherits.
Six categories. Each one a real component, not a placeholder. Each one carrying a small bag of UI primitives the generator has to reach for whenever a prompt collapses into that genre.
The six archetypes, by the primitive each one teaches
Habit Tracker
Streak chips: a horizontal row of 7 small rounded squares, today's filled in bg-orange-400, missed days bg-zinc-200. The pattern shows mastery of a fixed-length status grid.
Budget Planner
Allocation bar: a single 8px-tall track with a bg-gradient-to-r from-emerald-400 to-cyan-400 fill at 62 percent width. Two side-by-side income/spent stat cards underneath.
Recipe Scaler
Servings stepper: a − / number / + cluster wrapped in pill chips, then a vertical list of ingredient name plus quantity. Simple input that drives proportional outputs.
Study Cards
Paginated flashcard: question chip, the question itself, a Show Answer button paired with Skip, plus a 4-segment pagination bar. A canonical learn-and-advance flow.
Mood Journal
Emoji row plus a 7-day rounded bar chart. The chart bars use bg-gradient-to-t from-pink-400 to-rose-300, with absent days as flat gray pills. Self-report meets time series.
Pomodoro Timer
Real SVG progress dial: two circles at cx=50 cy=50 r=42, with the second one's strokeDasharray=264 strokeDashoffset=80, which is the actual math for ~70 percent.
From prompt to mockup: how the contract flows
Picking the right archetype is most of the battle. Once the prompt is mapped to one of these six visual languages, every other choice downstream falls into place: the palette, the spacing, the interactions, the data shape. The generator does not invent a UI from scratch; it pattern-matches against what it already has a clean recipe for.
Where each prompt lands
What an AI-built app should not feel like
The reason the SHOWCASE array is intentionally short is that length is not the goal. A long gallery of half-baked screenshots teaches the generator nothing. A short list of six watertight references teaches it to pick a lane. Below is the difference, stated as a checklist, that we use as our internal sniff test before any new archetype gets added.
The reference design rubric
- Phone aspect, never desktop. The card container fixes the aspect ratio so the mockup must work in a thumb-sized frame.
- One UI primitive that earns its place. Streak chips, allocation bar, stepper, pagination, mini chart, progress dial.
- Real numbers, not lorem ipsum. 7-day streaks, 62 percent of budget, 4 servings, question 3 of 20, week of mood, 18:42 left.
- A single accent color per archetype, applied with intent. Orange for habits, emerald for money, violet for recipes, blue for study, pink for mood, amber for focus.
- Touch-friendly affordances by default. Stepper +/- buttons, big primary CTA, tappable emoji row.
- No decorative chrome. No floating gradients, no fake notifications, no AI-slop hero illustrations.
A walk through the file, in the order things happen
The file is laid out the same way the home page reads. Top of file: stats and brand logos. Middle: the steps and the showcase. Bottom: features, personas, FAQs. The six mockup components are stacked right before the SHOWCASE array, so anyone editing the gallery has to look at the actual UI they are signing off on.
Lines 1 to 11
Imports and STATS. The headline number is '~30s. From idea to working app.' That latency target is the reason the archetypes are simple, single-screen, and recognizable in a glance.
Lines 13 to 124
Brand logo strip. Anthropic, Vercel, Gemini, Firebase, Next.js, Stripe, Tailwind, Playwright, Cloudflare, Freestyle, Assrt, GitHub, AWS, TypeScript. Each is an inline SVG, not an external image.
Lines 132 to 169
STEPS. Idea, generate, refine. The three-step rhythm the showcase has to fit inside.
Lines 172 to 315
The six Mockup React components. Each one is around 20 lines of JSX with explicit Tailwind classes, fixed numbers, and one or two SVGs.
Line 317
SHOWCASE. The array that pairs each mockup with its title and description. This is the contract the rest of the page reads from.
Lines 350 onward
FEATURES, PERSONAS, FAQS. Everything past this point is editorial and does not constrain the generator. The mockups above do.
The contract, expressed as the SVG inside the focus timer
If you only read one snippet from the file, read this one. It is the Pomodoro dial, drawn pixel-honestly with two SVG circles. The progress arc uses a strokeDasharray equal to the circle's circumference and a strokeDashoffset that represents the fraction remaining. This is the shape an AI generator has to know how to produce when somebody types "circular timer".
Two pi times r equals about 264 when r is 42. So the dasharray is the full circumference, and the dashoffset of 80 leaves about 70 percent of the arc visible. The math is correct on purpose. When an AI generator gets handed "a circular focus timer at 70 percent," this is what the right answer looks like. When it gets handed "at 25 percent," the dashoffset becomes roughly 198. There is no guesswork.
The fast lane vs the deep lane
mk0r has two generation modes, and the same six archetypes are targets for both. The Quick mode streams a single HTML file from Claude Haiku, hits the phone preview in seconds, and is ideal for testing whether the prompt even matches an archetype. The VM mode boots a real Vite + React + TypeScript + Tailwind v4 project inside an E2B sandbox and produces a codebase you can keep.
| Feature | mk0r VM mode | mk0r Quick mode |
|---|---|---|
| Output format | Single streaming HTML file | Vite + React + TS + Tailwind v4 project at /app |
| Speed to first paint | Around 30 seconds, streaming | Tens of seconds, then iterative |
| Editable later? | Re-prompt to regenerate | Real source files, real HMR, real diffs |
| Best for | Validating that the prompt hits an archetype | Building an app you actually want to keep |
| Reference designs targeted | All six SHOWCASE archetypes | All six SHOWCASE archetypes |
| Browser inside the sandbox | No, the HTML is the surface | Yes, real Chromium with Playwright MCP wired in |
Try the prompts that hit each archetype
Below are the literal prompts that map cleanly onto each archetype. Type any one of them into mk0r and you will see the matching mockup's primitives appear in the phone preview within the time it takes to read this paragraph.
Why six is enough
A bigger gallery is the easy answer. The honest answer is that six archetypes, each carrying one strong UI primitive, cover most of the things people prompt an AI app builder for in their first session. The point of the showcase is not to enumerate every possible app; it is to give the generator a small, sharp visual vocabulary that scales by recombination.
The number that frames everything
Six reference apps, one file, line 317 of src/components/landing-content.tsx. Read the file and you can falsify or confirm every claim on this page in under five minutes.
What other galleries call "variations"
Galleries elsewhere often pad their numbers by listing color variants of the same template. A blue todo, a green todo, an orange todo. That is not what is happening here. Each archetype is structurally different from the others. A streak chip cannot substitute for an allocation bar; a flashcard pagination cannot stand in for a progress dial.
One more honest line
The whole content of this guide compresses to that strip. Six primitives, one for each archetype, drawn straight from real Tailwind classes and SVG attributes in a file you can open and read. That is what an example gallery is for. Anything more is decoration; anything less is fiction.
Want a custom archetype added to the generator?
Walk us through the kind of app you keep prompting for. If it lands, it gets a Mockup component and a slot in SHOWCASE.
Frequently asked questions
Where do these six examples actually live in the codebase?
All of them are React functions in src/components/landing-content.tsx. HabitTrackerMockup starts around line 172, BudgetPlannerMockup around line 195, RecipeScalerMockup around line 221, StudyCardsMockup around line 243, MoodJournalMockup around line 262, and PomodoroTimerMockup around line 287. The SHOWCASE array at line 317 collects all six in the order they appear on the home page. Each one renders inline in a 224px tall card with its own Tailwind palette and a distinct UI pattern.
Why these six archetypes and not, say, calculators and CRMs?
These six cover the patterns most prompts collapse into: streaks and goals (Habit Tracker), money and allocations (Budget Planner), inputs that scale outputs (Recipe Scaler), spaced learning (Study Cards), self-reporting plus a chart (Mood Journal), and a single-purpose timer (Pomodoro). If a generator can produce all six cleanly, it can stretch to thousands of variations. CRMs and full calculators are too schema-heavy for a 30 second build, which is the speed mk0r is calibrated against.
Are these examples just decorative, or are they connected to what the generator outputs?
They are reference designs, not random art. Each mockup encodes the UI primitives the generator should reach for when a user asks for that genre of app: a 7-day streak chip with bg-orange-400 squares for habits, a gradient progress bar with from-emerald-400 to-cyan-400 for budgets, a − / 4 / + servings stepper for recipes, a Show Answer / Skip pair plus a 4-position progress bar for flashcards, an emoji row plus a 7-day rounded bar chart for mood, and an SVG circle with strokeDasharray='264' strokeDashoffset='80' for focus timers. When mk0r generates an app in that genre, those primitives are the visual vocabulary it draws from.
What makes the Pomodoro example a credible reference for an AI-built timer?
It is a real SVG progress dial, not a placeholder. The component draws two concentric circles at cx='50' cy='50' r='42', the first as a track with stroke='#fde68a', the second as a progress arc with stroke='#f59e0b' and strokeDasharray='264' strokeDashoffset='80'. The math is correct: 2*pi*42 ≈ 264, and 80 of those 264 units left undrawn corresponds to roughly 70 percent complete. That is exactly the math an AI generator must produce when a user asks for 'a circular timer at 70 percent'.
How long does mk0r actually take to produce one of these examples?
The landing page reports 'around 30 seconds from idea to working app' as one of three top-line stats in src/components/landing-content.tsx (the STATS array, top of the file). That figure is for the Quick mode, which streams an HTML response from Claude Haiku straight into a phone preview. The VM mode, which boots a Vite + React + TypeScript + Tailwind project inside an E2B sandbox, takes longer because it provisions real services, but the visual fidelity goes up accordingly.
Can I copy these mockups and use them in my own app?
The mocks themselves are part of the mk0r marketing site, but the patterns they show are completely generic, and the prompts that produce equivalents are typed in plain English. The point of publishing the file path is to be honest about what the generator is targeting; the point is not to suggest the file should be lifted. If you want one of these apps for real, the fastest path is to type the prompt into mk0r and have it scaffold a fresh, owned codebase.
Do AI generated apps from mk0r work on phones, or just desktop screenshots?
All six showcase mocks are constrained to a phone aspect ratio in their card container, and the FEATURES array on the same landing page calls out 'Mobile first. Every app is designed for phones. Touch friendly, responsive, polished.' That is the explicit visual brief the generator inherits. When you generate one of these apps, the output is a working mobile-first interface, not a desktop layout shrunk down.
How is this different from the Bolt or Lovable example galleries?
Most galleries publish PNG screenshots, sometimes a README, occasionally a live link. None of them point at a file in their own repo and say 'this is the design vocabulary the generator was tuned to reproduce.' That difference matters because a screenshot is unfalsifiable; a React component with specific Tailwind classes and SVG math is checkable. Read the file at src/components/landing-content.tsx and you can verify every claim on this page.