Hiring: Senior Make.com Automation Engineers (Ongoing Contractor Work, $75–$95/hr)

This looks like a good white-label or overflow partner fit, especially where the work needs more than app-to-app Make scenarios.

TinyOps Studio is strongest on the messy implementation layer: CRM and lead routing, webhook/API integrations, Sheets/Airtable data contracts, error handling, retries, idempotency notes, run logs, and client-safe handoff docs. I would start with one representative client workflow so the acceptance criteria, communication rhythm, and handoff style are clear before either side commits to ongoing volume.

A practical first step would be a paid 6-10 hour pilot or fixed milestone around one sanitized client workflow. Send one sample payload or current scenario outline, the target CRM/marketing stack, and the success criteria, and I can map the first milestone and timeline.

Hi Josh,

This is a strong fit. I build AI-assisted automation systems around APIs, webhooks, CRM/marketing ops, lead routing, and operational handoff docs. The part of your post that stood out is owning solutions, not just executing tickets - that is exactly how I prefer to work.

For a first paid slice, I would be comfortable owning one CRM / lead-attribution workflow end to end:

  • map trigger, input, output, and failure states
  • build the Make scenario with API/webhook boundaries
  • add retries, logging, and does-not-silently-fail checks
  • document the handoff so your team or client can maintain it

I have also sketched a Make-first state-machine blueprint for exactly this style of work: webhook/event intake → durable status → idempotency key → retry/recovery note → operator-visible handoff. I can adapt that into a client-specific v1 instead of starting from a blank scenario.

Public proof:

I am available async-first and can start with a bounded 24-72 hour paid test before discussing ongoing bench work.

Best,
Joseph

Hi Josh,

Following up about the senior automation engineer bench. I focus on building robust production automation systems, not just one-off scenarios. This includes CRM pipelines with lead routing and enrichment, as well as API and webhook integrations across SaaS tools.

I pay close attention to the less visible aspects like error handling, retry logic, and alerting, which are key to making sure a system handles real-world volume reliably.

I’m comfortable working in Make.com, and can move to TypeScript, Supabase, or Airtable if a scenario needs more than the visual builder can offer. I work async and can join an ongoing queue as needed.

Would you like more details on my approach or availability?

Senior automation builder, US based, async friendly. Things I run in production right now: an AI receptionist that answers real calls and texts 24/7 and books appointments (call it, 760 437 6082), a lead pipeline that enriches, scores, validates deliverability, and routes outreach with bounce suppression, and a 5 agent e-commerce system that takes a product from market research to a live Etsy listing through QA gates. Built on APIs, webhooks, and custom Python where visual modules run out, documented and handed over clean.

Happy to start with a paid test project at your posted range. Portfolio and contact at blazalgosystems.netlify.app.

Blaz

Hi Josh,

Your post stood out because you described the agency problem clearly: client workflows around CRM, marketing ops, lead attribution, APIs, webhooks, and documentation need someone who can own the outcome, not just build a few Make modules.

The most useful way for me to test fit would be one sanitized client workflow where a lead comes in, gets validated, routes to the right place, notifies the owner, and leaves enough notes that your team can maintain it.

That is the narrow service I am packaging as Lead Handoff Rescue. It is one fixed workflow slice first, not a pitch to replace your senior bench.

Worth sending over the one page pilot scope?

Michael

Hi Josh — I sent a concise application to [email protected] regarding the senior Make.com contractor bench. My focus is CRM architecture, routing, APIs, reliability, QA, and documentation. Thanks.

Curtis — the Eventective and DJEP questions above are the right
ones. Two things nobody’s raised yet that will decide whether this
works or embarrasses you in front of a bride.

Texting is not a Twilio switch

You described SMS as the primary channel. In the US, sending
business texts to consumers requires A2P 10DLC registration — brand
registration plus campaign registration with the carriers. It takes
days to a few weeks, costs a small monthly fee, and unregistered
traffic gets filtered silently. Not blocked with an error.
Filtered, so you think it sent and the lead never saw it.

Your campaign use case here is conversational, and carriers scrutinise
AI-driven messaging. Worth starting registration now in parallel with
the build rather than discovering it at launch.

Practical route: build email-first, add SMS as a second channel once
registration clears. Same agent, same memory, different transport.

The pricing logic is the actual risk

Everyone’s treating “provides the appropriate pricing” as one bullet.
It’s the part that costs you money if it goes wrong.

Wedding DJ pricing usually has conditional structure — ceremony plus
reception versus reception only, hours, travel beyond a radius,
uplighting, a second setup for a different location, peak Saturday
versus a Tuesday in February. An LLM asked to “work out the price”
will interpolate confidently and quote something you never agreed to.

The fix is to not let it. Pricing sits in a lookup table or a
deterministic function. The AI collects the variables — venue,
distance, hours, ceremony yes or no — passes them to the calculation,
and reads back the result. It never calculates.

Same for availability. If the agent implies a date is free without
checking DJEP, you find out when two couples believe they’ve booked
the same Saturday.

Two more worth building in from the start

A hard handoff on booking intent. The moment a lead says anything
resembling “how do I pay” or “send me a contract”, the agent stops and
notifies you. Deposits and contracts are not places for an agent to
improvise.

A conversation cap. If a thread goes past six or seven exchanges
without reaching Calendly, hand it to a human. Long AI conversations
degrade, and the leads that ask the most questions are usually the
ones worth talking to yourself.

On the build itself — the memory piece you described is
straightforward, a state store keyed to the lead with full
conversation history, so a reply three weeks later continues rather
than restarts. We’ve built exactly that pattern, including the part
that matters here: routing anything the system is uncertain about to
a human rather than guessing.

I’d scope this as email-first with pricing as a deterministic lookup,
then layer SMS once 10DLC clears. Happy to write that up as a fixed
scope so you can compare it against the others properly.

Conner James
Parix.ai

Hi @Chek_Creative Josh,

This is close to the work I already do: production Make and n8n systems, APIs, webhooks, Supabase, Airtable, AI steps, and the error paths that keep an operator from babysitting the automation.

One production workflow I built has run for 14 months inside a live business. It handles intake, AI classification, CRM writes, and human review when confidence is low. I also build the operating layer around the workflow: logs, alerts, handoff notes, and a runbook another person can use.

I am US-based, comfortable speaking directly with clients, and my current rate is $94.45/hr.

Which part of the current pipeline needs the bench first: CRM and attribution work, API-heavy integrations, or fault-tolerant internal systems?

Hi Josh, I like the way you framed this as a partner bench rather than a one-off ticket queue.

I’m strongest for contained delivery slices behind an agency team: map one client workflow, repair form or CRM routing, add duplicate protection and owner alerts, and leave a concise handoff runbook. I don’t want to overstate senior production history, so I’d suggest a small paid test rather than a broad capability claim.

A $250 to $400 pilot with one client workflow, a defined acceptance test, and async handoff notes could show whether the working relationship fits. If you have a current project where the boundary is clear, share the trigger, destination, and what is failing.

Hi Josh,

This lines up almost exactly with how I work. I build Make automations with a strong focus on reliability — proper error handling, retries, logging and idempotency so nothing breaks silently — and I’m comfortable across the rest of your stack too: Airtable, Supabase, CMSs (WordPress, Webflow, Shopify) and data modeling / database design.

I’m a certified Make Partner (Levels 1–4) and HubSpot certified, and the messy, real-world systems problems you described are exactly the kind of work I enjoy. The long-term partner-bench setup and async-first style suit me well.

I’d love to connect. You can reach me at [email protected], or I’m happy to hop on a quick call whenever suits you.

Best,
Mile Marković
Automation & CRM specialist — Make Partner, HubSpot certified
[email protected]

Hi Josh,

I realise this is an older thread, but the recent activity suggests you may still be expanding the contractor bench.

My strongest fit is production ecommerce and operational systems rather than paid-media attribution.

I currently build and maintain workflows connecting Make, Shopify, Airtable and Google Workspace. My work includes Shopify GraphQL and webhook integrations, order and payment tracking, inventory workflows, relational Airtable structures, validation, status management, error visibility, documentation and team handover.

One example involved building the operational layer for a South African produce distributor: structured order capture, automated Shopify order creation, central Airtable tracking and payment-status synchronisation through Make.

I’m comfortable owning a contained workflow end-to-end and working asynchronously with clearly defined acceptance criteria. I would be open to starting with one paid trial workflow at the lower end of your stated range—USD 75/hour—or agreeing on a fixed milestone after reviewing the scope.

Portfolio:
https://nhlanhla-systems.lebonemak.chatgpt.site

To be transparent, I would be a stronger fit for Shopify, Airtable, Make, GraphQL and operational workflow projects than for work requiring deep Supabase or TypeScript development.

If the bench is still open and that specialist coverage would be useful, I’d be happy to discuss one representative workflow.

Nhlanhla

Hi Josh,

I came across your post about building Chek Creative’s long-term automation engineering bench and wanted to reach out directly.

My primary orchestration platform today is n8n, although I also work with Make.com and I’m comfortable adapting to the platform your client environment requires.

The broader engineering work you described is very close to what I build: end-to-end automation systems, REST APIs and webhooks, Supabase/PostgreSQL, lead qualification and routing, AI workflows, database-backed business logic, and multi-system integrations.

I’ve also built a modular AI Sales OS combining lead qualification, customer workflows, knowledge retrieval, appointment automation, persistent data, and external integrations.

I don’t want to position myself as a long-time senior Make specialist if that’s the hard requirement. But if you’re looking for an automation engineer who can own the underlying system architecture and quickly work within your Make stack, I’d be very interested in joining your contractor bench.

I can send you my portfolio, GitHub, architecture examples, and relevant workflow screenshots privately if useful.

Best,
Vladislav

Hi Josh — I’m Dmitry. I do white-label / overflow delivery for agencies: you keep the client, I build Make (and n8n) workflows async, no calls. CRM, lead routing, APIs, documented handoff. I’m used to a client bench, not one-off gigs. Based in Arkhangelsk, Russia (MSK). If you still need senior contractor capacity, I can take a scoped first workflow. LinkedIn: https://www.linkedin.com/in/dmitry-overflow

Hi,

I’m Faraz, a full stack JavaScript developer (Next.js, TypeScript, Node, Postgres, Supabase). I saw your post about the automation bench.

Straight up: my depth is not Make itself, it’s the layer around it. Custom TypeScript middleware, Supabase/Postgres data modeling, webhook systems with retries, logging and idempotency, API integrations that don’t silently drop records. I build and run my own SaaS, Parhako, solo for 3 years, and that’s the same skill set your post lists as the big bonus: the builds where scenarios end and real code needs to start. Portfolio: portfolio.parhako.com.

On Upwork: 5 stars on every contract, $12k+ earned, one contract ran 942 hours. Fully remote, async-first, which matches how you work.

The $75–95/hr band works for me. If the bench needs someone for the complex builds, tell me the next step.

Faraz Shah faraz-35 (Faraz Shah) · GitHub

Hi Josh — I found the Chek Creative post about building a senior Make.com partner bench for client delivery. Because the original post is from March, I wanted to first check whether you are still adding delivery partners.

Your focus on CRM operations, lead routing and reliable handover is relevant to the type of work I am looking to take on. If the need is active, I can send my technical background and availability against a specific brief. I saw the published USD 75–95/hour range.

Would you be open to sharing one representative client workflow or a first pilot brief, and whether the delivery is white-label, client-facing, or both?

Hi Josh — the agency bench model is a good fit for the engineering side I can credibly support: Node.js/TypeScript/Python, APIs and webhooks, SQL/data modeling, testing, idempotency, retries, logging, and client-safe handoff notes. I use Make as an orchestration layer, but I won’t claim years of Make-only client delivery I can’t verify. A sensible way to evaluate fit is one paid, bounded client workflow: sanitized trigger/payload, destination, and acceptance criteria. I can map the failure states, implement and test the integration, and leave a short runbook your team can hand to the client. I’m comfortable starting at the low end of your posted range ($75/hr) for that trial. If that works, send one representative CRM/lead-routing/API workflow and I’ll scope the first slice. Portfolio: https://fored.id/ — Yehor Rodionov

Hi Josh,

I’m interested in joining your automation partner bench.

My background sits at the intersection of operations systems and automation rather than isolated one-step scenarios. I work primarily with Make, Airtable, Shopify, ClickUp and connected business tools, taking messy operational processes and turning them into structured, maintainable systems.

A recent example is an ecommerce/distribution operation where I’ve built Airtable as the operational layer, Make as the automation layer and Shopify alongside it, covering order workflows, payments, inventory/operational status, linked data and exception handling.

The part of your post that particularly caught my attention was ownership. I’m comfortable inheriting existing processes, understanding why they’re failing, improving the underlying structure, documenting what has been built and working with nontechnical stakeholders.

I also want to be transparent about fit: my strongest production experience is Make/Airtable/Shopify and operational system design. I’m not positioning myself as a TypeScript/Supabase engineer, so if deep custom-code development is a requirement for every engagement I may not be the right fit. If you’re building a bench where different engineers can own work aligned with their strengths, though, I think there is strong overlap.

I’m based in Johannesburg (UTC+2), work remotely and am comfortable with async collaboration.

I’d be happy to start with one representative workflow or paid pilot so you can evaluate the way I approach, build and document systems before committing to anything ongoing.

Portfolio/case studies:

Hi Josh — Axioprax can sit on your Make partner bench for the CRM/lead-routing/API slices you described. Strongest fit: end-to-end Make scenarios with idempotency, retries, logging, and client-safe handoff notes (async-first). Sample first engagement: one client CRM or lead-attribution path mapped + hardened + documented. Rate band $75–95/hr works for senior delivery. Prefer forum DM (or hello@ if you still use that). — JH, Axioprax

Hi Josh — you invited PMs, but I’m new enough here that the forum won’t let me send one yet, so I’ll keep this public and brief.

Leading with the disqualifier: I am not an advanced Make.com builder. You list that as required and I’d rather say it now than find out on your client’s project. My depth is the layer underneath — APIs, webhooks, and specifically the “big plus” in your post: fault-tolerant automation with error handling, retries, logging, idempotency and drift handling.

Three things I’ve actually built, rather than claims:

  • A pipeline where a duplicate inbound event is physically unable to cause a second downstream effect — unique constraint plus a conditional write, not an “if exists” check, because two concurrent runs both pass an exists-check.
  • Work persisted durably before the expensive step, so resource pressure defers it for automatic retry instead of dropping it. That came from a real incident where items were being silently lost and the user was being told to resend.
  • A concurrency cap counted from the process table rather than from job status, because a crashed worker leaves a stale “running” row and deadlocks the queue forever.

That’s the messy-systems part, and it’s why automations rot in production: the happy path is easy, and client trust dies on the failure paths.

Instead of a rate conversation — give me one existing scenario that has failed before: the one that quietly double-sent, or stalled and needed manual re-entry. $1,500 fixed, and it only passes if, demonstrated live:

  1. a duplicate trigger produces exactly one downstream effect
  2. a forced mid-run failure recovers with no manual re-entry and no double-send
  3. every failure path emits a structured log line identifying the affected record
  4. a deliberately malformed payload lands in an error branch rather than passing silently

If it doesn’t clear all four, you don’t pay. You’d be evaluating me on real client work, and the Make-specific gap either surfaces immediately or turns out not to matter for that job.

Two things to know: I operate as a business rather than as an individual contractor, and delivery is AI-assisted — I build and run the systems rather than hand-building every scenario. I mention it because it’s exactly why I lead with idempotency: automated work is fast and confident, and that confidence is the failure mode. The tests are the product.

If Make-advanced is genuinely hard-required, no hard feelings. If reliability is the part that’s been hurting delivery, that’s where I’d earn a place on the bench.

Hi Josh, this maps closely to what I build.

Most relevant example: a lead pipeline where a webhook intake enriches through Apollo, an LLM classifies hot vs warm with structured output parsing and fallback logic, HubSpot is checked for records created in the previous 24 hours to prevent duplicates, then the contact and deal are created and Slack is notified. Failures route to Slack and Jira rather than dying silently. That is lead routing, enrichment and attribution with the reliability layer you described.

Second example, closer to document ops: one form submission parses an address, branches new versus returning client, creates the Drive folder, generates five PDFs and files them. Removed 15 to 20 minutes of manual work per submission.

Background is 7 years software engineering (Node, TypeScript, React, MongoDB) before I specialised in automation, so custom middleware when Make gets brittle is not a problem. Make Advanced certified. Comfortable in your rate band.

Suggested first step: one scoped paid workflow with clear acceptance criteria, so you can judge the work before adding me to the bench.

Aneeq Iftikhar