n8n Developer in Bangladesh: How to Hire and What to Check

n8n is easy to demonstrate and hard to operate. Anyone can drag four nodes onto a canvas, connect a form to a spreadsheet, and show you a green tick. The distance between that and a workflow that has run unattended for six months, through an API outage, a schema change and an expired token, is the entire job — and it is what you are actually hiring for.

This is a guide to hiring that second kind of person, written from Bangladesh (GMT+6) by someone who builds n8n workflows for a living. The vetting questions below are the ones I would use on myself.

What the job is, once the demo is over

Five things separate a workflow that works from a workflow that keeps working. None of them are visible in a screen recording.

1. Idempotency. If the same webhook arrives twice — and it will, because senders retry — does the customer get two invoices? A workflow that cannot recognise work it has already done will eventually embarrass you in front of a customer.
2. Failure handling. Retries with backoff for the transient errors, and a dead-letter path for the ones that will never succeed, so a single malformed record does not stall the queue behind it. This is covered properly in error handling for automations, which is the article I send clients before we start.
3. Credential hygiene. Keys stored in n8n’s credential store rather than pasted into nodes, scoped to what the workflow needs, and owned by your accounts. Tokens expire; someone has to know which ones and when.
4. Rate limits and batching. Every API has a ceiling. A workflow that loops over 2,000 rows without pacing itself works perfectly in testing with five rows and gets you throttled or banned in production.
5. Versioning and backups. Workflow JSON exported into a repository you control, so a bad edit is a revert rather than an archaeology project. And for self-hosted instances, the encryption key backed up somewhere other than the server — lose it and every stored credential becomes unreadable, which is the single most expensive mistake in self-hosted n8n.

There is also a design decision that comes before any of this: whether each workflow should be triggered by a webhook, a poll, or a schedule. That choice determines latency, cost and how the thing behaves when the other end goes down, and it is hard to change later — webhook vs polling vs schedule walks through how to pick.

Decide cloud or self-hosted before you hire

This is the first question a developer should ask you, and it changes the shape of the engagement, so have a view before the call.

n8n Cloud is the right default for most small businesses. Someone else patches it, backs it up and keeps it running, and you pay per execution. Self-hosting costs a few dollars a month on a VPS instead, has no execution ceiling, and keeps data on infrastructure you control — which stops being a preference and becomes a requirement the moment the workflow touches health records, financial detail, or anything covered by a data processing agreement. The tradeoff is that you now own a server: updates, backups, and the encryption key. Self-hosting n8n is the full setup, including the honest section on when not to.

Whichever you choose, the instance should be in your name. A developer who hosts your workflows on their own server is selling you a hostage, however friendly the relationship is today.

If you have not settled on n8n at all yet, the two comparisons worth reading first are n8n vs Zapier and n8n vs Make — both include the honest cases where the other tool wins, which is usually at small scale.

Six questions that separate a developer from a tutorial

You do not need to be technical to use these. You need to hear whether the answer is specific.

1. “The same webhook fires twice. What happens?” Want to hear: a dedupe key, a lookup against what has already been processed, or an upsert rather than an insert. Do not want to hear: “that won’t happen”.
2. “The CRM API is down for an hour. What happens to the records that arrive during it?” Want to hear: retries with backoff, then a queue or dead-letter store, then an alert, then a replay path. Do not want to hear: “they’d fail and we’d re-run it” without saying how you would know.
3. “Where do the credentials live, and who owns that account?” Want to hear: your accounts, your billing, their access revocable by you.
4. “How do I roll back a workflow you broke last Tuesday?” Want to hear: exported JSON in version control, or at minimum dated exports somewhere you can reach without them.
5. “How will I know it stopped working?” Want to hear: a named destination for failure alerts — an inbox, a Slack channel, a monitoring tool — and something that notices a workflow which has gone quiet, not just one that has thrown an error. Silent failure is the expensive kind.
6. “What would you build differently if this had to handle ten times the volume?” Want to hear: batching, pagination, queueing, moving heavy work out of the main workflow. This question separates people who have operated automations at volume from people who have built them once.

What handover must include

Agree this list before the project starts, not at the end. If a developer hesitates at any line of it, that is your answer about what happens when you eventually want to move on.

• Admin access to the n8n instance, in your name, with their account removable.
• Every workflow exported as JSON, in a repository or drive you own.
• All API credentials held in your own accounts, with the billing attached to your card.
• For self-hosted: server access, and the encryption key stored somewhere other than that server.
• A runbook in plain language: what each workflow does, what it touches, what to check first when it misbehaves, and which failures are safe to ignore.
• Where alerts go, and who is on the other end of them.

Working across GMT+6, for this kind of work specifically

Bangladesh is five to six hours ahead of the UK, ten ahead of New York, four behind Sydney. For automation work that is a better fit than it sounds, because the deliverable is a workflow rather than a meeting: the building is asynchronous, and the synchronous part is a handful of decisions about your process.

There is a small operational bonus too. Scheduled jobs usually run overnight in your timezone, which is the middle of my working day — so a failed nightly run is often caught and fixed before you have opened your laptop. The broader timezone arithmetic is in the guide to hiring an automation consultant in Bangladesh.

What it costs, and how I work

A single workflow — one trigger, one clear outcome, error handling included — starts at $600 and is usually live within three to five days. A connected set wired into your CRM, store or accounting system is $1,800-tier work. Both include 30 days of support after launch, and both are on the pricing page alongside everything else.

I build on n8n, self-hosted where the data justifies it, always in accounts that belong to you, and I hand over the export, the runbook and the keys at the end whether or not you keep me around afterwards. If you want to test the six questions above on a real person, book a free intro call.

Key takeaways

• The demo is not the job. Idempotency, retries, credential hygiene, rate limits and versioning are what you are paying for.
• Decide cloud or self-hosted before you hire — and either way, the instance goes in your name.
• Ask what happens when the same webhook fires twice, and how you would know the workflow had stopped. Silent failure is the expensive kind.
• Agree the handover list at the start: instance access, exported JSON, your own credentials, the encryption key, a runbook.
• Automation is asynchronous work, so the timezone gap costs you little — and overnight runs get watched during the Bangladesh working day.