I have created a Make.com automation that runs daily to deliver customized industry research by email for multiple clients. The research is done by Google Gemini deep research. The automation also leverages Google Docs and Make database for persistence across automation runs (the research is aware of past findings). This is currently running, we would like to expand the functionality of this automation and make it more self-serve to easily set up to deliver to new clients that want to use this tool.
Meetings and communications for this job will be in PDT time zone.
We estimate that expanding this tool with take ~40 hours. Please name your rate.
Hello @Eli_Malone-Shkurkin , I can take this on. I’ve built and extended Make workflows that combine LLM research, document generation, persistence, and multi-client onboarding, so the next step here is to turn your current scenario into a cleaner client-ready system with reusable modules, structured inputs, and an easy setup flow for new accounts. I’d review the existing Make architecture, data model, Gemini prompt/research logic, and Google Docs outputs, then tighten reliability, client separation, and state handling across runs. If needed, I can also add an intake form/admin layer so onboarding a new client becomes mostly configuration rather than manual scenario edits. I work comfortably across Make, APIs, webhooks, Google Workspace, and AI workflow design, and I can collaborate in PDT. If you want, send over a brief overview or access to the current scenario and I can outline the fastest path to expansion. Feel free to book a meeting with me here to discuss this further.
Hello @Eli_Malone-Shkurkin , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications
This is a solid system already. What you’re moving into now is more about making it scalable and self-serve rather than just extending the current automation.
I’ve worked on similar Make setups where we turn single workflows into reusable multi-client systems with proper config and onboarding.
To give you a clear timeline and quote, I’d need a bit of clarity:
• how are you handling client-specific inputs (prompts, industries)?
• how are new clients currently added?
• should each client’s data stay fully isolated or partially shared?
Once I have this, I can map a clean structure and estimate properly
Eli — the bottleneck for “self-serve onboard a new client” on a Gemini Deep Research stack usually isn’t the AI or the Make scenarios. It’s prompt templating: each new client industry (B2B SaaS vs consumer goods vs healthcare) needs different system instructions, output schemas, and seed examples. Without a per-client config layer, every new client becomes a 2-hour engineering task for you — which is why the system feels “almost self-serve” but never quite gets there.
The fix is a 3-layer pattern: (a) per-client config row in Make DB with system prompt + persona + output schema as fields, (b) one onboarding scenario that reads the row and spins up the per-client research workflow, (c) a backfill scenario that primes persistence with 7-10 days of research-output for the new client before going live — so day-one briefs already feel “aware of past findings” the way you described, not cold-start blank.
I’ve shipped multi-tenant + persistence patterns like this in two production systems: a multi-tenant text-to-SQL platform with industry-specific schemas, and a 9-agent Claude system running across Make + Supabase + Slack for a D2C client.
Reply and I’ll DM a 12-minute Loom walking through how I’d layer this on top of your existing setup, plus a sample Make DB config schema. PDT meetings are easy from IST.
I love this project because you’ve already tackled the hardest part—getting the AI to actually “think” and remember past research. Now, we just need to stop you from doing manual work so the system can scale to 100 clients as easily as it does for one.
Here’s exactly how I’ll help you scale this:
One “Brain” for all clients: I’ll restructure your Make database so it acts as a central hub. Instead of duplicating scenarios, we’ll have one master workflow that dynamically pulls the specific keywords, history, and schedules for each client based on their ID.
Self-serve onboarding: I’ll build a bridge so new clients can sign up via a simple form. Once they hit submit, the system will automatically create their Google Doc, set up their database entry, and trigger their first research run without you lifting a finger.
Smart memory management: Scaling “persistence” can get messy and expensive. I’ll optimize how past findings are retrieved so Gemini stays focused on what’s relevant, keeping the research sharp and the token costs low.
PDT availability: I’m completely comfortable with your time zone. I’ve worked with many US-based teams and can be online for our meetings and sync-ups during your business day.
Why me?
I’m Mikhail, a developer and automation specialist. I’ve built “Content Factories” and research pipelines that handle massive data flows for fintech and real estate. I don’t just “link nodes”—I build production-grade systems that include heavy error-handling and scalability as standard.
The Details:
Rate:$50/hour.
Availability: I have 25–35 hours a week free and can start immediately to hit your 40-hour roadmap.
Hi Eli, this sounds less like a one-off automation now and more like turning a working internal workflow into a repeatable multi-client system.
I’d focus the 40 hours around making onboarding/configuration cleaner, not rebuilding what already works:
inventory the current scenario and Make database structure
define the client config model: industry, prompts, output format, schedule, delivery recipients, history rules
separate client-specific settings from shared workflow logic
add a simple onboarding/config flow for new clients
make Google Docs creation and persistence repeatable
add error logging around failed research runs, missing docs, or bad outputs
document the setup so new clients don’t require manual scenario edits
My background is Laravel/API workflow systems plus Make bridges, so I’m especially interested in cases where Make handles orchestration but a lightweight backend/config layer makes the system easier to scale.
A few questions:
How are new clients currently added?
Is each client’s history fully isolated?
Are the Google Docs created from a template?
Does Gemini Deep Research run through Make directly, or through another API/process?
Do you want this to stay fully inside Make, or are you open to a small admin/config layer?
I would make the first paid slice the self-serve setup path, not a broad rebuild of the research workflow.
For this Make build, I would define the client intake fields, research brief template, Gemini request shape, persistence rules in Make database or Docs, delivery email format, retry/error states, and a simple admin handoff for adding a new client without editing the whole scenario.
TinyOps Studio can quote this as a fixed $499 build for one self-serve onboarding path: one client setup form or row in, daily research email configured and logged out. If the current workflow needs diagnosis first, the $149 audit would turn it into the exact scenario map and build quote.
Send one current client setup example, the desired email output, and where client config should live, and I can confirm the scope.
If this is still open, I can help turn the current Make + Gemini + Google Docs flow into a self-serve multi-client system.
I am Carlos Silveira, a Spain CET full-stack automation engineer. The relevant fit here is Make scenario architecture, Google Workspace integration, structured LLM outputs, persistence/state handling, client configuration, run/error logs, and plain-English handoff docs.
I would start by separating the system into clear layers: client config, research request generation, Gemini prompt logic, persistence across runs, Google Docs output, email delivery, and review/error logging. The goal would be to make onboarding a new client mostly configuration rather than manual scenario edits.
My rate is 60 EUR/hour. For a first step, I can do a 600 EUR fixed milestone covering architecture review plus one concrete onboarding improvement, then continue hourly if the fit is good. I can overlap with PDT for planned calls and work async for the build.
A good first milestone would be a 1-3 day audit of the existing scenario, data model, and onboarding path.
I would start by reviewing the current Make scenario, the Gemini research prompt flow, Google Docs output, and the persistence layer, then tighten:
- client separation and state handling across runs
- retries / error paths for failed research jobs
- reusable modules so a new client can be configured instead of manually rebuilt
- a simple intake/config layer for onboarding and handoff
For that first slice, my fixed quote would be USD 300-450 depending on what access you can share and how much of the refactor you want included in v1. I can work asynchronously and keep the handoff documentation concise.
If you want, send over a brief overview of the current scenario and I?ll come back with a scoped milestone plan.
For a first paid slice, I would quote USD 450 for the architecture audit and self-serve onboarding design.
Since you already have a working daily research automation, I would keep the first milestone narrow: review the existing Make scenario export, normalize the per-client config/state layer, and redesign new-client onboarding so it is configuration-driven instead of manual scenario editing. That gives you a concrete deliverable you can judge before the full 40-hour expansion.
I can work in PDT and deliver the first slice in 2-3 business days after access and the current scenario export. If the fit is good, I can then break the larger expansion into a clearer milestone plan.
Productizing a Make + Gemini research workflow is a great move — the tricky part is usually turning it into something repeatable for non-technical users. A few things that help: structure your Make scenario with modular sub-scenarios (search → summarize → format) so each piece can be swapped independently, and use Gemini’s structured output mode for consistent formatting downstream. A simple Airtable or Google Sheet as the input/output layer makes it feel like a real product rather than a script. Full disclosure: my company Nucleus AI builds done-for-you AI agent workflows for teams without in-house AI expertise, and we’ve found the packaging (input simplicity + clean output delivery) matters more than the LLM logic itself. Are you targeting this for internal use or as a client-facing offering?
