Start with the outcome, not the tool
Before you contact anyone, write three sentences: what starts the process, what should be true when it finishes, and who is affected if it fails. A developer who asks for those, rather than quoting immediately, is thinking about your problem. If the answer turns out not to need n8n, a good one will tell you.
What to put in the brief
The more of this you can provide, the tighter and fairer the quote.
- The trigger: webhook, schedule, new record, incoming message, form submission.
- Every system the workflow touches, and whether each has an API, a ready-made n8n node or neither.
- Rough volume: ten runs a day or ten thousand changes the design.
- What should happen when a step fails, and who should be told.
- Where data is allowed to live, especially personal or financial data.
- Who will maintain it and how technical they are.
What actually drives the cost
Node count is a poor proxy for effort. The real drivers are the number and quality of integrations, because an undocumented API costs far more than a standard connector; error handling and retries, which are often more work than the happy path; data volume and rate limits; any AI step that needs testing on your real data; and whether the build includes hosting, monitoring and handover. A cheap quote that omits error handling and documentation is usually a deferred cost.
We give a fixed scope and estimate before starting. Anything outside it is quoted separately, so there are no surprise invoices.
Red flags
Watch for these when comparing developers or agencies.
- A demo with no failure handling: ask what happens when the API returns an error at step four.
- Credentials pasted into nodes or shared in chat instead of stored as proper credentials.
- No documentation or export of the workflows at handover.
- Promises about connecting to a system without checking it has an API.
- A workflow built on the developer's own n8n account with no plan to move it to yours.
What a good handover looks like
You should receive the workflows in your own n8n instance, a short document describing each one in plain language, a list of credentials and where they are used, the alerting that tells you when something fails, and a recorded walkthrough. The test is simple: could someone on your team keep this running if the developer disappeared tomorrow?