Free · No email required · Written by us · Make pricing checked 22 August 2026
The Make Automation Starter Kit
Make pays us a commission if you sign up through our link. This kit is ours, not theirs — they haven't seen it, and Part 2 is largely about how not to give them more money than you need to. It's free either way, and there's nothing to enter.
Most people open Make, build something that works, and discover a month later that it ate their entire credit allowance doing nothing useful. That isn't a failure of the tool. It's a failure to do about ten minutes of arithmetic first.
This kit is those ten minutes, plus five scenarios worth building and an honest note on when to use something else.
Part 1
What to automate first — and what not to
Automation earns its cost when it removes a task you're doing repeatedly by hand, and only then. Before you build anything, the test is: am I doing this more than about twenty times a month, and does it take me more than a minute each time? If not, leave it.
In order of how much time they usually save:
- Lead capture → wherever leads live. Form or landing page fills, straight into your CRM or a sheet, tagged with the source. This is the one almost everyone should build first
- Payment → fulfilment. Someone buys, they get access, you get told, the record gets updated. High value because the cost of getting it wrong is a refund request
- Enquiry → notification. Anything time-sensitive that currently depends on you noticing an email
What not to automate yet: anything you do occasionally, anything whose rules you're still changing weekly, and anything where a silent failure would be expensive but hard to notice. Automation is a commitment to a process. If the process isn't settled, you'll spend more time rebuilding the scenario than you saved.
Part 2 — the important one
Credit planning: the arithmetic before you build
Make charges one credit for every module run. Not every scenario run — every module inside it. A five-step scenario that runs 100 times costs 500 credits, not 100.
That part people work out eventually. This is the part that catches almost everyone:
Your trigger spends credits when nothing has happened
A polling trigger checks on a schedule and costs a credit each time it looks — whether or not there's anything new. Do the arithmetic before you switch a scenario on:
| Polling interval | Checks per month | Against Core's 10,000 |
|---|---|---|
| Every 15 minutes | ~2,880 | 29% of your allowance, before any work |
| Every 5 minutes | ~8,640 | 86% — one scenario, doing nothing |
| Every minute | ~43,200 | 4× over. Impossible on Core |
Note what that means for the free plan. Free gives you 1,000 credits and a 15-minute minimum interval. So a single always-on scheduled scenario costs about 2,880 credits a month in checks alone — nearly three times the entire free allowance, before it does a single useful thing.
The fix is usually webhooks, not a bigger plan
An instant or webhook trigger doesn't poll. It sits there costing nothing and fires only when something actually happens. Where the app you're connecting supports one, that single change removes the entire cost above.
Before you upgrade a plan because you're running out of credits, check whether your triggers can be instant instead of scheduled. It is very often the whole problem.
The estimate to write down before building. For each scenario:
(modules per run × expected runs per month) + (trigger checks per month) = credits
Add them up across your scenarios, then add 40%. The 40% is for the retries, the test runs, the branch you forgot and the month your volume spikes. If that total is over your plan, fix the design before you buy more capacity.
Part 3
Five scenarios worth building
Each of these is small enough to build in a sitting. The module counts are approximate — use them for the arithmetic in Part 2.
| Scenario | Shape | ~Modules |
|---|---|---|
| 1. Form → CRM | Webhook from your form → filter out obvious junk → create or update the contact → tag with the source | 3–4 |
| 2. Payment → access + alert | Payment webhook → grant access → update the record → notify you | 4 |
| 3. New subscriber → welcome path | New contact → router on source → add to the right sequence | 3–5 |
| 4. Weekly numbers digest | Schedule weekly → pull the figures → format → send to yourself | 4–5 |
| 5. Failed payment → chase | Failure webhook → look up the customer → send the email → flag for follow-up | 4 |
Notice that four of the five are webhook-triggered. That's deliberate, and it's the difference between these five scenarios costing a few hundred credits a month and costing more than a Core plan provides.
Build number 1 first, run it for a week, and compare the credits it actually consumed against what you estimated. Your estimate will be wrong. It's much cheaper to find that out on one scenario than on six.
Part 4
Seven mistakes that burn credits
- Polling when a webhook exists. The single biggest one, and worth checking on every scenario you've already built
- Filtering too late. Put the filter immediately after the trigger. Every module before it runs on records you were going to discard anyway
- Iterating over a whole dataset. An iterator over 500 rows runs its downstream modules 500 times. Narrow the search first
- Re-scanning instead of watching. “Search rows” re-reads everything on every run; “watch new rows” reads only what's new
- Testing on a live scenario. Test runs consume credits like real ones. Limit the data during testing
- No error handling. A scenario that fails silently either stops working or retries forever. Both are expensive — one in missed work, one in credits
- AI modules left unbounded. They consume at a higher and less predictable rate than standard modules. Put them behind a filter, never on the trigger
Part 5
The planning sheet
Answer these six before you open Make. Ten minutes here saves an afternoon of rebuilding.
1. The triggerWhat event starts this? Is there a webhook or instant trigger for it, or does it have to poll? If it polls, what's the longest interval you can live with?
2. The filterWhat should stop this scenario early? Write the condition now — it goes immediately after the trigger, not at the end.
3. The actionsList them in order. Count them. That number is your per-run credit cost.
4. The volumeHow many times a month, honestly? Then multiply by the count above.
5. The failureIf this breaks on a Tuesday and nobody notices until Friday, what's the damage? If the answer is meaningful, build an error handler and a notification now.
6. The exitWhat would tell you this automation is no longer worth running? Write it down. Dead scenarios quietly consume credits for months.
Part 6
When Make is the wrong tool
We earn a commission from Make, so treat this section as the one to read hardest.
- Your workflows are long. Make charges per module, so a fifteen-step workflow costs fifteen credits a run. n8n charges per whole execution — the same workflow costs one. If your scenarios are long and frequent, that difference is decisive. Full comparison
- Your triggers must poll frequently. If the app has no webhook and you need checks every few minutes, Make's model works against you. Pabbly Connect counts only action steps, so polling is free. Full comparison
- The app you need isn't supported. Zapier connects around 9,000 apps against Make's smaller library. An automation you can't build has no cost advantage. Zapier pays us nothing and never can
- You're not running several tools yet. If everything already lives on one platform, there's nothing to connect. Automation between tools solves a problem you don't have yet
Being straight about the money here: n8n and Zapier pay us nothing, and Zapier structurally never can — we recommend both above anyway. Pabbly Connect does pay us, so when this page sends you there for frequent polling, we earn either way. That's the one recommendation in Part 6 you should check rather than take on trust, and the billing difference behind it is published on both vendors' own pricing pages. We'd rather you paid less for the right tool than more for ours.
Ready to build
Start on the free plan and build scenario 1 from Part 3. Run it for a week. Compare the credits it used against your estimate from Part 2, then decide whether you need Core — and whether your triggers should be instant rather than scheduled.
Affiliate link — we may earn a commission if you sign up. Your price is unchanged, and the free plan is genuinely free.
Read the full Make review first →
Everything in this kit is ours. It isn't Make documentation, it isn't affiliate material, and nobody paid for a word of it. If something here is wrong, tell us and we'll fix it.