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.
