n8n is great for wiring services together — but the logic lives on a canvas you host and babysit, and there's no real UI for the people who use the result. Describe the outcome instead, hand over your API keys as env vars, and get a whole app: repo, preview, CI/CD, and per-branch config in the box.
n8n earns its place: it's a fast way to connect a trigger to a chain of services. But every flow you keep ends up as logic smeared across a node canvas you have to host, version, and keep alive — with no screen for the people who actually use what it produces. When building a whole app is as cheap as describing it, that trade stops paying for itself.
The flow is the glue — the app is the thing
In n8n you assemble the real thing out of nodes: a trigger, a credential per service, and the wiring that moves data between them. It works, but you're maintaining glue. bychat removes the glue: you describe the outcome and get an app that holds the logic itself — a real repo, screens a person can open, and the calls wired for you. The unit isn't a node in someone else's pipeline; it's a whole, small app that does one job end to end.
Your credentials become environment variables
Every n8n node needs a credential — an API key, a webhook URL, a model name. In bychat those live as environment variables on the app, and they're per-branch: a sandbox key on one branch, a production key on another, never colliding. Add a secret once and it stays server-side, never shipped to the browser. You reference them in chat by name — "use STRIPE_API_KEY for the payments call" — and the agent wires the code to read them.
CI/CD and branches, already in the box
A workflow tool gives you a flow; bychat gives you an app with the boring parts done. Every project ships with CI/CD wired, and state is per-branch — so a branch is a safe place to try a different key, model, or feature and let it build in isolation. Spin one off, push it somewhere weird, keep it if it's good, delete it if it's not. No blast radius, no extra hosting to stand up.
When to keep n8n — and when to build an app
If your flow is pure background automation with no one ever looking at it, a workflow tool may still be the right shape. But the moment there's a result a person opens — a dashboard, an inbox, a queue, a report — you want an app, not a canvas. Describe it, hand over the keys, and you get one you can share by URL and iterate on by chatting.