I'm the creator of VibeCodePack. Before I built a single mission file, I spent weeks studying a company called ThemeSelection — a bootstrapped operation that turned one admin theme into a $65,000/month business. 1.6 million creatives reached. 300,000+ downloads. No venture funding, no big team. Just the right product positioned the right way.

I wasn't looking at their templates. I was looking for the model underneath the revenue — the thing that actually makes a UI business work. And once I understood it, I ran a test that changed how I thought about the whole space.

I took a typical admin template and opened it in Claude Code. Just to see what would happen if a modern AI agent tried to build with it. Within minutes, the agent was drowning. Multi-thousand-line files loaded into context all at once. No instructions about naming conventions, folder intent, or design token structure. The agent started guessing, hallucinating component names, writing across files it shouldn't have touched. What came out was bloated and broken before I'd even started the dev server.

That was the realization: static templates break the moment AI does the building. They were designed for a human to copy, paste, and adapt by hand. Hand that same file to an agent and the whole thing falls apart. The market ThemeSelection proved is real — but the product format is from the wrong era.

The five things their customers actually complain about

Before I designed anything, I read through ThemeSelection's public reviews — support threads, marketplace feedback, forum posts. Five complaints came up again and again. These aren't edge cases or one-off bad days. They're structural, and they're recurring. They became the design brief for the entire product.

1. The support process punishes you for following up

To get technical help, you first request access to a private GitHub repository, then submit a formal issue. That alone is friction. But here's the part that genuinely surprised me: if you reply to your own ticket before the support team does, the system resets your priority date. You get pushed further back in the queue for the crime of following up on your own request.

2. Documentation that covers setup but not development

The word that shows up over and over in critical reviews is "adequate." Basic installation works fine. But anything past that — extending the design system, understanding component architecture, adapting a pattern for a real use case — isn't covered in depth. For any non-standard work, you're guessing or waiting on a ticket.

3. Templates that slow to a crawl under AI

One review described a purchased product that "took forever to load" and delivered a frustrating development experience overall. This is the exact failure I reproduced myself. AI agents working against large static templates load everything into context and start writing blindly. The original quality degrades because nothing tells the agent what to touch and what to leave alone.

4. Bundles that quietly void the refund policy

ThemeSelection markets big bundle deals — sometimes up to 90% off the catalog. What's buried in the terms: the standard 14-day money-back guarantee is completely voided for bundle purchases. If it doesn't fit your stack, you have no recourse. The discount is real. So is the risk you're taking on.

5. Customization is officially out of scope

Their support explicitly excludes installation, deployment, and customization. Bug fixes and basic functionality questions only. If you need to modify a layout or adapt a component for a client, you either pay them for custom development or hire an outside dev. What feels like a 15-minute tweak becomes a multi-day freelance invoice.

The ten things that actually go into a real dashboard

Here's what most people — and most AI output — get wrong. A dashboard isn't a screenshot. It's a system of interlocking decisions, and if any one of them is sloppy, the whole thing feels broken to the person using it. When you ask a generic AI to "build me a dashboard," it skips most of these. Here are the ten things that separate a real one from a demo.

1. Layout shell and navigation structure

   The sidebar, the topbar, the way regions are defined and how they collapse on smaller screens. This is the skeleton everything else hangs on. Generic AI output usually nails the look and completely misses the responsive behavior, so it breaks the moment you resize the window.

2. A consistent component naming convention

   Every button, card, and table needs to follow one naming system so the codebase stays navigable. AI agents left to their own devices invent a new convention every few files, and within an hour you can't find anything. Consistency here is the difference between maintainable and disposable.

3. Design tokens, not hardcoded values

   Colors, spacing, and typography should reference a single source of truth, not be typed in by hand on every element. When the AI hardcodes a hex value 40 times, changing your brand color becomes a find-and-replace nightmare instead of a one-line edit.

4. Data tables that actually work

   Search, sort, filter, pagination, empty states. A table is the hardest-working component on most dashboards and the one AI most often fakes — it'll render rows that look right but have no working interaction underneath.

5. Stat cards with real hierarchy

   The KPI row at the top needs visual hierarchy — what's the primary number, what's the trend, what's secondary. Most AI output makes every card identical weight, which means the user's eye has nowhere to land.

6. Loading, empty, and error states

   Real interfaces handle the moments when data is loading, missing, or failed. These three states are where amateur builds fall apart, because the happy path is easy and the edge cases are the actual work. AI almost never builds them unless told to.

7. Sensible file and folder structure

   Components grouped logically, no 800-line god-files, clear separation between layout and feature code. This is invisible until you try to extend the project — then a bad structure costs you hours every single time you touch it.

8. Auth and role-based access

   Login, sessions, and the logic that decides who can see what. Even a frontend build needs the structure for this. Skip it early and you're retrofitting it painfully later, which is exactly when bugs creep in.

9. Accessibility basics

   Keyboard navigation, focus states, semantic markup, contrast that passes. Not optional for anything client-facing, and almost universally ignored by generic AI output because it's not visible in a screenshot.

10. Verification before you ship

    Some check that confirms the build is actually correct — files within size limits, exports wired up, tokens applied, nothing hallucinated. Without this step, you discover the broken parts in production. This is the single most-skipped step and the most expensive one to miss.

Read that list again and notice something: almost every item is a place where unguided AI output fails. Not because the model is bad, but because nobody told it the rules. That's the entire problem VibeCodePack exists to solve.

How VibeCodePack actually works

At its core, VibeCodePack is a collection of structured Markdown files — I call them missions — that live in an Obsidian vault and tell a Claude Code agent exactly how to build. Not what to build from scratch. How to build it: with what constraints, in what order, verified against what spec.

Obsidian is the command center

If you haven't used Obsidian, it's a free desktop app that opens a folder of Markdown files and treats it as a connected knowledge base. No cloud, no account, no subscription. Your files live on your own machine. That local-first design is exactly why it works here: when Claude Code runs, it reads directly from the same folder Obsidian points at. No API calls, no syncing, no latency. The agent opens the mission file the same way you do — it's just a file on disk, and it's the single source of truth you both work from.

The four layers

Inside the vault, everything is organized into four layers, each one attacking a specific failure mode from the list above.

Blueprints are the 75 mission files — the actual build instructions for dashboards, interactions, and auth. This is where the naming conventions, design tokens, table behavior, and component structure get specified, so the agent doesn't have to invent them.

Safety is a set of hardcoded rules the agent must follow on every build. The most important one is a strict 300-line file limit per component. That single rule prevents the god-file problem — the agent physically cannot produce the 800-line monster that makes a codebase unmaintainable. It's forced to keep things modular, readable, and reviewable.

Operations are the step-by-step checklists. Inspect what already exists before writing. Scaffold the shell first. Build in a fixed sequence. This is what stops the agent from writing blindly across files and degrading quality as it goes.

Gates are the verification scripts that run before anything is committed. Files within limits? Exports wired correctly? Tokens applied? The gate returns a pass or a precise list of what failed. This is item ten from the list — the most-skipped step — built directly into the system so it can't be forgotten.

Now map this back to the five complaints. No support queue — the gate tells you what failed, locally and instantly. No thin docs — the blueprint is the documentation, always current. No AI degradation — the 300-line limit and inspect-first rules prevent it structurally. No bundle lock-in — the tiers are modular. No customization wall — you change the brief and re-run. Every complaint, designed out.

What happens after you buy — step by step

This is the part most products skip, and it's the part that matters most. You buy something, you download a ZIP, and then comes the worst moment in any digital purchase: okay, now what? Here's exactly what you do, start to finish. You do not need to be a prompting expert. You don't need to write any prompts at all, actually.

1. Open the vault in Obsidian

   Unzip the download. Open Obsidian, choose "Open folder as vault," and point it at the unzipped folder. The entire mission library appears in the sidebar, organized and readable. That's the whole setup.

2. Choose a mission

   Browse to the dashboard type you want — Admin, CRM, Client Portal, Analytics, and so on. Open that mission file. You're now looking at the build instructions, which you can read in plain English before anything runs.

3. Fill in the brief — four fields

   At the top of every mission is a short brief. Project name. Primary color. Stack (like Next.js or Laravel). One sentence describing what it manages. That's it. Four fields. Everything else is already configured for you.

4. Copy the generated prompt

   Below the brief, the mission has already assembled a complete Claude Code prompt based on what you filled in. You don't write it — you copy it. All the safety rules and build sequence are baked in automatically.

5. Paste into Claude Code

   Open Claude Code in your project folder, paste the prompt, hit enter. The agent reads the mission and safety files first, then builds in the specified order. You watch it work. No further input needed.

6. Let the gate verify it

   When the build finishes, the gate script runs automatically. You get a clean pass, or a precise list of what to fix. Either way you know exactly where you stand — no guessing whether the output is actually production-ready.

That's the whole loop. The reason it works for non-experts is that the hard part — knowing what to tell the AI and how to constrain it — is already done inside the mission. You're filling in four blanks and pressing go.

A real build, in detail

Let me walk through an actual run so you can see the texture of it. I used DASH-01, the Admin Dashboard mission, targeting Next.js 14 with Tailwind and shadcn.

I filled in the brief: project "Internal Admin," primary color #1B55A8, the Next.js stack, and "manages user accounts and subscription billing" as the one-line description. Then I copied the generated prompt, which looked like this:

You are executing mission DASH-01.
Read MDD/blueprints/dash-01-admin.md before writing any code.
Read MDD/safety/global-rules.md and enforce all constraints.

Project: Internal Admin
Color:   #1B55A8
Stack:   Next.js 14 / Tailwind / shadcn
Manages: user accounts and subscription billing

# Build sequence:
# 1. Inspect existing /components before writing anything
# 2. Scaffold layout shell (sidebar + topbar)
# 3. Build stats row (4 metric cards)
# 4. Build users table with search and filter
# 5. Run MDD/gates/dash-verify.md before committing

I pasted it into Claude Code and watched. The first thing the agent did was inspect the existing components folder — it didn't write anything until it knew what was already there. Then it scaffolded the layout shell, built the four-card stat row, and assembled the users table with working search and filter. It stayed inside the 300-line limit on every file because the safety layer wouldn't let it do otherwise.

Total time: about 14 minutes. The gate ran at the end and came back clean — every file within limits, exports correct, design tokens applied consistently. No hallucinated component names. No mystery folders. No 800-line files waiting to be refactored. A clean, modular admin dashboard I could actually extend.

Then I did the thing that proves the point. I changed the brief — different color, swapped the "manages" line to something else — and ran it again. Thirteen minutes later, a different dashboard. Same structure, same quality, different output. That's the part that matters: it's not one template, it's a repeatable process. Run it for one client, then run it again for the next with new inputs. That's the factory.

The honest version of where this stands

ThemeSelection proved the market exists. That's not in question — the revenue is real, the downloads are real, the demand is real. What I've built is the same fundamental idea rebuilt for how people actually develop now: with AI agents doing the assembly instead of humans copying files by hand.

I'll be straight with you about where I am versus where they are. ThemeSelection has years of brand equity, an enormous catalog, and a base of buyers who trust them. I don't have any of that yet. What I have is a different approach to the same market — one that starts with the mission file instead of the finished template, and removes the five things their own customers complain about most.

Whether this becomes a $65k/month business comes down to execution, and I'm early. I'm not going to dress that up. What I'm confident about is the core: the system works, the builds are clean, and the friction that drives people away from the old model is designed out of this one from the start. The rest is just building, shipping, and iterating — the same way they got there.

If you want to look at the vault yourself, run a build, and see whether it holds up, the link is below.