Waymaker is an AI-powered platform that helps entrepreneurs and builders launch successful businesses. It combines AI technology with psychology-based accountability to guide you from idea to income.

How is Waymaker different from other app builders?

Waymaker combines AI building tools with psychology-based accountability coaching. It doesn't just help you start—it helps you finish, with checkpoints, an AI accountability partner, and a gated 10-stage method that only moves you forward once you have real evidence.

Do I need coding skills to use Waymaker?

No coding skills required. Waymaker's AI builder handles the technical complexity while you focus on your business strategy, design, and launch. Our multi-agent system builds production-ready apps from your ideas.

How long does it take to launch with Waymaker?

Timelines vary by business, but the platform guides you through the Waymaker Method — a 10-stage gated path (Compass, Opportunity, Advantage, Validate, Define, Build, Launch, Grow, Operate, Exit) — all with AI assistance and accountability.

What kind of support do I get?

You get 24/7 AI accountability coaching, daily check-ins, momentum tracking, and access to our builder community. Plus, dedicated customer support and comprehensive documentation to help you succeed.

Can I try Waymaker before paying?

Yes! Plans start at $29/mo (Waymaker Core). Human coaching is included from Waymaker Guided ($99/mo). Explore all features and see if Waymaker is right for your business journey.

Free tool · No signup

Build the agent file you actually want to work with.

Pick from 24 rules we actually use running Claude Code on a real production codebase, edit the wording to fit how you work, and download a ready CLAUDE.md or AGENTS.md. Nothing to sign up for, nothing saved on our end.

Git & Version Control

Never force-push to main or shared branchesA force-push can silently erase teammates’ work with no easy recovery.

Don't amend a commit that's already pushedAmending after a hook failure can quietly rewrite history other people or CI already saw.

Confirm before destructive git operationsThese commands discard work with no undo, and it’s easy to run them out of habit.

Merge to main via pull request onlyPRs create a paper trail and a checkpoint before code reaches production.

Code Quality

Comment the why, not the whatComments that repeat the code rot the moment the code changes; comments that explain a non-obvious reason keep paying off.

Don't build for hypothetical future requirementsSpeculative flexibility usually guesses wrong about what actually changes later, and it costs real readability today.

Match existing conventions before introducing new onesConsistency inside a codebase matters more than any individual style preference.

Prefer editing an existing file over creating a new oneNew files fragment logic that was easier to find in one place, and most "new file" instincts are really edits in disguise.

Testing & Verification

Write a failing test before the implementationA test written after the fix can pass for the wrong reason and never actually prove the bug is gone.

Run the tests — don't assume from reading the diffReasoning about code and executing code catch different classes of mistakes.

Evidence before "done"Confident-sounding claims without evidence are how silent regressions ship.

Security

Never hardcode credentialsHardcoded secrets end up in git history and diffs forever, even after you "remove" them later.

Validate at system boundariesTrusting internal calls but checking the edges keeps validation logic from spreading everywhere while still closing the real attack surface.

Flag likely vulnerabilities instead of silently patching themSecurity issues deserve a visible decision, not a buried one-line change nobody reviewed for that reason.

Deployment & Config

Don't hardcode model or SDK versions from memoryA model ID that was current when training data was collected can 404 in production months later.

Run a real production build before reporting successDev mode forgives import errors and type mismatches that a production build will not.

Batch related changes, don't deploy per fixFrequent tiny deploys multiply the chances of a bad deploy and make it harder to tell which change caused an issue.

Working With You

Ask before hard-to-reverse or shared-system actionsThe cost of a quick confirmation is low; the cost of an unwanted irreversible action is not.

When a request is ambiguous, make the reasonable call and say soConstant clarifying questions slow work down more than an occasional corrected assumption does.

One-sentence plan before, short summary afterIt keeps the person in the loop without burying the useful signal in noise.

Don't create documentation files unless askedUnrequested docs pile up and go stale, and most of the time the conversation itself was the documentation.

Planning & Task Tracking

Track multi-step work explicitlyExplicit tracking survives context growing long, and it shows real progress instead of a wall of scrollback.

Check for duplicate or in-flight work before buildingTwo independent efforts building the same thing is expensive and avoidable with one search first.

Fix root causes, not symptomsBypassing an obstacle usually just moves the same failure downstream to someone with less context on it.

9 rules selected

# CLAUDE.md

This file provides guidance to Claude Code when working with code in this repository.

## Git & Version Control

- Never use `git push --force` on main or any shared branch. If a force-push seems necessary, stop and explain why before doing it.
- Never commit directly to main. Branch per task, open a PR, and let review or CI gate the merge.

## Code Quality

- Don't write comments that restate what well-named code already shows. Only comment a hidden constraint, a workaround for a specific bug, or something that would genuinely surprise a reader.
- Don't add config flags, abstractions, or error handling for scenarios that can't currently happen. Three similar lines beat a premature abstraction.

## Testing & Verification

- Before saying a change works, actually run the relevant tests or the app and read the real output. A diff that looks right is not the same as a diff that runs right.

## Security

- API keys, tokens, and passwords always come from environment variables or a secrets manager, never as literal strings in source.

## Deployment & Config

- After a change that could affect the build, run the actual build command and check for errors, not just a passing type-check or dev-server reload.

## Working With You

- Before deleting data, force-pushing, sending messages, posting publicly, or changing shared infrastructure, say what you’re about to do and confirm first.

## Planning & Task Tracking

- For any task with three or more distinct steps, keep an explicit task list and update it as each step finishes, rather than holding the plan only in context.

Built by the team behind Waymaker

An AI Cofounder that already works this way, from idea to income, not just a file generator.

See the Accelerator →