I am Jorge, based in Spain. I build practical AI-assisted automation systems for small businesses and founders.
Best fit projects for me:
- n8n workflows with APIs, webhooks and clear handover documentation
- WhatsApp/customer follow-up flows
- appointment/calendar logic and reminders
- CRM-style automations, lead intake, deduplication and status updates
- Airtable / Google Sheets / forms / email integrations
- LLM workflows with structured prompts, fallback paths and testing
- debugging existing workflows when data mapping or routing is breaking
To be transparent: I do not present myself as a traditional senior developer who codes everything from memory. My strength is AI-assisted development: understanding the process, breaking it into clear steps, using AI/tools/APIs/n8n, testing with real cases and documenting the result so it is usable.
Current work:
I am open to small paid test builds, workflow audits, debugging sessions or fixed-scope MVP automations. Remote/async preferred.
Hey Jorge — I liked the paid test build framing. It feels more concrete than promising a full build upfront, especially when the scope is still unclear.
One thing I’d be curious about: when you structure a paid test build, do you usually scope it around a single integration, like WhatsApp → CRM, or around a workflow pattern, like lead intake with deduplication and handoff?
My guess is the first is easier for a client to approve, but the second may show business value more clearly. Curious how you think about it.
Just to clarify, I’m offering this as a service / freelance work, not hiring someone.
For a paid test build, I usually prefer to start with a small business workflow rather than only one isolated integration.
A single integration like WhatsApp → CRM is easier to approve, but I think it becomes more valuable when it is connected to a real use case: lead intake, basic validation, deduplication, status update, and a clear handoff to a human if needed.
So my ideal test build is small, but complete enough to prove value. Something that can be delivered quickly, tested with real examples, and then expanded if it works well.
That way the client is not paying for a huge project upfront, but they still see a practical result, not just a technical connection.
That makes sense — “small but complete” is a strong framing.
The lead intake → validation → deduplication → status update → human handoff chain is a good test because it proves more than a technical connection. It shows whether the workflow can survive a real business process.
The human handoff piece is especially easy to underestimate. A lot of automations don’t fail because the workflow breaks; they fail because the person receiving the handoff doesn’t know what to do next, gets the wrong notification format, or has no fallback path if they miss it.
Curious how you usually handle that layer in a test build: do you include simple escalation logic from the start, or keep the first version lean and add escalation once the client sees it working?