Hi, I’m Pony, founder of Weft.
I offer a planning package for SaaS teams whose customer requests pass between support, product and engineering. If you are considering Make to connect those steps, the first task is defining what should happen, who owns it and what to do when a connection fails.
For one workflow, the package includes:
- A review of the current process and up to 30 redacted request records.
- Current and proposed flowcharts, with owners, required information and exception paths.
- Recommendations on what to keep manual and where an integration may help, with access requirements and assumptions for an implementer to verify.
- A phased rollout plan and acceptance checks, followed by a handover and one revision.
For example, a task marked done should not automatically trigger a customer announcement: someone needs to confirm deployment and whether that customer’s account can use the change. The plan makes that check explicit.
This is a planning engagement. Building or debugging Make scenarios is not included. Any implementation would need a separate scope and technical validation.
Here is an illustrative sample, not a client result or a ready-to-import Make scenario: Weft | Sample SaaS workflow improvement blueprint
If your team is deciding what to automate across these handoffs, tell me where requests get stuck. You can reply here or contact [email protected].
To assist with your workflow planning for Make, I propose a structured approach that includes a thorough review of your current processes and the analysis of up to 30 redacted request records. I will create flowcharts that identify ownership, necessary information, and exception handling for each step. Additionally, I will outline recommendations for manual versus automated processes, specifying access requirements for implementation. If anything is unclear, please specify which aspects of the current process you find most problematic or any specific goals you have in mind for the automation.
Gilbert, GL Tools (Vienna, written communication)
Hi Gilbert, thanks for taking the time to respond. I should clarify that Weft offers workflow assessment and planning—I’m not looking to commission an assessment.
I’m exploring potential implementation partners who could take an agreed workflow plan, validate the technical approach, and scope the build directly with the client. I don’t have an active client project to refer yet.
Is that something you’d consider? If so, what would you need in a brief before assessing a Make implementation?
I will review the agreed workflow plan, validate that each step can be built in Make, identify any connector gaps, estimate build steps and data flows, and draft a scope document for your client. Steps: 1) examine plan details; 2) map triggers, actions, and data mappings; 3) check authentication and API limits; 4) identify missing connectors or custom coding; 5) produce validated plan + formal scope. I’ll need the included workflow JSON, source and target systems, data volume estimates, and any performance or compliance constraints.
Gilbert, GL Tools (Vienna, written communication)
Hi Gilbert, thanks—that helps clarify your approach.
One point on the inputs: Weft would provide a process brief with workflow maps, business rules, example inputs and expected outcomes, and acceptance checks. We wouldn’t normally have an existing Make scenario or workflow JSON.
Would you be comfortable taking that brief through technical validation, building and deploying the scenarios, and separately agreed ongoing support? Your reply describes the validation and scope document clearly; I’d like to understand whether you also cover delivery.
If so, could you share one relevant example and explain how you typically price technical discovery before quoting a build? The intended arrangement is for you to agree implementation scope, pricing, and delivery directly with the client, with Weft coordinating the handover.
There’s still no active client project, so no custom proposal or demo is needed at this stage.
Hi Pony, yes - I cover delivery, not only the scope document.
Starting from a process brief (workflow maps, business rules, example inputs, expected outcomes, acceptance checks) is how I prefer to work. No existing scenario or JSON is needed:
- Technical discovery: I check every step against the Make modules and APIs involved (auth, rate limits, missing connectors, where a webhook or small script is needed), list the rules that need a client decision, and return a short validation note with a fixed build price. I charge a flat EUR 74 per workflow for this, credited in full if the client goes ahead with the build.
- Build and deployment in the client’s own Make organisation: error handlers on every external call, duplicate protection on webhooks, a test run against your example inputs, and the acceptance checks run and documented.
- Handover: blueprint export, setup guide and a run log. Ongoing support as a separate written agreement is fine.
One relevant example, a scheduled automation with a written handover: Beispiel: Wochenbericht automatisch | GL Tools
Agreeing scope, price and delivery directly with the client, with Weft coordinating the handover, works for me. Everything in writing, in English or German.
Gilbert, GL Tools (Vienna)
Hi Gilbert, gotcha, that clarifies the delivery scope and how you work from a process brief. I’ve noted the EUR 74 discovery fee, credited toward the build, and the separate support agreement. Thanks for sharing the example too.
The direct-client arrangement sounds like a good fit to explore. When a suitable project comes up, I’d suggest sending you a short anonymized brief first so you can check fit and availability before we arrange an introduction.
I’d also be open to referrals in the other direction. If you meet a prospective client who needs help clarifying their business workflow, responsibilities, or priorities before technical scoping, Weft could help with that assessment. Your technical discovery and implementation would remain your scope, with introductions made with the client’s agreement.
Would that two-way arrangement suit you, and what’s your preferred contact method for future briefs? There’s still no active project, so no further proposal is needed for now.
Pony
Hi Pony, yes, the two-way arrangement suits me.
Sending a short anonymised brief first is a good way to do it: I reply within one working day with fit, open questions and when I could start, and only then we arrange the introduction.
In the other direction: when a prospect comes to me with an unclear process (who owns which step, what should happen when something fails), I will suggest your assessment first and only make the introduction with their agreement.
For future briefs, email works best: [email protected]. A forum message here is fine too.
Gilbert, GL Tools (Vienna)