Build a Side Project with Hermes + Claude Code in One Weekend (2026)

Last tested and updated: June 2026

You have two harnesses on your machine and one weekend. What can one person actually ship in 48 hours using both? Hermes for thinking, Claude Code for building. That pairing is the lesson.

The hook

Here’s a real weekend, the kind someone on the team shipped in June 2026:

Friday 7pm. Open Hermes, ask for five product angles on a niche you already know well. Pick the smallest one. Ask Hermes to draft the spec: features, data model, edge cases, test plan. Save it to SPEC.md. Stop for the night.

Saturday morning. Open Claude Code in a fresh repo, paste the spec, watch the loop run. Spec → test → fix → spec → test → fix. By evening there is a working API and a basic UI.

Sunday. Open Hermes again. Ask it to verify the build against the spec. Diff the gaps. Open Claude Code for the close-out: write the README, add the screenshots, deploy. Ship by midnight.

That’s it. One person. Two harnesses. One weekend. No heroic weekend coding sessions, no copy-paste boilerplate, no “I’ll finish it next week” projects that never ship.

The shape works because each harness is doing what it’s good at. Hermes thinks. Claude Code builds. Mix them up and you waste time.

The mental model

The single idea behind this lesson: Hermes is for thinking, Claude Code is for shipping.

If you try to remember nothing else, remember the four-step flow above.

Step 1 — Sketch (Hermes). Before you write a line of code, you need an angle. Hermes reads your niche knowledge, your saved links, your notes from the last six months. It gives you three product angles ranked by weekend-fit. You pick one. This step takes 20 minutes. It saves you from building the wrong thing.

Step 2 — Spec (Hermes). Once you have an angle, Hermes writes the spec. Features as bullets. Data model as a table. Edge cases as a list. Test plan as a checklist. Save it as SPEC.md in a new folder. This file is the contract between you and Claude Code on Saturday morning.

Vague spec breaks Saturday. Specific spec flies.

Step 3 — Code (Claude Code). On Saturday, open Claude Code in a fresh repo. Paste the spec. Let the loop run: spec, test, fix, repeat. Claude Code verifies by running tests. That’s exactly what you want for code that has to work. This is the step that actually ships the thing.

Step 4 — Review (Hermes). On Sunday, open Hermes again. Point it at the spec and at the codebase. It produces a gap analysis: what’s built, what’s partial, what’s missing. Take that list back to Claude Code for the close-out pass.

Why this works. Each tool is doing what it’s designed for. Hermes is in its element during steps 1, 2, and 4 — research, structured writing, comparison, gap analysis. Claude Code is in its element during step 3 — code, tests, fixes, iteration. Neither tool is fighting its nature.

Why one tool alone doesn’t work. Hermes alone means you spend Saturday writing code in chat. The loop is slow. Claude Code alone means you spend Friday evening brainstorming in chat. The spec drifts. The two together cover the whole weekend without gaps.

What this looks like in your terminal

Friday evening, two Hermes commands get you most of the way:

• /brainstorm-angles — produces three product angles, ranked, with a “weekend-fit” score.
• /write-spec — takes the chosen angle and produces a SPEC.md with features, data model, edge cases, test plan.

Saturday morning, one Claude Code command and a cup of coffee:

• “Read SPEC.md. Implement feature by feature. Run tests after each. Commit when green.”

Sunday afternoon, one more Hermes command:

• /verify-spec — diffs the codebase against the spec, outputs a gap list.

That’s the whole flow. The tools carry the typing; you carry the taste.

Pick your tool

The hard part isn’t the tools — it’s the boundary between them. Here’s where each one stops and the other starts.

Step	Tool	What it produces	What you do
Brainstorm angles	Hermes	Three ranked product angles	Pick one
Draft the spec	Hermes	SPEC.md	Edit for taste, save
Implement the build	Claude Code	Working code + green tests	Review the diff
Verify the build	Hermes	Gap analysis vs spec	Decide ship-or-fix
Close-out (README, deploy)	Claude Code	Production-ready repo	Hit merge

Rule of thumb: markdown output goes to Hermes. Working code with green tests goes to Claude Code. Cross the boundary as few times as possible. Every cross costs you context.

When one tool is enough

You don’t always need both. Here’s the honest decision:

• Hermes alone is fine for research, daily automation, multi-channel orchestration, and writing-heavy projects (newsletter, weekly digest). Anything covered in L04 — Skills and Skill Bundles and L08 — Automation lives here.
• Claude Code alone is fine for shipping software, refactoring an existing codebase, or one-off code questions. The full Claude Code workflow is in L01 — Coding with Claude Code.
• Both together is for projects that need a real spec and a real build, in a tight timeframe, by one person.

The weekend-build pattern is the third case. It’s not the default — it’s the escalation when you actually want to ship something with both rigour and speed.

Where Hermes’ agents.md fits

If you’re running the weekend-build pattern, write an agents.md at the root of your project directory before you start. It tells Hermes the project context, file conventions, spec tone, model preferences. Without it, you repeat the context-setting on every Hermes call. With it, Hermes loads it once and stays consistent.

The agents.md file is not read by Claude Code — that’s CLAUDE.md or .cursorrules territory. Keep them separate. The reason: Hermes wants a long-form project brief; Claude Code wants a short list of repo-specific rules. Different shapes, different files.

Try it

The exercise

Pick one product angle you already have domain knowledge in. It should be small enough that one person could realistically ship it in a weekend. Then run the four-step flow over the next 48 hours.

Step 1 — Friday (30 minutes total). Open Hermes. Run /brainstorm-angles with your niche as input. Read the three options. Pick the one with the smallest surface area and the clearest “done” condition.

Step 2 — Friday (1 hour total). Run /write-spec with the chosen angle. Edit the output for taste. Save as SPEC.md. Don’t worry about perfect — worry about specific. “User can upload a CSV” is good. “User can do data stuff” is useless.

Step 3 — Saturday (6–8 hours). Open Claude Code in a fresh repo. Paste the spec. Implement feature by feature. Run the test suite after each feature. Commit when green. Stop for the night when the loop stops being fun.

Step 4 — Sunday (3–4 hours). Open Hermes again. Run /verify-spec against the codebase. Read the gap list. Open Claude Code for the close-out: fix the gaps, write the README, deploy, push.

Success criteria

You’ll know it worked if:

• By Sunday night, you have a deployed URL you can show someone.
• The SPEC.md matches the shipped behaviour (no drift).
• You didn’t write any glue code yourself — only spec edits and gap-fix decisions.
• You’d be willing to do it again next weekend.

If you don’t have a URL by Sunday night, the spec was probably too vague. Tighten it and try again next weekend with a smaller scope.

A realistic scope check

A weekend-build project is roughly:

• 2–5 features, each describable in one sentence.
• 1 data model, with 3–7 fields.
• 1 user flow, end-to-end (signup → use → result).
• 0 auth complications (skip login for the weekend; add it later).
• 1 deployment target (Vercel, Fly, or a single VPS).

If your spec has more than that, the weekend will slip. Cut features, not time.

What’s next

• L02 — Vibe Coding vs Real Coding
• L04 — Skills and Skill Bundles
• L08 — Automation
• L04 — Niche Directory Sites

Check your understanding

See the standalone quiz at /lessons/ai-projects/L03-building-with-hermes/quiz.json (6 questions).