Stress Testing Make no-Code as a SaaS Backend: Can It Handle 1000 Requests Per Minute??

When building a SaaS, automations, or a simple AI-powered tool, choosing the right backend can make or break your product’s reliability.
While many developers default to building custom APIs, non-coders have powerful no-code platforms like Make as an alternative.
However, a critical question remains:
Is Make actually reliable as a production backend when used by too many users?
To find out, I built a real-world marketing automation in Make and stress-tested it with increasingly aggressive loads: 50, 100, 200, 500, and finally 1000 calls per minute. The automation mimics a realistic SaaS use case, where it processes YouTube video content to generate personalized marketing emails using AI.

The results surprised me. Make didn’t just survive the stress test, it crushed it.
Why This Matters
Before moving on to the technical details, I would like to mention why this matters for your next project. When you’re building a SaaS or automation tool, you have three main backend options:
- Custom API Development: Full control, but takes a lot of time to develop
- Serverless Functions: Fast setup, but complex at scale
- No-Code Automation Platforms: Rapid deployment, but unknown reliability
For rapid MVP development, automation platforms like Make offer an unbeatable time-to-market advantage. But only if they can handle real user loads without breaking.
The Test Setup: Real-World Marketing Automation
The Make automation I built represents a simple SaaS backend operation:
- Webhook Trigger: Receives a GET request with video ID, product description, and target audience
- SearchAPI Integration: Fetches YouTube video transcript using SearchAPI.io
- OpenAI Processing: Analyzes the video’s marketing style and generates personalized email copy
- Response Delivery: Returns the generated email to the requesting application
This mirrors a real-world production workflow that uses external API calls, AI processing, and data transformation.
To test this workflow, I used a Python script that simulates realistic user behavior. Here’s the core structure:
import asyncio import httpx import time # Test configuration TOTAL_REQUESTS = [50, 100, 200, 500, 1000] DURATION_SECONDS = 60 WEBHOOK_URL = "your-make-webhook-url" PAYLOAD = { "video_id": "zgYQT-fdLL4", "product_description": "A guide that helps people build a personal brand...", "target_audience": "Developers, CS students, and beginners..." } async def send_request(client, payload): start = time.monotonic() response = await client.post(WEBHOOK_URL, json=payload, timeout=60.0) elapsed = time.monotonic() - start return response.status_code, elapsed
The script spreads requests evenly across 60 seconds, simulating real user traffic patterns.
Building the Make Automation: Step-by-Step
Let me walk you through creating this automation from scratch. This will show you exactly how to build robust, production-ready workflows in Make.
Step 1: Webhook Trigger Setup
Add the Webhook Module:
- Create a new scenario in Make
- Add “Webhooks > Custom webhook” as your trigger
- Copy the webhook URL—you’ll need this for testing

Step 2: SearchAPI Integration
Add HTTP Request Module:
- Add “HTTP > Make a request”
- Set method to GET
- Configure the URL:
https://www.searchapi.io/api/v1/search?api_key=YOUR_API_KEY&engine=youtube_transcripts&video_id=
{{7.video_id}}

Make sure that you pass the video_id as shown in the URL above, which we get from the webhook. I’ll show you below how we’ll send it exactly.
This module retrieves the complete video transcript, which serves as the foundation for analyzing the marketing style and tone.
Step 3: OpenAI Integration
Add OpenAI Module:
- Add “OpenAI > Create a Chat Completion”
- Select model: gpt-4o-mini (fast and cost-effective)
- Add this user prompt:
##Instruction You are an expert email marketer. Your task is to write a persuasive marketing email that will encourage my customers to purchase my product. Use the transcript of a YouTube video as inspiration for the tone, messaging, marketing strategy, and main ideas. The email should include: - A compelling subject line that grabs attention and increases open rate. - An email body that speaks directly to the target audience, uses their problems to offer a solution by highlighting the product’s benefits, and builds desire to buy. ##Input Product description: {{7.product_description}} Target audience: {{7.target_audience}} Video transcript: {{5.data}} ##Output Do not include any additional content, headings, or formatting beyond the email copy. It should be exactly in this format: Email Subject Line: Email Body:
The product description and target audience are obtained from the webhook, which we send using a GET request (I’ll show you how to do that). The data is passed from the previous HTTP module, which returns the video transcript.

Step 4: Response Handler
Add Webhook Response:
- Add “Webhooks > Webhook Response”
- Set status: 200
- Map the body to the result you get from the OpenAI module.
- This returns the generated email copy to your application.

Blueprint Download
Testing Process
Before running the stress test, I validated the automation with Postman to ensure everything worked correctly.
Postman Configuration:
- Method: GET
- URL: Your Make webhook URL
- The parameters

Expected Response: A comprehensive marketing email with a subject line and body copy tailored to the video’s style. Something like this:

Stress Test Execution
With validation complete, I ran five increasingly aggressive stress tests:
- 50 requests in 60 seconds (baseline test)
- 100 requests in 60 seconds (moderate load)
- 200 requests in 60 seconds (heavy load)
- 500 requests in 60 seconds (extreme load)
- 1000 requests in 60 seconds (maximum stress)
Each test used the Python script to distribute requests evenly across the 60-second window, simulating realistic user traffic rather than artificial bursts.
The Results Make Delivered
Here’s what happened when I pushed Make to its limits:
Load Level | Success Rate | Avg Response | Fastest | Slowest |
---|---|---|---|---|
50 requests/min | 100.00% | 9.62s | 6.53s | 14.16s |
100 requests/min | 100.00% | 11.58s | 7.69s | 26.80s |
200 requests/min | 100.00% | 14.86s | 6.62s | 28.19s |
500 requests/min | 100.00% | 20.89s | 6.04s | 34.28s |
1000 requests/min | 100.00% | 24.45s | 5.69s | 45.94s |
These performance metrics show that Make has:
- Perfect Reliability: Make achieved 100% success rates across all test levels. Zero timeouts, zero errors, zero failures. This indicates Make can handle production loads without breaking.
- Predictable Scaling: Response times increased gradually with load, showing Make’s infrastructure scales gracefully rather than hitting hard limits.
- Consistent Fast Responses: Even under maximum stress, the fastest responses remained around 6 seconds, showing that Make maintains its baseline performance.
- Reasonable Maximum Times: The slowest responses (45.94 s at peak load) remained well within typical timeout limits.
What This Means for Your SaaS
These results prove Make can serve as a reliable backend for production applications. Here’s the business impact:
- For MVP Development: You can build and deploy automation-powered tools in days, not weeks, while maintaining production-grade reliability.
- For Scaling Concerns: Make handles legitimate business growth without requiring infrastructure changes on your end.
- For User Experience: Response times remain acceptable even under heavy load, ensuring your users won’t experience frustrating delays.
- For Cost Management: No need to provision servers, manage scaling, or worry about infrastructure costs during traffic spikes.
What the Data Doesn’t Show
While the metrics prove Make’s technical reliability, there are qualitative benefits that numbers can’t capture:
- Development Speed: Building this automation took 30 minutes in Make without needing any coding skills.
- Maintenance: No server management, security updates, or infrastructure concerns.
- Flexibility: Easy to modify the workflow, add new integrations, or change business logic.
Real Cost Analysis
Alternative Costs: Custom development would require:
- Initial development: 5-10 hours
- Server costs: $10-40/month
- Maintenance: 2-4 hours/month
For most SaaS applications, Make offers better ROI, especially during the crucial MVP and early growth phases.
Make Grid: Your Stress-Testing Secret Weapon
Make Grid is a new feature that helps you see every part of your backend in action—live, clickable, and transparent. It shows you an interactive, real-time map of all your scenarios.

Here’s what makes Grid so powerful:
Bird’s-eye View & Dependencies
Each tile represents a folder or scenario, connected by lines that show data flows between webhooks, APIs, databases, AI modules, and other components. Purple links mean one asset triggers the next, while blue links show data passing between modules.
Live Interaction
Click on any node or link to inspect metadata, such as execution statistics or module properties. It provides important insights into how things connect, such as which webhook links are associated with which scenario, what data is being passed, and more.
Search & Filter Control
A search bar lets you find assets, fields, or URLs instantly. Filters help you drill down by folder, team, error state, or AI usage—whatever you need.
Real-time Monitoring & Debugging
Grid highlights scenarios with errors or slowdowns, making it easy to spot performance bottlenecks. During your stress tests, Grid surfaces slow or failed executions, so you can fix issues before they cause any problems.
Operational Insights
Beyond visibility, Grid shows operation-heavy flows. You can identify which workflows are consuming the most quota, a key for cost optimization.
Conclusion: Make as Your Reliable Backend
This stress test proves that Make can absolutely serve as a production-grade backend for SaaS applications.
The 100% success rate across all test levels, combined with reasonable response times and excellent observability through Make Grid, makes it a compelling choice for non-developers and developers who want to focus on building features rather than managing infrastructure.
The question isn’t whether Make can handle your backend needs. The test results prove it can. The real question is: What could you build if you didn’t have to worry about backend infrastructure?
Start with the blueprint I’ve provided, run your own tests, and discover how automation platforms can accelerate your next SaaS project.