Make Pricing Tiers
Make's pricing is based on operations, every module execution in a scenario counts as one operation. Understanding the tiers prevents surprise bills as your automations scale. The Free plan gives you 1,000 operations/month across 2 active scenarios. This is enough for learning and testing but not for any real business workflow. Core ($9/month) gives you 10,000 operations/month, 3 active scenarios, and 15-minute minimum interval. This covers most early-stage SaaS automation needs, a new user onboarding sequence plus a weekly report.
The Pro plan ($16/month) unlocks 10,000 operations, unlimited active scenarios, and 1-minute minimum interval, critical for near-real-time webhook processing. Teams plan ($29/month) adds team collaboration and multiple users managing scenarios. Business plan ($59/month) covers 150,000 operations/month, appropriate for high-volume SaaS with hundreds of webhook events per day.
Practical operation budgeting: a 5-module onboarding sequence triggered by 100 new signups/month uses 500 operations. A weekly report scenario running 4 modules runs 16 operations/week. A Stripe webhook handler with 8 modules processing 200 events/month uses 1,600 operations. Most early SaaS companies stay within the Core plan for 6–12 months. Budget for the Pro plan when you add real-time webhook processing.
Building Error-Resilient Workflows
Unhandled errors in Make scenarios cause scenarios to stop and leave your data in an inconsistent state. Production-grade Make workflows require deliberate error handling at every external API call. Make's error handler routes allow you to define what happens when a module fails: Resume (skip the failed item and continue), Ignore (log the error and continue), Rollback (undo all completed modules in the execution), Break (stop execution and store the incomplete execution for manual retry), or Commit (mark execution as complete despite the error).
For webhook-triggered scenarios (Stripe, Supabase, inbound data), always wrap external API calls in error handlers set to Break. This stores the failed execution in Make's incomplete execution queue, where you can inspect the payload, fix the issue, and re-run it manually. Without Break handlers, failed executions disappear and you lose the triggering data permanently.
For scheduled scenarios (reports, batch operations), use Ignore or Resume with an error notification. If a weekly report fails to pull one data source, you likely want the rest of the report to run and receive an alert about the partial failure rather than receiving nothing. Always add a Slack notification or email alert on the error route, silent failures are the most dangerous failures in production automation.
Using Make with Webhooks and Supabase
Supabase's database webhooks allow you to trigger a Make scenario on INSERT, UPDATE, or DELETE events on any table. Configuration: in Supabase, go to Database → Webhooks, create a new webhook pointing to your Make scenario's webhook URL (generated in Make when you add a Custom Webhook trigger module). Select the table and event type (Insert for new user signup, Update for status changes). Supabase sends the changed row data as the webhook payload.
For a new user signup trigger: Supabase fires when a row is inserted into your profiles table (created by your auth trigger). Make receives the user's ID, email, and any metadata you store at signup. The scenario can then enrich the data (Clearbit lookup), create a CRM contact (HubSpot, Pipedrive), send a welcome email (SendGrid), and post to a Slack channel, all within 2–3 seconds of the user registering.
Important: Supabase webhooks have a 5-second timeout. If your Make scenario takes longer than 5 seconds to respond to the webhook, Supabase marks it as failed and may retry. For long-running workflows, Make should acknowledge the webhook immediately (respond with HTTP 200) and queue the remaining operations asynchronously. Achieve this in Make by splitting into two scenarios: a receiver scenario that responds instantly and sends data to a Make data store, and a processor scenario that reads from the data store and executes the heavy logic.
Workflow 1: New User Onboarding Sequence
Trigger: new row in Supabase users table. Actions: (1) Send welcome email via SendGrid, (2) Create contact in HubSpot, (3) Post to #new-users Slack channel, (4) Schedule Day 3 check-in email, (5) Add to Airtable new-user tracking base.
This workflow runs automatically for every signup, no manual intervention, no missed welcome emails.
Workflow 2: Stripe Subscription Events
Trigger: Stripe webhook (subscription.created, subscription.updated, subscription.deleted). Actions: (1) Update user plan in Supabase (role: free/starter/pro/enterprise), (2) Send plan confirmation email via SendGrid, (3) Update HubSpot deal stage, (4) Post to #revenue Slack channel for upgrades.
This ensures your app always knows the current subscription status, even if the user manages their subscription via the Stripe customer portal.
Workflow 3: Churn Risk Alert
Trigger: Supabase scheduled webhook, runs every Monday at 9am. Actions: Query users who signed in less than once in the last 14 days AND are paying. Send list to Slack #cs-team channel with user names, plan, and last login date.
This gives your customer success team a weekly list of at-risk accounts before they churn.
Workflow 4: B2B Lead Qualification
Trigger: new form submission (Typeform, Webflow form, or WeWeb form via webhook). Actions: (1) Enrich company data via Clearbit, (2) Score lead based on company size, industry, and job title, (3) Route high-score leads to Pipedrive with a task for the AE, (4) Route mid-score leads to a drip email sequence, (5) Route low-score leads to a self-serve email only.
Workflow 5: Invoice and Contract Generation
Trigger: new row in Supabase projects table (status = "confirmed"). Actions: (1) Generate PDF invoice via PDFMonkey from a Supabase project template, (2) Send to client via SendGrid with payment link, (3) Create project folder in Google Drive, (4) Post to #projects Slack channel.
Eliminate manual invoice creation entirely.
Workflow 6: Support Ticket Routing
Trigger: new Intercom conversation or support email. Actions: (1) Classify urgency using OpenAI (Critical / High / Normal / Low), (2) If Critical: page on-call via PagerDuty, (3) If High: assign to senior support and notify Slack, (4) Log all tickets in Airtable support tracker with category and resolution time.
Workflow 7: Weekly Revenue Report
Trigger: every Monday at 8am. Actions: (1) Query Stripe for last 7 days MRR, new subscriptions, cancellations, and expansion revenue, (2) Query Supabase for new signups, DAU, and feature usage, (3) Format as a structured report, (4) Post to #leadership Slack channel and email to founders.
Your KPIs land in your inbox every Monday without manual pulling.
Workflows 8–10: More High-Value Scenarios
Workflow 8, NPS Survey Automation: trigger 30 days after signup, send NPS survey via Delighted, route Detractors to customer success for immediate follow-up.
Workflow 9, Trial Conversion Sequence: trigger when trial expires. Day 0: upgrade prompt email. Day 3: case study email. Day 7: founder personal email. Day 14: cancellation confirmation with win-back offer.
Workflow 10, Data Backup: every night at 2am, export Supabase tables to encrypted CSV files in Google Drive. Simple but critical, SaaS companies that skip this eventually regret it.
Common SaaS Automation Patterns
Beyond the 10 specific workflows above, there are four architectural patterns that recur in almost every SaaS automation project. The event-driven pattern: every significant user action in your app fires a Supabase webhook, which triggers a Make scenario that handles downstream effects (CRM update, notification, analytics event). This is the backbone of modern SaaS operations, your app stays lean and each operational concern is isolated in a dedicated scenario.
The scheduled aggregation pattern: daily or weekly Make scenarios query your database, aggregate metrics, and distribute reports. This is simpler and cheaper than building reporting infrastructure in your app, and it keeps operational intelligence in tools your team already uses (Slack, email, Google Sheets).
The enrichment pattern: any time a new contact or company appears in your system (signup, lead form, support ticket), a Make scenario enriches it with third-party data (Clearbit, Hunter.io, LinkedIn) before it reaches your CRM. Sales teams who receive pre-enriched leads close 20–30% more deals because they spend time selling, not researching.
The escalation pattern: Make monitors for threshold breaches (payment failures, support response time, error rate spikes) and escalates to the appropriate team member with context. Building this in your app requires custom monitoring infrastructure. Building it in Make takes an afternoon and costs cents per execution.