Hi, I’m Pony, founder of Weft. I’m looking to connect with n8n implementers who work on SaaS customer-request workflows across support, product and engineering.
To be clear: I’m validating the service and have no client build to refer yet. This is an exploratory partner introduction, not an open paid job or a promise of work.
Weft’s package covers reviewing one workflow, mapping the current and proposed process, defining owners and required data, and documenting exception paths and acceptance checks. Implementation is separately scoped.
The collaboration I’d like to explore is: Weft prepares the process brief; an implementer checks technical feasibility and, if there is a suitable client project, quotes the build separately. Access, APIs, hosting, monitoring and support responsibilities would need agreement before any build.
For example, a customer update should depend on confirmed release availability for that account, rather than just a task moving to Done. I want the handover brief to explain that rule and what happens when data is missing or a sync fails.
If this kind of collaboration fits your work, what would you need in a process brief before you could assess and quote it? A short reply about your relevant experience is enough; no unpaid demo or proposal is requested.
Hi Pony — I’m Oleksandr, a full-stack engineer with 3 years of AI/n8n automation experience at DreiAI. I have built production n8n and API workflows, LLM-assisted document/invoice processing with structured outputs and validation, and integrations with human-reviewed exception paths. For a feasibility check, I’d need the trigger and data sources, exact business rules and status conditions, required systems/APIs and access model, expected volume, exception cases, owners, and acceptance checks. I’m happy to assess a clearly scoped build and quote implementation separately; I’m based in Vienna, Austria.
Hi Pony, thanks for being upfront that there’s nothing to build yet. I build n8n and Make automations for small businesses, mostly intake, routing and follow-up, which is a lot of what customer-request workflows come down to. Happy to be on your list. When you’ve got a real client flow, send it over and I’ll take a look.
I build n8n and Supabase workflows, so your rule that a customer update should depend on confirmed release availability for that account, not a task moving to Done, is the kind of brief I can assess.
The closest real build is my lead triage pipeline. Python fetchers pull posts on a schedule, dedupe and score them, and an LLM drafts a response. A rule-based validator then checks every draft. A failed draft gets one retry with the exact failure fed back. A second failure goes to a human-review queue with an email alert, and every action is written to an append-only ledger. That is the missing-data and failed-sync handling you describe.
I also run a missed-call text-back line, where a Supabase edge function verifies the Twilio signature, texts the caller back and logs the miss to Postgres.
To be plain, my n8n workflows are self-hosted and test-built on localhost with synthetic data, with no client production. My production automation runs as Supabase edge functions and Python workers.
In a brief I would need the source systems and their APIs, the owner of each step, the required fields, the missing-data and sync-failure paths, and the acceptance checks.
I can walk through the real builds on a live screen-share, and I work about 20 hours a week, US Eastern.
Hi Pony, adding one thing to the lists above: put 5-10 real (anonymized) examples in the brief, each with the input data and the exact outcome you expect, including the messy ones like missing account data or a sync that fails halfway. Rules are enough to quote from, but examples catch the “oh, that’s not what we meant” moments before the build starts, and they become your acceptance tests. Full disclosure: I’m with Pond AI, we build custom AI agents and workflows around the tools a business already uses. Would you want implementers to see a brief before it goes to the client, or after?
Thanks all — the access model, expected volume and exception paths are useful additions to the handover brief. I’ve noted the introductions and the distinction between test-built workflows and production experience.
@mahathir_lol: my intended sequence is to agree the problem and desired outcome with the client first, then involve an implementer before finalizing any technical scope or build estimate. The client can review a draft process map earlier, with unverified integrations clearly marked. A feasibility review or integration test would be separately agreed and scoped, not assumed to be free.
The anonymized input/expected-output examples are a useful addition, especially for missing data and partial failures. They should come from the client with permission and feed into the acceptance checks.
There is still no active client build, so there’s no need for a demo, proposal or further work at this stage. I’ve noted your introductions here and can revisit fit when there is a concrete brief. Thanks for the practical input.
CRASH-PROOF SAAS WORKFLOW ORCHESTRATION: VALIDATING THE EXCEPTION PATHS
Hi Pony,
Your approach to separating process discovery from pure node wiring is exactly how enterprise automation should be designed. Moving an account to ‘Done’ based on release availability rather than a loose state mutation requires strict, deterministic data boundaries. A naive sync logic will collapse under concurrency or create severe data drifts if third-party webhooks fail mid-transit.
I am a Senior AI Automation & Backend Infrastructure Architect specializing in transforming probabilistic system layers into crash-proof production realities.
Here is how I architect and validate the exact exception paths your briefs require: Idempotency & State Protection: To ensure a SaaS customer-request workflow never double-fires during peak sync surges, I deploy native Redis lock primitives (INCR + TTL gates) as atomic idempotency boundaries directly within the data paths. This safely isolates system transitions across 1.2M+ daily external payload vectors.
2. Absolute Structural Determinism: Instead of passing raw JSON bodies between support, product, and engineering tools (Jira, HubSpot, GitHub), I wrap extractions inside hardcoded Pydantic validation schemas. If required data is missing or a sync fails, the exception path triggers an isolated, stateful Human-in-the-Loop (HITL) triage queue rather than throwing an unhandled 500 error.
3. Production Metrics & Telemetry: Every workflow I deploy tracks token consumption and p50/p95 latency from the first execution, backing the network with global Error Trigger loops for instant alerting.
Audit the exact quality, data modeling logic, and crash-proof design of my live configurations straight from my verified GitHub repository: https://github.com
To assess a Weft process brief, I primarily require: 1) The exact API rate limits & authentication contracts of the target SaaS stack, 2) The deterministic boolean rules for your state transitions, and 3) The boundary parameters for your retry budgets.
I’d love to explore an implementation partnership. Let’s connect via forum DM or drop a sample blueprint my way at: katreshital11@gmail.com
Your release example is a good one. A ticket in Done usually means the code is merged. It doesn’t tell you the feature is live for that customer’s account, so an update sent on status alone can go out too early. Most of the work is mapping which field or event really means “available for this account”, and what the flow does when the data doesn’t match.
My experience is smaller than a SaaS support/product/engineering setup. I built an n8n flow for a bakery: it reads order emails in Gmail, Gemini pulls out the order details, then it creates a Google Doc, sends a Telegram alert and logs the order in Google Sheets. Same shape on a small scale: messy input, a check, and a message only after the data is confirmed.
To assess and quote, I’d need the brief to cover:
trigger and source systems, and whether they have API or webhook access
the exact condition for each customer update
who handles exceptions
where the workflow would be hosted
Would the first pilot start from the support tool or from the issue tracker?
Hi Pony, I can see why we would want to do a handoff like this. Also I can understand the separation of the process brief vs the implementation.
For my quoting purposes I think I mainly need - the systems we are dealing with - trigger & expected outcome - api/access restrictions - exceptions - expected volume - acceptances
I’ve dropped you a DM with some more detail.
For Weft’s illustrative pilot, I’d start with a small batch of requests from the support tool, preserving the source conversation and customer/account ID. Product would review them before accepted work is linked to the issue tracker. That lets us test the handoff manually before choosing an integration trigger.
For a real client, the starting point would depend on where reliable request records already live; there is no client pilot scheduled yet. The issue tracker would track delivery, while any customer update would still require a separate check of availability for that account. Thanks for spelling out the scope of your experience.
Makes sense. Starting with a small batch from the support tool also shows early how clean the account IDs are. If the same customer shows up under different emails or workspaces, the availability check later depends on fixing that first.
When you have a client brief, I’m happy to look at it and tell you what is doable in n8n and what would need more access. What’s the best way to reach you, here in the forum or by email?
Hi Pony! Interesting model — separating the process brief from implementation is a clean way to scope. I work on n8n/SaaS integrations and would be glad to check technical feasibility on a sample workflow and quote the build separately, exactly as you described. More about me: https://endigita.com
Hi @pony_weft , thanks for being upfront that this is exploratory. Your split, Weft writes the process brief and an implementer checks feasibility and quotes the build, is one Pond AI can fit into.
Briefly on experience: Pond AI builds custom AI agents around a client’s own tools, and runs a marketplace where people and AI agents compete on a task and the buyer pays only for results they accept. Each task starts with a written definition of what “done” looks like, which is close to your acceptance checks. Pond AI has 100,000+ users in 150+ countries and has run tasks for teams at ElevenLabs, Google Cloud and GPTZero. Most of that work has been lead generation, people-finding and video, so SaaS customer-request workflows would be new ground, and I’d confirm fit per project.
To your question, here’s what I’d need in a brief before quoting:
Source of truth per state: which system and field confirms “release available for this account”.
Linking IDs: how a request ties to a ticket, a release and an account, and what happens when they don’t match.
Systems and access: APIs, auth, rate limits, and whether a sandbox exists.
Exception paths with owners: missing data, a failed sync, a rollback. Who’s told and what the customer sees.
Send rule: what goes out automatically and what goes to a person first.
Acceptance examples: five to ten real cases with expected outcomes, including one with missing data.
Run and support: who hosts it, who gets alerts, and who fixes failures after delivery.
If a client project comes out of Weft, Pond AI can take the brief and come back with a design and a quote, and the build comes with a 7-day refund.
Disclosure: I’m affiliated with Pond AI.
For this collaboration, I would approach it by first reviewing the process brief you provide, identifying the triggers, steps, and defining the data flow required for the workflows. I would assess the technical feasibility based on the outlined requirements, including how exceptions will be handled if data is missing or a sync fails. The deliverable would include a comprehensive document detailing the workflow structure and any necessary API integrations. To proceed, I would need clarity on the specific data sources and systems involved, as well as any constraints or specific client needs you anticipate.
Here in the forum works well for now, Artem. For anything that needs to stay private, you can reach me at pony@withweft.app. There’s no client brief ready yet; thanks for offering to review feasibility when a suitable project comes up.
Hi Oleksandr, your production n8n/API work and human-reviewed exception handling look relevant to what Weft may refer. Could you share one existing, anonymized delivery example, including how failures and maintenance were handled? It would also help to know your usual lead time and how you price technical discovery before a build estimate.
Would direct client contracting suit you, with Weft handling the process brief and handover? I’d also be open to referrals the other way when a buyer needs help clarifying the business workflow or responsibilities before technical scoping. Introductions would be with client consent, and your technical discovery would remain your scope.
There’s no active build yet, so no custom demo or proposal is needed. You’re welcome to send commercial details privately to pony@withweft.app.
Hi Cindy, thanks for offering to stay in touch. Your Make/n8n intake, routing and follow-up work looks relevant to the smaller implementations Weft may refer. Could you share one existing client example, especially across several tools, and how you handle exceptions and support after launch? A brief anonymized description is enough.
It would also help to know your typical availability, any minimum project size, and whether technical discovery is a separate paid stage. The intended arrangement is for you to agree implementation scope, pricing and delivery directly with the client while Weft prepares the process brief and coordinates handover.
I’m open to referrals in the other direction too, where a buyer needs help clarifying the business workflow or responsibilities before a build. Any introduction would be with client consent, and your technical discovery would remain your scope.
No active project yet, so no custom proposal is needed. Commercial details can go privately to pony@withweft.app.
Hi Pony, thanks for explaining the collaboration. I build automation workflows using Make and n8n. My recent builds include lead qualification, contact enrichment, duplicate checks, and personalized outreach preparation using APIs, Google Sheets, and Gmail.
Before assessing feasibility and quoting, I’d need the workflow trigger, connected systems and API access, required data, decision rules, expected volume, exception handling, and acceptance criteria. Hosting, monitoring, and ongoing support responsibilities would also help define the scope.
I’d be interested in connecting for suitable future projects and can share examples of my existing workflows.
CRASH-PROOF SAAS WORKFLOW ORCHESTRATION: VALIDATING THE EXCEPTION PATHS
Idempotency & State Protection: To ensure a SaaS customer-request workflow never double-fires during peak sync surges, I deploy native Redis lock primitives (INCR + TTL gates) as atomic idempotency boundaries directly within the data paths. This safely isolates system transitions across 1.2M+ daily external payload vectors.
Audit the exact quality, data modeling logic, and crash-proof design of my live configurations straight from my verified GitHub repository:
