Hi! I’m building a mobile-first SMS experience for family caregivers, and am looking to connect with freelancers before a mid-May build start.
The stack: Bubble (front-end), Supabase (database + auth), Make (automation), Twilio (SMS), and Claude API (AI-generated content with human review via Slack).
We’re building stateful SMS conversation flows, a campaign batch generator where Claude selects and personalizes activities per user, a human-in-the-loop Slack approval workflow, and a longitudinal analytics layer in Supabase for research reporting.
This is a short-term contractor engagement (not an agency, not a long-term hire). Roughly 20h/week across 3-4 weeks starting mid-May. Would love to connect now while we’re in a pre-build approval window.
If you’ve built complex Make scenarios with Twilio and Supabase, or done stateful conversation logic in Make, I’d especially love to hear from you!
Hey @Claire_Manwaring , this is exactly the kind of workflow build I handle. I’ve built Make automations around Twilio, Supabase, Slack approvals, and AI-driven routing/content generation, including stateful conversation logic and audit-ready data capture. For your setup, I’d structure the SMS flows with clear state management in Supabase, use Make for orchestration and retry-safe processing, and layer Claude generation with a Slack review step before anything is sent. I’d also design the analytics schema upfront so campaign activity, user interactions, approvals, and outcomes are all reportable longitudinally without rework later. Bubble can stay focused on the front-end while Make handles the operational logic cleanly. If you want, send over the current architecture or scope doc and I can quickly confirm the best implementation approach before your mid-May start. Feel free to book a meeting with me here to discuss this further.
This is very aligned with the type of workflow systems I build using Make, APIs, AI tools, and communication platforms like Twilio and Slack.
The stateful SMS flow part is especially important because the user journey, approvals, retries, and conversation state all need to stay organized as interactions happen over time.
I also like that you’re already thinking about analytics + human review early in the architecture instead of adding it later.
Quick question:
are you planning to manage the conversation/session state fully inside Supabase?
Hello @Claire_Manwaring , 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 sounds like a very clean and well-thought-out stack. I’m a developer specializing in Make.com and complex automation, and I’ve worked extensively with exactly the tools you’ve listed.
Why I’m a good fit for this 4-week sprint:
Make + Supabase: I’m very comfortable using Supabase as a primary database for stateful logic (handling triggers, upserts, and longitudinal data).
Stateful SMS Flows: I’ve built conversation engines where Make manages the context and “state” of the user to ensure the SMS flow doesn’t break.
Human-in-the-loop: I’ve implemented similar Slack approval workflows where AI content (Claude/GPT) is staged for review before being sent to the final user.
I’m a freelancer, not an agency, so I can dedicate the 20h/week you need for this period. Since you’re looking to start in mid-May, I’m available to chat now while you’re in the pre-build phase.
Your project immediately stood out especially the combination of stateful SMS flows, personalization, and human in the loop approval. That’s a powerful and thoughtful approach for supporting family caregivers.
I’ve worked with similar stacks (Make, Supabase, Twilio, and AI APIs) to build automation-heavy systems that require both reliability and flexibility. What you’re building particularly the stateful SMS logic and campaign personalization layer is exactly the kind of challenge I enjoy solving.
Here’s how I can support you effectively:
- Build and optimize complex Make scenarios for Twilio-based SMS flows
- Design clean, scalable Supabase structures for stateful conversations and analytics
- Integrate Claude API for personalized content generation with structured outputs
- Set up Slack approval workflows for human-in-the-loop review
- Ensure everything is reliable, testable, and easy to iterate on during your short build window
I understand this is a fast moving, short-term engagement, so I focus on delivering production ready work quickly without cutting corners. Clear communication, quick iterations, and stability are my priorities.
I’m available to commit 20 hours/week and can align with your mid-May timeline.
If this sounds like a good fit, I’d love to jump on a quick call to walk through your architecture and help you map out the most efficient build approach before kickoff.
Looking forward to hearing more about your vision.
Your project is a strong fit because it sits at the exact intersection where AI workflows usually break down: messaging state, automation logic, human review, and clean backend data. I would not treat this as a simple Make.com build. I would treat it as a controlled SMS operations system where Bubble, Supabase, Make, Twilio, Claude, and Slack each have a clear job, and where the caregiver experience stays reliable even when replies, approvals, failed sends, or campaign changes create edge cases.
I would approach it this way:
I would start by defining the conversation state model in Supabase before building scenarios in Make, because SMS workflows become fragile when “where the user is in the flow” only lives inside automation steps.
I would map each Twilio event into Supabase: sent, delivered, failed, replied, stopped, opted out, and errored. That gives you real reporting data instead of just a message log.
I would review how Bubble is being used and keep it focused on admin-facing screens, campaign controls, review visibility, and reporting access rather than forcing Bubble to own automation logic it should not own.
I would structure the Make scenarios around clear handoffs: trigger, fetch caregiver context, generate or select content, send to Slack for approval, update Supabase, then queue or send through Twilio.
I would set up Claude with controlled inputs instead of open-ended prompting: caregiver profile, activity library, campaign rules, message history, tone constraints, exclusions, and approval status.
I would make the Slack approval workflow practical for real reviewers. Approve, reject, edit, regenerate, and hold should all write back to Supabase so the batch does not lose its audit trail.
I would define the campaign batch generator so Claude’s choices can be reviewed later: which activity was selected, why it matched the caregiver, what personalization was added, and what final message was approved.
I would separate pilot users, test users, and live users early. Twilio SMS testing gets messy fast if live caregivers are mixed into QA runs.
I would put guardrails around message timing, duplicate sends, retry logic, and opt-out behavior, because those are the areas that create real operational risk in SMS systems.
I would design the longitudinal analytics layer around events, not snapshots. Research reporting needs a clean history of message activity, approvals, caregiver engagement, and outcomes over time.
I would document the Make scenarios while building them, including scenario purpose, trigger source, Supabase tables touched, Twilio actions, Slack approval path, and failure handling.
I would keep the first build narrow enough to launch in the 3 to 4 week window, but structured enough that it does not turn into a pile of disconnected automations after the pilot.
A few relevant projects from my background:
Cococure AI WhatsApp Chatbot I helped build an AI-powered WhatsApp automation system for a hospitality and events brand that needed high-volume conversational messaging tied to live business rules. I handled the architecture and delivery around WhatsApp automation, OpenAI/LangChain orchestration, backend flow logic, response control, and state-aware conversation handling. That is directly relevant here because your SMS experience also depends on the system knowing user context, generating useful content, and keeping messaging behavior controlled across many users.
DocuMind.ai
I built an AI document intelligence platform using OpenAI, Supabase, vector search, and structured retrieval workflows. My work involved the AI pipeline structure, data storage approach, retrieval logic, and making model output useful inside a real product workflow. That ties directly into your Claude campaign generator because the important part is not just calling the API. The important part is giving the model clean inputs, storing outputs properly, and making every generated result traceable.
Datability AI Goal-Setting Assistant (databilityweb.com)
I integrated an AI assistant into an existing education platform where the system evaluated, refined, and generated structured goals through a user-facing workflow**. I handled the backend API structure, prompt logic, real-time interaction patterns, and output quality controls.** That is relevant because your Claude layer needs to produce personalized caregiver content that can be reviewed, approved, and improved without becoming unpredictable.
I can step in as a hands-on short-term contractor and help get the workflow architecture, Make scenarios, Supabase structure, Twilio messaging logic, Claude generation flow, and Slack approval process into a clean working build.
A few questions I would want to confirm on a call:
Is the Supabase schema already designed, or do you need help structuring it before the Make scenarios are built?
Are the SMS conversation flows already mapped as states, or are they still in narrative/user-story form?
Will Slack approval happen per individual message, per campaign batch, or only for messages Claude flags as uncertain?
Does Claude choose only from a fixed activity library, or can it generate new activity ideas?
For research reporting, do you need raw event history only, or dashboards/views for caregiver engagement, campaign performance, and longitudinal outcomes?
Hi Claire, I’d treat the stateful SMS layer as the core architecture question here, not just a Make scenario.
The cleanest version is probably:
Supabase owns user/session/campaign state
Make orchestrates events and approvals
Twilio events get logged back into Supabase
Claude outputs go through Slack review before sending
every send/reply/approval/failure becomes an event for research reporting
Relevant background: I build Laravel/API workflow systems around intake, SMS/email notifications, private links, timelines, human review, and Make bridges. I’m not primarily a Bubble developer, but I’ve been developing software for years and it’s easy for me to steer any AI app builder. Also, I’m comfortable working around APIs, backend state, Twilio-style messaging flows (I have a ton of experience there), and automation reliability.
A few questions:
Is the Supabase schema already designed?
Should conversation state live fully in Supabase?
Are Twilio delivery/reply/failed/opt-out events part of the reporting layer? If the app is for US market you’ll need to have Twillio number(s) approved for SMS sending. I have two 1-888 numbers approved for my own apps so I can help with going through the approval process.
Is Slack approval per message, per batch, or only for uncertain outputs?
If you’re still looking, I’d be happy to review the architecture and see if my background fits the build.
Hi Claire. This is a strong fit for a short, controlled build because the hard part is state and auditability, not just connecting modules.
I would make Supabase the source of truth for caregiver/session/campaign state, then let Make orchestrate Twilio events, Claude generation, Slack approval, retries, and reporting updates. That keeps Bubble focused on the admin/user interface and avoids fragile state living only inside scenarios.
For a first paid slice I would start with one conversation path: incoming/reply event → Supabase state update → Claude message/activity selection → Slack approve/reject → Twilio send → event log for reporting. Once that loop is reliable, the campaign batch generator and longitudinal analytics become much safer to expand.
I work well async with written specs and handoff notes. If this is still open, the first useful thing to share would be the current Supabase schema or the state diagram you expect for one caregiver flow.
This stack is exactly what I work with daily — Make + Supabase + Claude API + Twilio is a combination I’ve built production systems on.
What I’d deliver for your project:
-> Stateful SMS conversation flows: conversation state stored in Supabase, Make handles Twilio webhooks + routing logic
-> Campaign batch generator: Make scenario triggers Claude API with user context, generates personalized activity suggestions, writes candidates to Supabase for Slack review
-> Human-in-the-loop Slack approval: approval/rejection updates Supabase state, approved content triggers Twilio send — no message goes out unreviewed
-> Longitudinal analytics schema: every SMS event (send/reply/approval/failure) captured as immutable rows in Supabase — research-ready from day one
-> Bubble integration: Supabase as shared data layer, Bubble reads/writes via API, Make handles all async logic
In production (running 4+ months, zero manual interventions): inbound lead pipeline — webhook → Claude qualification → DB write → team notification. Same architecture as what you’re building.
Stack match: Make · Claude/Anthropic API · Supabase · Twilio · Bubble · Slack API
Available immediately. 20h/week fits my schedule. EU timezone, async-first, detailed execution logs for every run.
Happy to review your current scenario structure or schema draft before committing.
Hi @Claire_Manwaring
I’ve experience delivering Make automations around Twilio, Slack and AI Routing tools, including conversation logic.
We can quickly schedule a call to discuss best approach
Hi Claire, this is a clear short-term build scope and I can help with the Make-side architecture and implementation.
For this stack I would design it around Supabase as the source of truth for state, not Make memory. The key pieces I would map first are:
SMS conversation state per caregiver/user in Supabase
Twilio inbound/outbound webhooks into Make
Claude generation with structured outputs, not free-form text
Slack human review before send
retry/error handling for failed sends or rejected approvals
analytics events written back to Supabase for longitudinal reporting
The part I would pay most attention to is state management: every SMS turn should have a session/user state, campaign context, approval status, and event log so the experience is reliable and reportable later.
I can start with a paid architecture slice: review the current scope, produce the Make scenario map, payload schema, Supabase tables/events, and Twilio/Slack handoff plan. If that fits, I can continue into implementation.
Hi Claire — I know the mid-May window has likely passed, so this is more of a “keep me in mind” note in case the build is still open or you have follow-on work.
This stack is squarely what I build: Make scenarios orchestrating Twilio, Supabase as the conversation-state + event store (sent/delivered/failed/replied/opted-out), Claude with controlled inputs (caregiver profile, activity library, campaign rules, history, exclusions) rather than open-ended prompting, and a Slack approve/reject/edit/regenerate loop that writes every decision back for a clean audit trail.
My approach: define the Supabase state model first, keep Bubble to admin/reporting/campaign-control screens, separate pilot/test/live users early to keep Twilio QA clean, and put guardrails around timing, duplicate sends, retries and opt-outs. I document each scenario as I build, so it stays maintainable after launch.
If the project is still live or you’re planning a phase 2, happy to share examples and confirm scope on a short call.
