vs Runwork vs DIY Development
This is the layer you would otherwise build and maintain yourself.
Quick Verdict
You can build all of it. A Next.js app, Postgres behind it, auth, a queue, secrets, an MCP server so your agents can reach it, a deploy path. None of it is hard on its own, and once it exists it is yours. Runwork is that layer already running, plus the parts that always get postponed: permissions on what agents can touch, an audit trail of what they did, and some way to tell whether anyone besides you is using it. Your agent writes the code either way. The question is what it has to write on top of.
Overview
Teams doing this seriously end up building roughly the same stack. Somewhere for agents to connect over MCP. Somewhere for skills to live and sync to everyone's machine. Entity and file storage. A scheduler for the jobs that must survive a closed laptop. Secrets. A sandbox so an agent can run code without touching your laptop. A deploy path. Then the team layer: who is allowed to run what, what did it do last Tuesday, and is anyone besides the person who wrote it actually using it. That last part is the one that never gets scheduled, and it is why most internal AI setups end up with one user. Runwork is that stack, running. Claude Code, Cursor, and Codex work against it over MCP, the platform hands your agent the knowledge files during dev, and every app you deploy becomes an MCP server the rest of the team's agents can call.
DIY Development is a Custom Code (Next.js, Laravel, Rails).
Runwork Strengths
- Your agents reach it over MCP. Claude Code, Cursor, and Codex work against the real workspace, not a guess at it.
- The platform provides CLAUDE.md and AGENTS.md during dev, plus a generated SKILL.md per app.
- Every app you deploy becomes an MCP server, so everyone else's agent can call it too.
- Entities, file storage, schedules, and workflows are already there. No queue to stand up.
- `runwork dev` runs in a remote sandbox. Nothing installed locally, and an agent cannot wreck your machine.
- `runwork deploy` ships it. No pipeline, no hosting decision, no DNS afternoon.
- Roles, permissions, and audit logs across everything, including what the agents did.
- 3,300+ integrations with credentials handled, instead of an OAuth dance per service.
- Skills sync to every teammate's AI tool, so what you worked out reaches people who will never read your repo.
DIY Development Strengths
- Total control. Every dependency, every version, every architectural call is yours.
- Any language, any framework, any host.
- Nothing sits between you and the runtime when you are debugging at midnight.
- The ecosystem is enormous. Every problem you hit has been hit and written up already.
- Data can stay entirely inside your own network.
- No commercial dependency. Your stack outlives any vendor, including us.
Feature Comparison
The agent layer
| Feature | Runwork | DIY Development |
|---|---|---|
| MCP endpoint your agents can reach | Per workspace and per app | Write and host your own |
| Knowledge files (CLAUDE.md, AGENTS.md, SKILL.md) | Provided by the platform | Maintain by hand |
| Sandbox to run agent code | `runwork dev`, remote | Docker on your laptop |
| Skills that sync to every teammate's AI tool | - | |
| Works with the AI tools people already use | 60+ AI tools | Config per machine |
What you would otherwise stand up
| Feature | Runwork | DIY Development |
|---|---|---|
| Auth and sessions | Built in | Clerk, Auth0, or your own |
| Database and migrations | Entities | Postgres, ORM, migrations |
| File storage | Built in | S3 plus a CDN |
| Scheduled and background work | Schedules and workflows | Redis, a queue, a worker |
| Secrets and credentials | Managed per workspace | Vault or env files |
| Integrations | 3,300+ integrations | Build each one |
| Deploy | `runwork deploy` | Pipeline plus hosting |
The team parts people postpone
| Feature | Runwork | DIY Development |
|---|---|---|
| Role permissions on what agents can touch | Built in | On the roadmap |
| Audit trail of every action | Build it | |
| Somewhere the whole team can find it | Workspace and desktop app | A link in Slack |
| Is anyone actually using it | Adoption dashboard | - |
| Versioning and backups | Built in | Set it up |
| Monitoring | `runwork log --events` or dashboard | Stand up a logging stack |
Ownership
| Feature | Runwork | DIY Development |
|---|---|---|
| Real code you can read and edit | TypeScript and React | |
| Export to Git | It is already yours | |
| Self-host | - | |
| Runs inside your own network | - | |
| Pick your language and framework | - |
Which Tool is Right for You?
Choose Runwork if you need...
- * Teams who would otherwise spend a quarter building this layer
- * Giving your agents a real place to run instead of somebody's laptop
- * The permissions, audit, and adoption parts that never make it into a sprint
- * Work that does not stop when the person who set it up logs off
- * Letting the rest of the team use what you built without cloning your repo
Choose DIY Development if you need...
- * Anything that has to run inside your own network
- * Your product, not your internal work. Custom architecture, unusual runtime, heavy scale
- * Hard compliance or data residency requirements
- * Stacks where you need control of every dependency and version
- * Teams who enjoy owning the infrastructure and have the people to do it
Pricing Comparison
DIY has no invoice, which is what makes it look free. The real cost is hosting, a database, an auth vendor, monitoring, a queue, the engineer weeks to wire them together, and the ones after that spent keeping it alive. Runwork is priced per seat with a monthly usage budget with a 14-day trial, no credit card. Compare it against a quarter of somebody's time, not against zero.
View Runwork pricingHow to Migrate from DIY Development
Nothing you know goes to waste. It is TypeScript and React, the code is code you can read and export, and your git habits still apply. What changes is that you stop maintaining the layer underneath it.
Typical migration: Hours for the first one
Pick the thing you were about to build
The internal tool sitting in the backlog, or the script that only runs on one machine. Start there instead of migrating anything.
Point your agent at the workspace
Claude Code, Cursor, or Codex connects over MCP. The platform hands it CLAUDE.md and AGENTS.md during dev, so it writes against the real API instead of hallucinating one.
Let it build in the sandbox
`runwork dev` runs remotely. Nothing to install, nothing an agent can break on your machine, and a live preview before anyone else sees it.
Ship it
`runwork deploy`. Auth, roles, audit, and hosting are already on. The app becomes an MCP server, so your teammates' agents can call it from day one.
Move the shared parts up
Skills and workflows sync to the whole team's AI tools. That is the part you cannot replicate with a repo everyone has to clone and configure.
Frequently Asked Questions
Is this a replacement for our stack?
Can I see the code?
What if we outgrow it?
Can I use my own AI tools?
Can we self-host it?
Explore Runwork Features
Try Runwork for yourself
Start a free trial. No credit card required.