Install · Use it · How it feels · Compare · FAQ · GitHub

_{The guide (python tools/keel.py), on a real project: the one next step in plain words, the journey from idea to ship, and every document Keel has written.}

What is Keel?

Keel is a free, open-source system that turns a one-sentence idea into a complete, buildable, shippable product. Think of it as an AI founding team in your terminal: a business analyst, a market researcher, a product manager, a designer, a software architect, a QA engineer, and a security auditor, each an AI specialist that does its part of the 0 to 1 work and hands you a real deliverable.

Most AI tools help you generate a prototype in minutes. Keel helps you build a real product: one that is planned, designed, tested, secure, and grounded in an actual business case, using the AI coding tool you already pay for as the engine. You bring the idea and the decisions. Keel does everything else and tells you the single next step at every point.

Keywords: AI app builder, idea to MVP, idea to production, build a startup with AI, AI product manager, spec-driven development, AI market research, PRD generator, vibe coding done right, Claude Code workflow, Cursor workflow, open-source AI developer tool.

The magic-wand loop

flowchart LR
    I([Your idea]) --> D
    subgraph R [the specialists do the thinking]
      direction LR
      D[1 Discover] --> P[2 Define] --> DS[3 Design] --> A[4 Architect]
    end
    A --> F{5 Feasibility}
    F -->|revise| D
    F -->|GO| PL[6 Plan] --> B[7 Build] --> S[8 Secure] --> SH([Ship])
    B -.->|next task| B

The research steps each spawn a specialist AI subagent that writes a real document, not a stub. The feasibility gate checks all three plans together: is the product coherent with the business, is it buildable with your tools, can you afford to run it? If not, it says REVISE and tells you exactly what to fix. And whenever Keel finds a weakness, in your idea, your product, or your code, it never leaves you there. It always hands you the fix.

Does Keel actually write the code?

Yes. Keel is not just a planner. Once the plan passes the feasibility gate, Keel drives your AI coding tool through the entire build: it picks the next task, writes production-grade code (real data paths, every state, every error, no mocks or TODOs), writes the tests, proves the security, and moves to the next task. It writes the whole product.

What makes Keel different from using a coding agent on its own is the judgment around the code:

• it works out what to build and why (the business case and the product spec),
• it builds in the right order (a dependency-ordered plan, so nothing is built before the thing it needs),
• and it proves the result is real (/audit verifies "done" against a written definition of done, and /secure proves no user can read another user's data).

Raw coding agents write code fast and guess at the rest. Keel removes the guessing.

Production quality, enforced (not hoped for)

Most AI tools will hand you code full of mock data, TODOs, and happy-path-only functions, and call it done. Keel will not. Quality here is enforced by gates that fail the build, not by good intentions.

Gates that run on every change:

Laws the code is written against, in rulebooks the AI reads every session: every error is typed with a stable, greppable code (VAL_, AUTH_, NOTFOUND_, DEP_, and so on) and never silently swallowed; no personal data in logs, ever; functions stay small and single-purpose; the same logic is never pasted twice, so a fix is made in one place; a bug is root-caused and reproduced before it is called fixed; and secrets are scanned on every write.

The judgement a linter cannot make is done by a code-reviewer specialist before a push: spec drift, silent failures, a missing empty or error state, a test that only covers the happy path. Every weakness it finds arrives with the fix that closes it. That is a law here, not a courtesy.

This is the line between code you can demo and code you can ship.

Works with any AI tool (open or closed)

Keel is built in layers, and only the top one is tied to a specific tool:

So: best with Claude Code, where the commands, agents, hooks, and security gate are native. But it works with any AI coding tool, Cursor, Codex, Aider, Cline, Windsurf, Gemini CLI, open-source or closed, because every command is a prompt file the AI reads, and the repo ships an AGENTS.md (the emerging cross-tool standard) plus a Cursor rules file as the universal entry point. And the tracker, the gates, the security proof, and the guide run with no AI at all. Nothing here is locked to one vendor.

Your project's own toolkit, found and vetted for you

You should not have to know which open-source tools, skills, or MCP servers your project needs. /equip sends a tool-scout to find them, for your exact stack: the MCP servers the AI can use, the Claude Code skills and plugins, the dev and quality tools, the libraries. It vets every one for safety (what it does, what it can access, whether it touches your data or secrets) and recommends a small, focused set, because piling on twenty tools just costs the AI focus. Anything that could touch your data or credentials is never added without your explicit yes. The vetted list lives in your repo, and the safe tools get wired in for you.

Install it (start here)

What you need first

1. Python 3.10 or newer. Check with python --version. Get it from python.org (tick "Add Python to PATH" on the first screen).
2. An AI coding tool. Claude Code is the smoothest fit. Cursor, Codex, or any tool that reads files and runs commands also works.
3. Git. From git-scm.com if git --version fails. (Keel's installer can set your project up if this is missing.)

The easiest way (recommended for everyone)

git clone https://github.com/Bhargs24/keel
cd keel
python install.py ~/my-product      # the folder for your new product

The installer is a concierge: it creates the folder, sets up version control, asks "is it just you building this?" with no jargon, and offers to open the guide.

Then open the guide, which shows you the next step at every point:

cd ~/my-product
python tools/keel.py

Your browser opens to a friendly cockpit: a progress rail from Idea to Ship, one plain-English "your next step" card with the exact words to copy, and every document Keel writes, readable in the browser. It even explains itself, with a short "how this works" panel built in. Do the step it shows, and the page moves to the next one on its own. No refresh, no remembering commands. Keep going until you have shipped.

The developer way (install as a Claude Code plugin)

/plugin marketplace add Bhargs24/keel
/plugin install keel

Then run python install.py <your-repo> once to lay down the project structure, and use the commands in that repo.

On Windows? Everything works. Use python tools/run.py check wherever older docs say make check. Keel prefers the Python runner so nothing depends on tools you may not have.

Use it

You do not drive the tools. Keel does. You say what you want in plain words; it picks the next step, runs it, and tells you in one line what happened. When something is genuinely your call (a name, a budget, a real trade-off), it asks. Otherwise it proceeds.

The whole thing, in three moves:

1. Give it your idea. In the guide, or by typing /keel "your idea in a sentence" in your AI tool.
2. Approve each step. Keel researches the business, defines the product, designs it, plans the build, and audits whether it holds together, pausing at each gate to show you what it found.
3. When it says GO, it builds the product, task by task, testing and securing as it goes. Ask /next any time to see what is next.

Already have a spec? Drop your documents into spec/, run /plan, then /work.

The three commands to remember: /start when you sit down, /next to find out what to do, /wrap when you stop. Everything else, Keel reaches for on your behalf.

And you never have to memorize the rest. The guide shows every command and what it does, right on the screen, with a marker on the one you are up to:

Twenty commands, three groups: the pipeline (/keel through /plan), the build loop (/work, /review, /audit, /test, /equip, /secure, /ship, and more), and the anytime navigation (/status, /board). The full reference with what each spawns is in docs/01-INDUCTION/COMMANDS.md.

A tracker that knows what is next

Keel ships a real, dependency-aware task tracker (plain Python, file-per-task in git, no dependencies). /plan loads your build roadmap into it; from then on the build loop leans on it:

$ python tools/track.py status
Progress   1/3 done (33%)   todo 2  doing 0  blocked 0  review 0  done 1

$ python tools/track.py next
Ready now
  TODO   T-002   Build the login flow     # T-003 stays hidden: it depends on this

next only ever surfaces a task whose dependencies are met, so nothing is built before the thing it needs, and finishing one unlocks the next automatically. /board opens the same thing as a visual board in your browser:

Easy by design

Keel is built so a first-time builder never freezes. It talks the way a good mentor does: one short question at a time, in plain words, and it never dumps a wall of steps on you. The long plans and the details live in the guide and the documents. The conversation stays calm.

Two rules make this true, and they run on every message:

• The conversation law: one question at a time, short plain answers, no jargon, and the depth kept in the guide rather than pasted into the chat.
• The paired-honesty law: whenever Keel finds a weakness in your idea, product, or code, it hands you the fix in the same breath. It is never only a critic, and never a wall of problems with no way forward.

How Keel compares

Prompt-to-app builders are great for a quick demo, then you hit the wall: no real spec, no plan, no proof it works, and you are locked into their platform. A raw coding agent writes code fast but guesses at what to build and whether it is right. Keel gives you the whole path, and you own it.

What Keel produces

A complete, professional document set, plus the working product. Every document is written to a hard rigor standard: deep and exhaustive, not a summary; researched, with every external claim cited inline (source, URL, date) and a Sources list; written to the real professional format for that artifact. This is the difference between Keel and a chatbot that hands you an outline: it writes the actual document.

_{A real run: the whole document map, from the business case through the technical plan, each one Keel writes and you can read in the guide.}

• Business: the company narrative, vision and values, positioning against a real moat (the 7 Powers, not hand-waving), market and competitor analysis, unit economics stress-tested with a downside case, a defensibility analysis, a pre-mortem, a financial model (P&L, burn, runway), a fundraise ask, and the real monthly cost to run, rebuilt from prices checked today.
• Product: it starts with the person, the target user's psychology and the behaviour the product has to create, not a feature list. Then a master PRD and per-module specs with prioritized, testable requirements, jobs-to-be-done, success metrics, a product roadmap, real-world scenarios, and every screen state, so the product is built around how people actually think and act.
• Design: a design brief, a design system (colors, type, components), and real HTML mockups of the key screens, covering every state.
• Technical: the architecture, a justified tech stack, the data model, a security and privacy design, the infra and CI/CD, a setup runbook, the accounts to set up, and a dependency-ordered build roadmap.
• The product itself: production-grade code, tests that cover the risk, and a security proof, built task by task and tracked in git.

Scaled to what you are building. A serious company gets the full set (around thirty documents). A weekend project gets a focused one (the concept, the product, the design, the plan). A side project has no business carrying a fundraise deck, and a funded startup with no unit economics is flying blind. Knowing which one you are, and giving it exactly the rigor it needs, is part of the point.

The specialists

Each is a focused AI mind with a clean context and one job, defined in .claude/agents/.

trespass: security you can prove

Broken access control, one user able to read or delete another user's data, is the single most common way AI-built apps leak, and the one class ordinary scanners cannot catch, because catching it needs to know who is supposed to see what.

Keel ships trespass, a formal analyzer for Postgres and Supabase row-level security. It compiles every policy into logic and either proves no user can reach another's rows, or hands you the exact query that shows they can:

That is a real run: a policy a developer would plausibly write, proven unsafe by the solver, with the counterexample and the fix. Not a linter guessing at patterns, a proof.

Written from scratch on the standard library, validated against Z3 and a real Postgres, it runs in the gates and in /secure, and it fails your build when a policy leaks. Details: tools/trespass/README.md.

FAQ

Click any question to open its answer.

Who Keel is for

• Founders and indie hackers turning an idea into a fundable, buildable, shippable product.
• Product managers and designers who want a spec, a plan, and a build that follows them.
• Engineers and small teams who want AI speed without losing quality, ownership, or security.
• Anyone hitting the wall with a prompt-to-app tool and needing to reach real production.

Why I built Keel

I'm Bhargav, and I have taken a product from an empty folder to real users on my own. In about three months I shipped an edtech product solo, end to end: two mobile apps live on the App Store and Google Play, a backend API, three web consoles, and a content engine behind them, five languages in production, used by real students. Not a prototype. A deployed product with everything a real one has, and I built every side of it myself: the business case, the product, the design, and the engineering.

Then I did the part almost everyone skips. Before a line of the next version existed, I wrote its specification: a product spec of 180 screens, each with its real states (loading, empty, error, permission-denied, not just the happy path); 290 build steps put in dependency order so nothing is ever built before the thing it needs, checked mechanically to zero ordering violations; and every screen traced end to end to the step that builds it, so nothing gets discovered missing in production. Around half a million words of it. I rebuilt the financial model from prices I checked that day and caught my own earlier numbers understating the true cost to run by 6.7x.

That is the experience Keel is built from. Not that I can ship, but that I know what a product actually needs, across business, product, and technical, and how much rigor each part deserves. A weekend project should not carry a competitor analysis; a funded startup skipping its unit economics is negligent. A product is not a feature list, it is whether the person you built it for will actually use the thing. Working all of that out end to end, alone, is slow and expensive.

And it taught me where the real difficulty now sits. When AI writes code this fast, building stops being the bottleneck. The hard part, the part that decides whether what you ship is any good, is knowing what to build and why, for the person you are building it for, and in what order. Every AI tool out there turns a spec into code brilliantly, and every one assumes you already wrote the spec. Most people have not, and the people who need it most are the least sure what a good one contains.

So I built Keel to be the thing I wish I had had: it does that thinking with you, whether you are a seasoned engineer or have never written a line of code, and then it keeps the build honest against it, all the way to production. It carries the product and business judgment I learned the slow, solo way, so you do not have to.

The ideas it is built on

1. Anything a person must remember is a rule that will eventually be broken. So a rule must run, be checked, or be short enough to hold.
2. The AI is the operator, not the instructor. It never tells you to run a command it can run itself.
3. Every weakness travels with its fix. Keel can tell you your idea is weak because it never leaves you there.
4. Choosing what to build next is a machine's job. /next ranks the candidates and shows the reason.
5. "Done" is verified, not declared. /audit walks a task against its written definition of done.
6. "Secure" is proven, not assumed. /secure proves the permission boundary rather than trusting it.
7. Feasibility is a gate, not a hope. The business, the product, and the build are audited together before you build on them.