I've written about the Mac mini this agent runs on and about why the agent can't deploy itself. What I hadn't done is put the whole thing side by side with the products people actually pay for: Lovable, Replit, Abacus.AI, Bolt, v0, Base44, and the coding agents that open pull requests for you.
So I asked the agent to do it. It's a little strange to have a system compare itself to its competitors, so I read its answer with that in mind. The matrices below are the result, edited by me. Product details for the others come from public product information and 2026 reviews. They move fast, so check their sites before you decide anything based on this.
Devchitchat is a chat app. An AI agent sits in the channels like a teammate, and anyone in the channel can talk to it. It works in real git checkouts on a persistent disk. When it builds a web app, a proxy gives it a preview URL that starts on first visit and stops when nobody's looking. Git, CI, and issues run on mesh, a peer-to-peer git daemon I wrote. Production deploys go through GitOps: the pipeline pins an image digest into a deploy repo, and a controller in my cluster applies it. Nothing gets pushed without my say-so.
| Primary interface | Built for | What you get | |
|---|---|---|---|
| devchitchat | Multi-user chat channel with an agent in it | A technical owner running their own platform | Git repos, previews, GitOps deploys to your own cluster |
| Lovable | Browser chat + live preview | Non-technical founders, PMs | React/Supabase apps on Lovable's cloud |
| Replit | Browser IDE + agent + design canvas | Beginners through pros | Web, mobile, and data apps hosted on Replit |
| Abacus.AI | Multi-model chat assistant with an agent | Business users who want one AI subscription | Apps, sites, automations, reports |
| Bolt | Browser chat + in-browser dev environment | Fast prototypers | Full-stack prototypes, framework of your choice |
| v0 | Chat + design-to-code | React/Next.js teams | Next.js apps on Vercel |
| Base44 | No-code chat | Non-technical builders | Apps with a built-in backend |
| PR agents (Devin, Cursor, Copilot) | Assign an issue, get a pull request | Engineering teams | PRs in your existing repo |
"Partial" means the feature exists but isn't what the product is built around.
| Capability | devchitchat | Lovable | Replit | Abacus.AI | Bolt | v0 | PR agents |
|---|---|---|---|---|---|---|---|
| Prompt to working app | Yes | Yes | Yes | Yes | Yes | Yes | partial |
| Live preview URL | Yes | Yes | Yes | Yes | Yes | Yes | partial |
| Several people steering one agent | Yes | partial | partial | partial | no | partial | partial |
| Plain git as source of truth | Yes | partial | partial | no | partial | partial | Yes |
| CI/CD defined in the repo | Yes | no | no | no | no | no | Yes |
| GitOps, digest-pinned deploys | Yes | no | no | no | no | no | your call |
| Issue tracker the agent uses | Yes | no | no | no | no | no | Yes |
| Scheduled agent tasks | Yes | no | partial | Yes | no | no | partial |
| Agent has a browser for QA | Yes | partial | Yes | Yes | no | no | Yes |
| Managed DB, auth, payments | no | Yes | Yes | Yes | partial | partial | no |
| Visual editor | no | Yes | Yes | partial | partial | Yes | no |
| Mobile apps | no | partial | Yes | Yes | partial | no | no |
| Parallel agents | no | partial | Yes | partial | no | no | Yes |
| Pick your model | no | no | no | Yes | partial | no | partial |
| Security scan before deploy | no | partial | Yes | no | no | partial | your CI |
| Runs without a vendor cloud | Yes (except the model) | no | no | no | no | no | no |
The "no" answers in my column are real. I don't have a visual editor, I don't generate mobile apps, and there's no managed database waiting for you. If you want a login page and a Stripe checkout by lunch, use Lovable.
| Decision | What I chose | What the hosted products choose | What it costs or buys |
|---|---|---|---|
| Where it runs | A Kubernetes pod on a Mac mini | Vendor cloud | Data stays home. I'm the on-call. |
| Where code lives | Peer-to-peer git across my machines | Vendor database, sometimes synced to GitHub | No lock-in. Replication is my problem. |
| Agent workspace | Persistent disk with real checkouts | A sandbox per project | The agent works across repos like a developer. They all share one disk. |
| Who builds | A separate runner, not the agent | Same system builds and deploys | Writing code and executing privileged builds are different jobs. |
| How production changes | Pinned digest in a deploy repo, applied by a controller | One-click deploy | Every deploy can be audited and reverted. More steps, more latency. |
| How the agent is contained | Its own deployment lives where it can't push. Its deploy power is scoped to one namespace. A human approves. | Trust the vendor | The agent can't rewrite the rules it runs under. |
| Getting to the internet | A tunnel, no open ports | Vendor subdomain | Safe at home, one more moving part. |
| App framework | A small Bun template I maintain | React + Supabase, Next.js | Lightweight. Less training data, so the agent hits gotchas more often. |
| Collaboration | The chat channel is the interface | Single-user editor | A team can steer one agent asynchronously. Less visual. |
| Model | One provider | One provider (Abacus routes across many) | Best agentic coding I've used. One vendor dependency. |
| Where my setup wins | Where theirs wins | |
|---|---|---|
| Time to first app | Lovable, Bolt, and Base44, by a mile | |
| Ownership | Plain git, my cluster, nothing proprietary | |
| Audit trail | Issue → commit → CI run → deploy repo, all in one place | |
| Containing the agent | Approval gates and an agent that can't redeploy itself | Vendor isolation, built-in scanning |
| Operations | Zero. They run it. | |
| Non-technical users | All of them | |
| Polish | Canvases, visual editors, mobile | |
| Extending it | Any tool, script, or pipeline I want | |
| Uptime | A managed service beats one Mac mini |
Three things stood out enough that I'll probably build them:
The hosted builders are optimized for the moment you go from idea to running app. That moment is real and they're very good at it. But most of my career has been spent on what happens after: the integration that breaks at 2am, the deploy nobody can explain, the system nobody remembers how to change. I want the agent's work to land in the same place as mine: git history, an issue, a CI run, a deploy I can revert. And I want the agent unable to change its own permissions, because it doesn't control where its deployment lives.
That's slower on day one. I think it pays off by day thirty.
Field Mappings