8 products in 3 weeks: my Claude skills that made it possible
I'm not an engineer or a designer but I've shipped eight software products in just 3 weeks. Technically, I'm shipping nearly ever minute.
The bet is always the same. Find a real problem buried in PDFs, phone calls, and stuff nobody wrote down, and build a small tool that just handles it. LabLookup came straight from my house. My wife is a nurse practitioner and lives that clinical workflow every day.
The skills that make it work are further down, in full, for you to copy.
The rhythm looks like this. One to two days to ship a real MVP. A few days to test and fix. Then a few days watching what people actually do and tuning until they convert.
Here's the setup that lets me run eight of these at once.
One platform, every product
You can't log into eight dashboards. So every product ships with the same baseline: admin area, health monitoring, a feedback path, analytics, transactional email. All of it routes into one HQ.
The nice part is standardized funnels. "Activation" means something totally different for a veteran decoding a disability rating versus a trucker checking compliance. The admin tool flattens all of it into one flow: Started, Succeeded, Paid.
The shared stack
The biggest cheat code for a solo builder is running the identical stack every time. Code and lessons transfer for free.
- Framework: Next.js app router and Tailwind
- Database: Postgres (Supabase), row level security on by default
- Auth: a hosted provider like Clerk
- Payments: Stripe, paid status flipped only by the webhook
One rule holds it together. Keep a lib/ directory that's completely product-agnostic. Auth, billing, email, rate limiting. Domain code imports platform code, never the reverse. New product, and the whole lib/ folder comes along for free.
The skills that keep it honest
Building solo with AI, the hard part isn't the code. It's continuity. No code review, no standup, no one to catch sloppy thinking late in a session when the thing mostly works and you just want to close the laptop.
So I use packaged instruction files, "skills," that the agent runs on command or automatically. The trick isn't that they give advice. It's that a good one leaves behind a check, so the same mistake can't ship twice.
Three do most of the work. They're below in full. Read them, and copy any you want. There are more behind these, security passes, SEO scaffolding, copy linting, but start with these three.
1. Kickoff (new-product.md)
A clone-and-strip playbook for every new repo. Reuse the lib/ primitives as-is, swap the config, delete the old domain code, build the new one. It's not "stood up" until it clears the acceptance gate at the bottom.
---
name: new-product
description: Clone-and-strip playbook for standing up a new product on your shared platform. Use when starting a brand-new product repo. Walks platform reuse, config swaps, domain replacement, account setup, and the "every product ships with" acceptance gate.
---
# new-product: clone-and-strip playbook
Standing up product #2+ should be fast because everything except the domain is shared. Use your newest healthy product repo as the donor. Think in three tiers: reuse as-is, swap values, rebuild from scratch.
## 1. Scaffold
- New repo, same framework and folder layout as the donor (route groups, `lib/`, `components/`, database migrations, tests).
- Copy the tier-1 `lib/` primitives UNCHANGED: auth/session, billing, email, AI cost guard, rate limiting, analytics, notifications, health, validation, security headers. Dependency rule: domain code imports platform code, never the reverse.
## 2. Tier-2 config swaps (same shape, new values)
- The analytics event registry: new product's event names.
- Billing plans/prices. Every price, threshold, and flag is an env var with fail-loud validation and NO hardcoded fallback.
- Env var names, email templates, onboarding copy, tenant naming, admin feeds.
## 3. Tier-3 domain
- Delete the donor's domain modules entirely. Build the new product's domain in the app routes and its own domain modules. No speculative frameworks.
- Domain leftovers hide OUTSIDE `lib/` - grep the donor before trusting the clone. Common hiding spots: the health check's list of core tables; cron registrations; branded assets; any hardcoded product name.
## 4. Accounts & infrastructure
- Separate accounts and keys per product for every vendor. Never share a project across products.
- Enable Row Level Security on every table from the first migration (deny-all default). Wire the payment webhook as the ONLY thing that flips paid status.
## 5. Seed the agent config
- Copy your `CLAUDE.md` (or agent instructions) and your skills into the new repo. Add a product-specific section for domain rules; keep the shared process rules identical to every other product.
## 6. Acceptance gate: "every product ships with"
Do not call it stood-up until it has all of these, matching your donor:
- Admin area gated by an admin-email allowlist.
- Health endpoint + external uptime monitor.
- A feedback path (widget -> stored row -> triage -> your inbox).
- Analytics wired, with an event on every new user-facing behavior.
- Transactional email, including a welcome email on signup (verify with a REAL signup).
- A golden-fixture test suite for whatever your core math is.
- SEO baseline: canonical tags, Open Graph, sitemap, robots, a branded social share card that actually renders.
- Favicon and app icons in the NEW product's brand color, not the donor's.2. Handoff (wrap.md)
I run this at the end of every session, not just every day. It's the handoff between fresh-context sessions. The point is simple: run the work, don't just describe it.
# /wrap: end-of-session ritual
Run at the END OF EVERY session. This is the handoff between fresh-context sessions, not just end-of-day. Run the work, don't just describe it.
## 1. Git hygiene
- Never leave work uncommitted. Feature branch + PR; never commit to `main` once the repo is on GitHub with `main` protected.
- Push to GitHub. Clean up merged worktrees/branches.
## 2. Verify
- Clean build (delete the build cache first to avoid stale-cache flakes).
- Typecheck.
- Unit tests (core math / golden fixtures must be green).
- End-to-end tests (stop any running dev server first).
- Re-run any flake single-worker before calling it environmental.
## 3. Docs
- Append a dated entry to a decisions log for anything decided this session: what, why, and what would change your mind.
- Update the changelog and any roadmap/status doc.
- List loose ends as TODOs for next session.
## 4. Memory
- Update your persistent notes: what shipped, what is in flight, gotchas discovered, and any standing actions owed by you (the human).
## 4b. Distill
- Run the `distill` skill. Any lesson from this session that would bite ANY of your products goes into your shared instructions or shared skills; product-specific lessons stay in that product's docs/memory.
## 4c. Commit the knowledge base
- Keep your shared agent config (instructions + skills + memory) in its own git repo so no lesson is ever lost. Every wrap: glance at its status, then commit.
## 5. Outputs
- A session summary: what changed, test counts, CI/prod state, loose ends, actions you personally owe.
- A short, honest build-log blurb you could post publicly (no hype).
- A copy-pasteable prompt for the NEXT session: current state, in-flight work, next phase, and which model to use.3. System compounder (distill.md)
This runs inside the handoff. Every lesson gets one question: would it bite any of my products, or just this one? Cross-project lessons get promoted into the shared skills. The rest stay local. That's the whole trick. Every session leaves the factory a little smarter.
---
name: distill
description: Promote this session's lessons into your shared factory layer. Use during /wrap or on demand after a session that surfaced a new gotcha, process fix, or reusable pattern. Routes cross-project lessons into shared skills/instructions and project-specific lessons into project docs/memory.
---
# distill: the factory that maintains the factory
Review what this session learned and file each lesson in the right layer. Takes two minutes; keeps your shared skills from rotting. This is the habit that makes the whole system compound: every session should leave the factory a little smarter.
## 1. Collect
List the session's lessons: bugs whose cause generalizes, process friction, new gotchas, patterns worth repeating, corrections the human gave you.
## 2. Route each lesson
Ask: would this bite ANY of my products on the shared stack, or only this one?
**Cross-project** (git/worktree mechanics, stack gotchas, testing protocol, copy voice, security posture, platform patterns):
- A gotcha or rule -> add/update the matching section in your SHARED agent instructions.
- A procedural step -> add/update the matching SHARED skill (ship-check, copy-lint, security-pass, new-product). Keep skills tight; prefer editing an existing line over appending forever.
**Project-specific** (domain data, product decisions, domain facts):
- A dated entry in that product's decisions log + its project memory.
## 3. Hygiene
- One lesson, one home. If it lands in the shared layer, don't also duplicate the full text in project memory; a pointer is enough.
- Delete or correct shared-layer entries that turned out to be wrong. A stale rule is worse than no rule.
- If a project's instructions still carry prose now covered by the shared layer, note it as cleanup debt (don't churn mid-session).
## 4. Report
State what was promoted to the shared layer, what stayed project-local, and any cleanup debt you noticed.Want to try it
You don't need to be an engineer. A year ago this tooling was good for engineers and simple marketing sites, nothing in between. Now it's genuinely good for the rest of us.
If you're starting:
- Pick a problem you actually live, not one you'd casually browse.
- Separate the platform layer from the product layer on day one. That up-front cost is what makes the next one thin.
- Write the boring rituals down as skills so the agent runs them every time, especially when you're tired.
- Build the improvement loop into the product. User signal in one end, shipped fix out the other.
Start with wrap and distill. Add new-product when you build your second app. Adapt every step to your own stack. The value is in the shape of each ritual, not the exact commands. And whenever something bites you, don't just fix it. Write the lesson down as a check, so it can't bite you twice.