I spent the last year building an AI agent in a startup as the first engineer, technically I can build anything I want, I'm also an ex-founder so I have the business side skills as well.
I have many ideas, the hardest part is knowing which one to choose (what to build), tips?
I spent the last year building an AI agent in a startup as the first engineer, technically I can build anything I want, I'm also an ex-founder so I have the business side skills as well.
I have many ideas, the hardest part is which one to choose (what to build), tips?
Some businesses could easily run 150K workflow executions per month. On n8n pricing, that adds up to around $30K/year. If you run 500K executions per month, you are looking at roughly $74K/year. At that volume, pricing becomes huge, so I built the parts that mattered most from the Business plan: multi-stage environments (dev, staging, prod) and Git versioning.
If workflows are running in production, you cannot keep editing production directly. The normal software loop is needed: dev, staging, prod with backups.
From here, it gets more technical. The high-level idea is simple though: use dev for changes, staging for testing, prod for real execution, and Git as the source of truth between them.
The setup has three environments: dev, staging, and production. Dev is where workflows are modified. Staging is only for testing before production. Production is never edited directly. GitHub sits between them as the promotion and deployment mechanism, but the environment flow is dev -> staging -> prod.
The runtime stack is Docker Compose: n8n, PostgreSQL, Redis, Caddy, and workers. n8n stays the workflow runtime. The platform around it handles delivery and operations.
The export script pulls workflows from dev, splits encrypted credentials by ID, commits the changes, and pushes them to the dev branch. From there they move through staging and production via pull requests.
Git is the source of truth and the promotion mechanism. The JSON diffs mostly exist to detect that a workflow changed, not because people are supposed to review workflow JSON by hand.
The system keeps encrypted credentials in Git, split into one file per credential ID. On deployment, the script compares credential IDs in the repo with IDs already present in the target environment. It imports only new ones.
That means staging and production can keep their own credential values. A dev export does not overwrite production secrets by accident.
Staging deploys when the staging branch changes. Production deploys from main, with approval. The scripts pull the repo, start the right Docker profile, import missing credentials, upsert workflows, and normalize export formats.
One annoying n8n detail: when workflows are exported from dev and imported into staging or production, n8n deactivates them. So the deployment needs to detect which workflows were marked active in the export, then use the n8n API to activate them again after import.
