Thanks to the n8n team for putting together the training courses! After completing N8N101, N8N102, and N8N103, I’d love some advice from experienced n8n freelancers and automation consultants.
Which demo projects would be the most valuable to build for my portfolio to demonstrate to potential clients on Upwork that I can solve real business problems with n8n?
I’m particularly interested in which projects offer the best return on time invested — projects that are relatively quick to build but demonstrate valuable, practical skills that clients are willing to pay for.
What would you recommend I focus on first? Should I prioritize CRM integrations, AI-powered workflows, lead generation, email automation, or something else entirely?
I’d appreciate any recommendations based on your experience working with real clients and winning projects.
Welcome to the community! For a portfolio aimed at Upwork clients, pick projects that map to a pain a business already pays to fix, not clever technical demos. The ones that reliably win interviews: an error-monitoring workflow (Error Trigger to your channel, carrying the execution ID, the failing node and a link to the execution); an intake pipeline (form or webhook, validate, enrich via an API, write to Sheets or CRM, notify) with duplicate handling; a scheduled digest or report job; and an AI step that classifies or drafts but has an explicit fallback when the model is unavailable. Build two or three of these end to end rather than ten shallow ones, and for each write a short README stating the business problem, the tradeoffs and the failure paths you handled, because that reasoning is what a technical client is screening for. A two-minute walkthrough recording of each workflow also converts better than the JSON alone.
@SimonKnudsen short answer from the other side of this: build the thing you can demo in conversation, not the thing that looks impressive in a screenshot.
The projects that get you hired are ones where you can say “here is the broken version, here is what I changed, here is what it costs now” — because that is the conversation you will actually have. Three that consistently pay:
-
An AI agent that takes an action and escalates properly. Booking, triage, quote generation. The demo is not the happy path, it is what happens when the input is ambiguous or the tool fails. Most applicants show the happy path and clients cannot tell the difference between them and a chatbot.
-
Something with a retrieval step and citations. Ask a question, get an answer with a source attached. Anyone can build RAG in an afternoon now, so the differentiator is what you do when retrieval is wrong — confidence thresholds, refusing out of scope, showing which document the answer came from.
-
Something with observability attached. A workflow where you can show latency, token cost, and every tool call per request. Very few people do this and it is the thing that separates someone who builds demos from someone who runs systems in production. If you have never wired tracing into your workflows, do that next — it is a differentiator and it takes an afternoon.
What I would avoid: anything requiring a lot of paid API setup to demo, because you will not have access at the call, and anything that needs a client’s data to be interesting.
On CRM integrations specifically — they demo well but they are close to commodity and the clients who want them are usually the ones who want to talk about price. I would build one as a supporting credential and lead with the agent or observability work instead.
If you want one concrete suggestion: build an agent that does enquiry-to-booking with a proper escalation path, and instrument it end to end so you can show the trace during a call. That single demo covers the agent, the integration, the failure handling and the observability, which is four portfolio pieces in one.
Happy to look at what you have built if useful.
I’d start with one small intake-to-CRM demo, then make its test results part of the portfolio. You can keep the first version simple: webhook → validate required fields → create/update a contact → notify someone. Use fictional data.
Give yourself five acceptance tests:
- A valid enquiry creates the expected contact.
- Missing email goes to review rather than creating a broken record.
- The same enquiry submitted twice does not create two contacts.
- An unavailable CRM leaves the enquiry recoverable.
- A failed notification does not cause the contact to be created again.
For each test, show the input, expected result and actual result. Include setup instructions and a sanitized JSON export. That gives someone a way to judge the work beyond the canvas screenshot. Once this is solid, add AI classification as an optional branch instead of making the whole demo depend on an AI API.
Which type of business are you hoping to work with first? That would help narrow the fields and follow-up rules.
@operantsolo, so I actually just built that automation (or am in the process of finishing it). Regarding the five acceptance tests, I have two questions:
1. Missing email addresses
Wouldn’t this be preventable by making the email field required in the form? Is there still a reason to validate it again in the workflow?
2. CRM unavailable
If the CRM is unavailable, how would you ensure the enquiry is still recoverable? Would you typically store it somewhere temporarily and retry the CRM operation, or is there a better best practice for handling this in n8n?
3. Stress testing
I’m also considering adding another acceptance test: what happens if 100 people submit the lead form at the same time?
What’s the best practice for stress-testing a workflow like this? Would you use k6, Postman, or another tool? And how would you determine whether the workflow can handle that kind of load reliably?
Good questions. I’d handle these at three different layers.
1. Validation: Even when a form requires an email, I’d validate again inside n8n. Webhooks can receive requests from sources other than your form, and external integrations can send missing or malformed fields.
2. CRM unavailable: I’d persist the validated inquiry before attempting the CRM operation. PostgreSQL would work well here. Each inquiry gets a unique ID and a processing status. If the CRM fails, the record remains available for a later retry.
I’d also use an upsert or stable idempotency key where supported, so retrying doesn’t create duplicate contacts.
3. Stress testing: I’d use k6 to simulate 100 concurrent submissions with unique test IDs. I’d measure successful requests, failed requests, response times, duplicate records, and whether every accepted inquiry eventually reaches the CRM.
One important test is making the CRM unavailable during the load test, then restoring it and checking whether the pending inquiries recover correctly.
My background is primarily backend development with TypeScript, PostgreSQL, and API integrations. I’m applying these reliability patterns to my own n8n automation projects.
Are you running n8n Cloud or self-hosting it? That would affect how I’d approach concurrency testing.
Thanks for the feedback!
Interestingly enough, I just ditched the built-in n8n Assistant and tried using Claude Code with MCP to get feedback on the workflow. The difference was huge, and it also helped me implement some of the points you mentioned.
I’m running n8n Cloud for now. One thing I’m a little concerned about is what happens if a client requires the workflow to be self-hosted on their own infrastructure, since I have no experience managing that side of things yet.
As a beginner, would you recommend sticking to n8n Cloud for now and positioning that as the default, or should I start learning how to deploy and manage self-hosted instances as well?
Learn it, but don’t make it your default. Most small clients will never run Docker, so Cloud (or a VPS you manage for them) stays the right answer by default — but the moment a job touches an internal database, a client’s own network, or data that isn’t allowed to leave the building, self-hosting is on the table, and being able to say “yes, on your own server” instead of “no” is what wins those jobs.
A cheap weekend-long path: one small VPS, n8n in Docker Compose with Postgres, TLS via Caddy, a nightly pg_dump plus a copy of the N8N_ENCRYPTION_KEY (back up both together, or the credentials in your backup are unusable), then import the exact workflow JSON you already built on Cloud. Practise by migrating one of your own demo workflows and running it for a week — that is what teaches upgrades, backup restores and the things that actually break (memory limits, proxy headers, webhook URLs behind a reverse proxy).
Price the setup separately from a monthly maintenance fee, because the ongoing ops is the real cost. Keeping your Cloud instance as the reference environment works well: same JSON in both places, demo fast, deploy self-hosted when a client needs it.
Yes, validate again in the workflow. A required form field improves the normal browser experience; it doesn’t stop someone posting directly to the webhook, or another integration sending an empty value.
For CRM failures, persist the enquiry first, then acknowledge receipt. Give it a stable enquiry ID and a status such as pending, completed or needs review. Retry the CRM step from that saved record, not the entire form submission. If a request times out after possibly reaching the CRM, reconcile it before creating another contact.
For your 100-submission test, start against a mock CRM or a sandbox. Check two outcomes separately: how quickly the webhook accepts the request, and whether every accepted enquiry eventually reaches the destination exactly once. Also submit the same ID twice and cut the CRM off partway through. 100 concurrent requests is a burst test; it isn’t the same as 100 requests per second sustained.
On your later hosting question, I’d keep Cloud as your current demo environment and learn self-hosting on a disposable test setup. Before offering to manage a client server, practise an actual backup restore and upgrade rollback—not just starting the container.
For learning, I’d move one demo workflow onto a VPS before trying a client project. I run Suji Cloud, where n8n has a one-click install. You’d still handle updates and backups. Is the server setup what’s holding you back?
