n8n 客製工作流程如何用一份設定檔避免重寫並維持 $79 固定收費

My $79 Fixed-Price n8n Builds Are One Config File: How I Ship Custom Workflows Without Rewriting Them

Part of my build-in-public series on running LLM workflows in n8n in production. This one is about the economics of custom work: how I sell fixed-price "built for you" n8n builds without every client turning into a rewrite. The trick is boring on purpose — the workflow never changes, only the config does.

The problem with fixed-price custom work

I sell fixed-price n8n builds (starting at $79) on my AI Automation Lab storefront. The classic freelancer trap with fixed-price custom work: every client has "just a small tweak," and six tweaks later you've rewritten the workflow and the $79 turned into twelve hours of your life.

I refuse to reprice per client, because the moment the price depends on a scoping call, I'm selling hours again. So the architecture had to make customization cheap enough that $79 stays profitable. The answer: I don't customize the workflow. I customize a config file.

Every client build is the same canonical workflow, parameterized end to end. A new client means a new 40-line JSON config, not a new workflow. Here's the exact machinery.

The canonical workflow

Take my inbox triage pipeline — the most common thing clients ask for ("sort my inbox, draft replies, escalate the important stuff"). The workflow itself is generic:

1. Config node — a single Set node at the top named CLIENT_CONFIG. It holds one JSON object and nothing else. Every node downstream reads from it.
2. Fetch — Gmail trigger → get messages. The filter comes from config: which labels to watch, which senders to always escalate, which domains to ignore.
3. Classify — LLM node with a prompt assembled from config: the client's categories, their escalation rule in plain words ("anything from an existing customer mentioning refund goes to urgent"), and two few-shot examples drawn from the client's own past emails.
4. Draft — reply draft node using the client's tone contract: formality level, signature, language, and the hard rule list ("never promise a refund, always offer the tracking page first").
5. Route — urgent goes to Slack/Telegram (destination from config), drafts land in Gmail drafts, everything gets logged with the config version stamped on the execution.

The workflow JSON is identical across clients. What differs is the config:

{
  "client": "acme-widgets",
  "config_version": 3,
  "gmail": { "watch_labels": ["INBOX"], "ignore_domains": ["newsletter"], "always_escalate_senders": ["vip@bigclient.com"] },
  "categories": ["order-status", "refund-request", "partnership", "spam"],
  "escalation_rule": "anything from a paying customer mentioning refund, chargeback, or broken goes to urgent",
  "tone": { "formality": "casual-professional", "language": "en", "signature": "— Sam, Acme Widgets support" },
  "hard_rules": ["never promise a refund amount", "always link the tracking page first"],
  "notify": { "urgent_channel": "telegram", "urgent_chat_id": "..." },
  "schedule": { "poll_minutes": 10, "quiet_hours": "23:00-07:00" }
}

Forty lines. A new client is a new forty lines.

Three rules that keep the config from becoming a second codebase

A config-driven workflow dies the same death as an over-abstracted framework if you let the config grow teeth. Three rules keep it honest:

Rule 1: the config surface stays small on purpose. If a client asks for something the config can't express — a second approval step, a different LLM for one category, a human-in-the-loop gate — that's not a config change, that's a scope change, and it gets a new quote. The config is a menu, not a programming language. Saying "the config doesn't do that" is the most profitable sentence in the fixed-price business.

Rule 2: a validator node runs first, always. Right after CLIENT_CONFIG, a Code node validates the config against a schema: required fields present, chat IDs non-empty, quiet-hours format sane, categories ≤ 8 (more than eight and the classifier's accuracy falls off a cliff — that's an empirical number from my own runs, not a guess). An invalid config fails the execution in the first 200 milliseconds with a message naming the exact field, instead of failing weirdly at 3 a.m. in the classify node. I learned this the embarrassing way: a missing urgent_chat_id once silently swallowed every urgent escalation for two days because Telegram errored and my error handler treated it as non-fatal.

Rule 3: stamp the config version on every execution. The validator also writes config_version into the execution's metadata log. When a client says "it used to escalate these and now it doesn't," the first question isn't "what changed in the workflow" — it's "which config version ran." Nine times out of ten, they edited the config themselves and forgot. The version stamp turns a debugging session into a diff.

The honest numbers

A fixed-price build breaks down like this: 30–45 minutes on a scoping call to fill the config with the client (this is the real product — the call where "sort my inbox" becomes eight categories and a tone contract), 20 minutes to write the config and two client-specific few-shot examples, 30 minutes to deploy and test against their real inbox, and a 15-minute handoff where they learn the one rule that matters: edit the config, never the workflow.

Total: about two hours of my time for $79. The workflow itself was amortized months ago — it's the same canonical pipeline my $29 Inbox Triage template ships as. The client isn't paying for invention; they're paying for the config to be filled in correctly by someone who's already made the mistakes.

What kills the margin isn't the build — it's scope masquerading as config. "Can it also check our Shopify orders?" is not a config line; it's a second workflow. The config menu is the contract, and the contract is what keeps $79 fixed.

The failure mode I'm still watching

Config-driven builds have one failure mode I haven't fully solved: config drift by confident clients. The handoff teaches them to edit the config, and eventually someone "improves" the escalation rule into something the classifier can't follow, or adds a ninth category. The version stamp catches it after the fact, but I'd rather catch it before. What I'm testing: a pre-save dry-run mode where the validator runs the new config against the last 50 real executions and reports what would have changed. Classification replay as a config linter. If it works, it becomes part of the template; if it doesn't, the version stamp stays the safety net.

The takeaway for n8n builders

If you ever plan to sell custom n8n work — or even just deploy the same workflow for two teams — build the config node first, before the first real node. Every hardcoded value you write in week one is a rewrite you'll do in month three. The discipline is simple: the workflow contains logic, the config contains decisions, and the validator node is the bouncer between them. Fixed-price custom work only works when customization is filling in a form, not editing a program.

I'm building AI Automation Lab — production-ready n8n workflow templates, plus fixed-price custom builds (from $79) via the Contact page. The canonical pipeline in this post ships as the AI Inbox Triage & Reply Drafter ($29); the free AI Hook Generator is the zero-risk way to see how I build. My open-source patterns live at github.com/zhp910318/n8n-ai-automation-lab.