What Steepworks is
Choose the work that matters, coordinate people and agents, and see what changed and what it took. Use it for software, research, launches and new ways of working. It's the system we build with, and it works with the coding agents you already use.
Your team
Steepworks
Your coding agent
What's inside
Your team and agents do the work. Steepworks handles the plan, the money, the people and the proof.
Plan
Start with the result you want. Steepworks turns it into a goal, milestones and tasks, each with a plain “done when”, written down and versioned so nobody re-briefs the next person or agent.
In the product
Project goal, milestone planner and task documents. plans.preview
and plans.apply
from the CLI or API.
Budget
Fund a stage and set its ceiling. Each run reserves against that ceiling before it starts, or it doesn't start. Usage is recorded with the model, the rate and who pays.
In the product Budget tab, stage funding and spending limits for the account, application and project.
Team
Owners, reviewers and the questions they answer stay with the spec. Agents show up on runs, never as assignees or approvers.
In the product
Inbox and page comments. pages.propose
for agent-drafted edits that a person reviews and applies.
Hand-off
Every task has one accountable person and the context to act on it. For software, a work order carries the goal, spec and checks to the coding agent you choose and comes back as a pull request with a record of the run.
In the product
Work orders, runs.start
and runs.update, and local runs on your own machine.
Checks
Evidence fits the work: a reviewed document, research with its sources or, for software, tests, a review against the “done when”, code review and a preview. An agent saying “done” is never the evidence; a named person accepts.
In the product Acceptance by a named person. For software, a GitHub App that is read-only by default and pull request checks.
Record
The build map shows what was built, what it used and where people stepped in, so the next project starts from evidence instead of memory.
In the product Usage per run, rolled up by milestone and step. See an example
What stays put
What you agree lives in records you can open, edit and trace, not inside a chat. Start simple and open more detail only when the work needs it. Parts still being built are marked Planned.
A shared goal, the people involved, tasks, budget and sign-off. Start with a name and the result you want.
The intended result and instructions in plain writing, one accountable person and a clear status.
Shared, versioned pages for the plans, research and decisions behind the work. A page doesn't need a project.
Your queue of decisions, reviews and assigned work.
Ask about a project in plain language and get an answer drawn from its records. Decisions, spending and sign-off stay with people.
Results you keep reviewing after a project ends, connected to every project that contributes.
Teams, dated assignments and capacity, so you can see who is needed where and when.
One view of what changed and where you're needed, with every figure linked to its source.
Built by builders
Steepworks is the system our builders use to run the builds we deliver. Use it with your own team, bring in a Steepworks builder, or both. The goal, budget and people stay attached to every run, whoever is at the keyboard.
Meet the builder approachBring your own agent
Three ways to connect
The steepworks terminal client and stdio MCP server. Sign in with a
device code, pick a project, and let your coding agent discover commands, take placed
tasks and report runs.
steepworks auth login --workspace-write
steepworks do tasks.list --in PROJECTREST and stateless MCP over HTTPS. Explicit scopes, observed versions, idempotency keys and durable receipts on every mutation. One command catalog, discovered at runtime.
POST /api/v1/mcp
POST /api/v1/workspace/commands/:commandThe web workspace for the people around the build: set the goal, review the spec, answer questions, fund stages, accept results and read the map. No terminal required.
steepworks.com/appAfter the build
Milestones across. Steps down. Cell intensity is Steepworks credit use. Markers show where a person gated, rejected or redirected the work.
| Step | M1 Scope and data prep | M2 Booking flow | M3 Exceptions and handoff | M4 Rollout |
|---|---|---|---|---|
| Context and planning | 0.6M | 0.3M | 0.2M | 0.1M |
| Implementation | 0.9M | 2.4M 3 retries | 1.1M | 0.3M |
| Evaluation | 0.2M | 1.2M | 0.7M | 0.2M |
| Human review | — Accepted | — Rejected, then accepted | — Redirected | — Gated |
| Rework after review | — | 1.6M | 0.3M | — |
| Milestone total | 1.7M $85 | 5.5M $275 | 2.3M $115 | 0.6M $30 |
| Result | Accepted · paid | Accepted · paid | Accepted · payable | Awaiting release |
Credits map to outcomes
Every credit has a state and a provenance. Estimates and measured usage stay distinct, fixed-price work is never billed twice, and missing cost is reported as unknown rather than zero.
Model comparisons can inform future work. A cost estimate cannot prove what an alternative build would have cost or how well it would have worked.
Human in the loop, measured
Reviews, approvals, rejections and redirects are steps in the build, not interruptions around it. Each one shows what it cost in time and credits, what it prevented, and where a gate held work longer than it needed to.
Agents never hold authority. Imported text, page blocks and checkboxes don't create work, complete tasks, accept scope or authorize spending. People do, and the record shows when.
Common questions
No. A project can produce research, a process, a campaign or a partner pilot, with evidence that fits the work. Software adds code checks on top; it isn't required.
Start from a goalKeep them. Your harness builds; Steepworks decides what is ready to build, holds what isn't, and keeps the record of why. It owns the goal, spec, budget, review and map, not the editor.
No. Extending a site, connecting existing systems, or changing a workflow may be the right answer. A new application is an option, not a requirement.
Yes. Tell us who will build and which harness they use. We'll confirm the supported connection and review responsibilities during planning.
Start with the result you need and the current state of the project. We'll agree a bounded review, place what exists into milestones, work out what it cost and quote the next work where the findings support it.
Review an existing buildCost estimates and targeted comparisons can inform the next build. They cannot establish the cost or quality of an alternative build that was never run.
Build something new. Modernize what exists. Connect what you have.
We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect