knack ← all posts

· claude-code · indie-hackers · agent-skills · mcp · indie-hacker-launch

The Claude Code stack for indie hackers in 2026

The four layers of a Claude Code stack for indie hackers shipping their second-to-fifth product, what to install in week one, and what to ignore until later.

“What is the Claude Code stack for indie hackers in 2026?” tends to get one of two unhelpful answers. The first is a thirty-tool list that takes a weekend to install and another to evaluate. The second is “just use Claude Code”, which is the same advice as “just use a computer” and equally specific.

This post names the four layers of the stack, recommends the four or five things to actually install in week one, and is honest about where the stack breaks before you can launch a product on top of it.

What “stack” means here, and what it leaves out

Stack here means the four-to-six things you have configured on your laptop, not the thirty you could install. The reader we have in mind is a solo indie hacker shipping their second-to-fifth product, working in their own time, with one repo open at a time. Not a team of five. Not a pre-product founder, for whom the bottleneck is talking to people rather than tooling.

What we leave out, on purpose: anything that takes longer than ten minutes to configure and doesn’t pay off in the first week. No team role-based access. No cost-tracking dashboards. No prompt observability. No “evals” infrastructure. These all become useful at some scale; that scale is not “shipping product number three on a Saturday”.

The point of the stack is to make Monday morning faster, not to admire it on Sunday.

The four layers of a Claude Code stack for indie hackers

The whole thing is four layers. Everything else is configuration of one of these.

Layer 1: editor and harness. Claude Code is the harness. The model is what changes underneath. Sonnet 4.6 handles the daily majority: refactors, doc edits, test scaffolding, “rename this everywhere”, “wire this endpoint to that handler”. Opus 4.7 is for the harder cases where you actually need something thought through. Switch with /model. Defaults stick across sessions in ~/.claude/settings.json. (If you are on Claude Pro, Sonnet is what you have, and Sonnet is enough; the Opus call only matters on Max or the API.)

Layer 2: skills. Composable instructions Claude Code reads when invoked. They live in ~/.claude/skills/ (global to your machine) or .claude/skills/ (scoped to the repo). A skill is a folder with a SKILL.md file inside it. The frontmatter names the skill and describes when to use it; the body says what to do. Examples: idea-clarifier, first-skill-template, proposal-writer. You will write your own; you will also install other people’s.

Layer 3: agents. Specialised reasoners scoped to a tool list and a system prompt. Useful when you have a recurring multi-turn workflow you keep typing the same scaffolding for. Less useful before that workflow is stable. The honest test: can you describe what the agent should do in five sentences? If not, you do not yet have a workflow worth automating.

Layer 4: MCP servers. The escape hatch from Claude Code’s built-in tools. Connect Claude Code to your Postgres, your GitHub, your Polar account, your Stripe dashboard, your Linear, whatever. Each MCP server adds power and adds cognitive load. Hold to two or three at most. The discipline is the same as dependency discipline: every new server is a tax on every future session.

What to install in week one

Five things. In order.

  1. Default model: Sonnet 4.6. Reach for Opus 4.7 only when you hit a real problem. Most of the work is mechanical and Sonnet handles it faster.
  2. One global skill bundle. The free Knack Starter Pack includes idea-clarifier (turns a vague brief into audience, pain, offer, and a ranked first-action plan; we wrote about the four-section pattern in detail) and first-skill-template (scaffolds a new SKILL.md so you stop forgetting the frontmatter). Install once, use across every repo.
  3. One MCP server. Most likely GitHub. Skip Postgres until you have a schema worth connecting to. Skip the marketplace browse.
  4. A CLAUDE.md per repo. Fifty lines max. Names what the project is, the hard rules (“no AWS”, “no localStorage”, “TypeScript strict”), the package manager, the test command, the deploy target. Pays back on the second day.
  5. One slash command for the workflow you do every week. If you ship every Friday, write /ship that runs your typecheck, test, build, and tag in sequence. Trivial; saves the cognitive load of remembering the four commands.

A minimal CLAUDE.md looks like this:

# Project: <name>

## Hard rules
- TypeScript strict, no `any`.
- pnpm only, no npm or yarn.
- No new dependencies without flagging the trade-off.

## Stack
- Astro on Cloudflare Pages, Worker on Cloudflare.
- Polar for payments. No Stripe direct.

## Commands
- Dev: `pnpm dev`
- Test: `pnpm test`
- Build: `pnpm build`

## What to do when stuck
1. Read `docs/spec.md`.
2. Add to `IDEAS.md` rather than guess.

Five things. Two evenings of work. Done.

What to ignore until you need it

Indie hackers are particularly susceptible to the cargo-cult version of “the stack”. Things to skip on purpose:

  • A subagent zoo before you have a stable workflow. If you cannot describe the workflow in five sentences, a subagent will not fix it; it will just hide the messiness behind a name.
  • More than three MCP servers. Each one is a tax on every session. The marginal value drops quickly after the second.
  • Plugin marketplaces. Anthropic’s plugin marketplace exists in 2026, and the ecosystem is real, but signal-to-noise is still poor for solo builders. Look once a month, install nothing on impulse.
  • Observability tooling. You will know whether the session worked, because you shipped or you didn’t. The dashboards add up to a Saturday you didn’t have.
  • Custom output styles, hook configurations, settings tuning. Tempting, low payoff. The defaults are good. Tune when something specific bites.

The pattern: defer everything that pays off only after the workflow is stable. Build the workflow first.

Where this stack breaks

The stack is good at code generation, refactoring, debugging, documentation, schema work, test writing. It is less obviously good at the launch-day work that decides whether your product gets seen.

Two specific gaps to name out loud.

The launch-week workflow does not write itself. ProductHunt prep, the X launch thread, the Indie Hackers post, the r/relevant-subreddit angle, the comparison page, the launch-day reply cadence, the affiliate kit. All of this is workflow you can author yourself in Claude Code, and almost no second-launch indie hacker does, because they are busy launching. The stack assumes someone has already done the meta-work of turning launch admin into skills and slash commands. If no one has, you are back to a blank page on the Sunday before launch.

Synchronous, not asynchronous. Claude Code is interactive. If you launch over a weekend, the agent is not running while you sleep. Whatever you build has to fit a human attention window: a Friday afternoon, a Sunday morning, a Tuesday lunch. Background jobs that run for hours and post to Slack are a different category of tool, and they are not what this stack is for.

Both gaps are addressable. They are addressable by writing the launch-week workflow once, in skills and slash commands, and re-running it on every product. That is exactly what you would build with the stack, given a Saturday. Most people, on their second product, do not have that Saturday spare.

What this looks like with Indie Hacker Launch

Indie Hacker Launch is the launch-week system for solo founders shipping their second-to-fifth product. Ship Friday, launch Monday, without losing the weekend to launch admin. The pack ships in beta and is open for testers now: free pack access in exchange for blunt feedback.

Apply to test Indie Hacker Launch →