Move your Make scenarios to Whisk
A Make scenario is already a small program. It has a trigger, modules that do things, routers that branch and error handlers that catch failures. That makes it easy to turn into an app: export the scenario, give the file to an AI coding assistant, and it writes the same logic as code that runs on Whisk.
The reason to do it is usually the bill, once the scenario gets busy.
Where Make's credits go
Make charges in credits. Each module that runs uses one, every time. That includes the trigger.
Take a scenario at a business that sells packaging to other businesses. Every 15 minutes, it checks the online store for new orders. For each order, it looks up the customer in the accounting system, creates the invoice, loops through the order lines to check stock, and adds the order to the dispatch sheet.
- Checking for orders. A check every 15 minutes uses a credit each time, even when there's nothing new. That's about 2,900 credits a month before a single order is handled.
- Each order. The lookup, the invoice and the dispatch row are three credits.
- Each order line. The stock check runs once per line. An order with eight lines uses eight credits for that one step.
At 50 orders a working day with eight lines each, that's roughly 1,100 orders, 12,000 credits for the order steps and the checks on top. That's well past the 10,000 credits that Make's Core plan includes for $12 a month. Then you either move up a tier or buy extra credit packs, and a busy month uses them up faster.
Prices are in US dollars, from Make's pricing page in October 2026.
The same scenario on Whisk
On Whisk, each order is one run of a workflow, however many modules, loops or branches it has. The stock check on eight lines doesn't cost eight of anything.
The store can also tell the app about a new order the moment it's placed, so nothing has to check every 15 minutes. Most online stores and accounting systems can send these messages, and Whisk checks each one really came from them.
The 1,100 orders are 1,100 runs. Every business runs one app free, with 10,000 runs a month. Starter is $49 a month for 10 apps and 100,000 runs. If you ever reached the allowance, new runs would wait rather than be charged.
How Make's parts map across
| In Make | In the app on Whisk |
|---|---|
| Trigger that checks on a schedule | A message from the store when something happens, or a schedule if the system can't send one |
| Module | A step in the workflow |
| Router and filters | Ordinary if and else in the code |
| Iterator and aggregator | A loop over the order lines |
| Error handler | Each step retries by itself, and the run picks up from the step that failed |
| Data store | A table in the app's own database |
| Connections | Access keys kept in Whisk's secrets |
Moving it
In Make, open the scenario, open the menu at the bottom and choose to export the blueprint. You get a JSON file that describes every module and how they connect.
Give that file to an AI coding assistant like Claude Code, Cursor or Codex, with this prompt:
Read https://whisk.run/skill and follow it. The attached file is a Make scenario blueprint. Rebuild it as a Whisk app with a workflow that does the same thing, one workflow step per module. Where the scenario checks for new data on a schedule, use a webhook from that system instead if it can send one. Turn the data store into a database table, and copy its current rows from the attached export. Ask me for the access keys you need through Whisk's secrets. Deploy it to Whisk when it passes whisk doctor.
Before you switch the scenario off, run them side by side for a few days with the scenario's last module turned off, and compare the results.
When to keep it in Make
A scenario that runs a few hundred times a month fits inside Make's plans and costs very little. It isn't worth moving. Move the ones with loops over many items, the ones that check on a short schedule, and the ones that are growing with the business.