solobuild
Running a business alone means you are also the operations department. Every form submission, every payment, every support email lands on you, and the small handoffs between tools quietly eat hours that never show up on an invoice. Most solo founders eventually open an automation platform to fix this, then stall out because they choose the wrong first project. The instinct is to automate whatever feels most annoying, which is usually the most complicated thing you do, and complicated automations break in ways that cost more time than they save.
The better starting point is boring work. The tasks worth automating first are small, repetitive, and triggered by something predictable, because those are the ones where a machine beats you on consistency rather than on judgment. What follows is five specific automations in the order I would build them, along with the places each one tends to break. Every one of them can be built in Make without writing code, though the same logic applies if you already use something else.
Pick automations by frequency, not by frustration
Before building anything, it helps to understand how these platforms charge you, because that shapes what is worth automating. Make bills in credits, which were called operations until the naming changed in 2026. Each module action counts as one credit, so a scenario that watches a form, adds a subscriber, and sends you a message burns three credits every time it runs. As of September 2026 the free plan includes 1,000 credits per month, two active scenarios, and a minimum scheduling interval of fifteen minutes. The Core plan starts at $12 per month for 10,000 credits with a one minute minimum interval, and annual billing cuts that by roughly fifteen percent.
That pricing model rewards a specific kind of automation. Anything that fires a handful of times a day and replaces five minutes of clicking is a good trade. Anything that polls a busy inbox every minute and replaces almost nothing will drain your credit budget while you sleep. So the filter is not how much a task irritates you, it is how often the task happens and how many steps it takes you to complete by hand.
There is a second filter worth applying. Automate the tasks where being late is expensive, because that is where consistency actually earns money. A lead who fills out your form at 11pm and hears nothing until Tuesday is a lead you probably lost, and no amount of good intentions fixes that as reliably as a scenario that runs whether or not you are awake.
1. The signup handoff
This is the first one to build because it touches revenue and because it is short enough to debug in an afternoon. Someone fills out a form on your site, and three things need to happen: the person gets added to your email list, you get a notification with their details, and the submission gets written to a spreadsheet so you have a record outside of any single tool. Built by hand, that is maybe four minutes of copying and pasting. Built once in Make, it is a four module scenario that runs forever.
The version I would start with watches your form provider, then creates or updates a subscriber in your email tool, then posts a message to wherever you actually look during the day. If you are on Kit or a similar platform, the subscriber step also lets you apply a tag, which is what makes later segmentation possible without a cleanup project. Add the spreadsheet row last, since it is the step you will thank yourself for the first time an app changes its export format.
The common failure here is duplicate contacts. If your form allows resubmission, or if you also import subscribers manually, you can end up with two records for one person and a welcome sequence that fires twice. Use the create-or-update module rather than the plain create module, and add a filter that skips the scenario when the email field is empty. Those two small choices prevent most of the mess.
2. The payment event chain
The second automation covers what happens after money arrives. A payment lands in Stripe, Gumroad, Lemon Squeezy, or whatever you sell through, and the customer needs access to what they bought, you need the sale recorded somewhere you can total up later, and you probably want a notification you can see without opening a dashboard. Doing this by hand is fine for the first ten sales. It stops being fine right when you least want to be doing admin, which is during a launch.
Build this as one scenario with a webhook trigger rather than a scheduled poll. Payment platforms will send Make a webhook the instant a charge succeeds, which means the customer gets their access in seconds instead of on your next fifteen minute check, and you spend credits only when a sale actually happens. The chain is usually four or five steps: receive the webhook, add or tag the customer in your email tool, write a row to your sales log, and send yourself the alert.
Two things break this one. The first is test payments polluting your real records, which you avoid by adding a filter on the live mode flag before anything downstream runs. The second is refunds, since the original scenario has no idea a charge was reversed. You do not need to solve refunds on day one, but write down that the gap exists so you do not trust your sales log more than it deserves.
3. The daily digest
By the time a solo business has a few moving parts, the morning routine turns into a tour of dashboards. You check analytics, then payments, then the support inbox, then whatever else is running, and twenty minutes disappear before any real work starts. A digest scenario collapses that tour into one message that arrives at a fixed time, which is a small change that compounds because it removes a reason to open the apps at all.
The build is a scheduled scenario that runs once each morning, calls two or three sources, and formats the results into a single email or chat message. Keep the numbers few and specific: yesterday's revenue, new subscribers, open support threads, and one metric that actually reflects your goal this quarter. A digest with fifteen numbers gets skimmed and then ignored, so the discipline is in what you leave out.
Cost is worth watching here. A digest that runs once a day at five modules is about 150 credits a month, which fits comfortably even on the free plan. The same digest set to hourly is roughly 3,600 credits, and it will not tell you anything useful in between. Choose the schedule that matches how fast the underlying numbers actually move.
4. The stalled conversation reminder
Follow-up is where solo businesses leak the most money, and it leaks quietly. You send a proposal, the prospect says they will look at it, and then a week goes by while you are heads down building. Nobody is at fault and the deal still dies. The fix is not a CRM you will not maintain, it is a small scenario that watches a single list and tells you when something has gone quiet.
The simplest working version uses a spreadsheet or a Notion database as the source of truth. Each row is a conversation with a status column and a last-contacted date. A scheduled scenario runs every morning, filters for rows where the status is open and the last contact is more than five days old, and sends you one message listing them. You still write the follow-up yourself, which is the point, because the automation is handling the remembering rather than the relationship.
What breaks this is data hygiene rather than logic. If you forget to update the last-contacted date, the reminder either nags you about a conversation you already handled or goes silent on one you did not. Adding a second small scenario that updates the date whenever you send an email is possible, though for most people it is easier to update the row as part of sending the follow-up. Keep the source list short enough that maintaining it by hand takes under a minute a day.
5. The backup snapshot
The last of the five protects you rather than saving you time, and it is the one most people skip. Every tool you use holds data you would struggle to reconstruct: subscriber lists, form submissions, sales records, client files. Accounts get locked, integrations change, free plans get restructured, and export buttons are never available exactly when you need them. A weekly snapshot into storage you control turns a potential disaster into an inconvenience.
Build it as a scheduled scenario that runs weekly, pulls the records added since the last run, and appends them to a spreadsheet or writes files to cloud storage. Incremental is better than full, both because it uses fewer credits and because a full export of a growing list will eventually time out mid-run. Name the destination file with the date so you can tell at a glance whether the backup is current.
The failure mode is silence. A backup scenario that quietly stopped working three months ago is worse than no backup, because you were counting on it. Set an error handler that messages you on failure, and once a quarter open the destination file and confirm the newest rows are actually recent.
| Automation | Trigger | Roughly what it replaces | Credits per month |
|---|---|---|---|
| Signup handoff | New form submission | 4 minutes of copying per lead | Low, scales with signups |
| Payment event chain | Payment webhook | 5 minutes of fulfillment per sale | Low, scales with sales |
| Daily digest | Scheduled, once daily | 15 to 20 minutes of dashboard checking | About 150 |
| Stalled conversation reminder | Scheduled, once daily | Follow-ups you would have forgotten | About 100 |
| Backup snapshot | Scheduled, weekly | An export you keep meaning to do | Under 50 |
How to build these without creating a second job
The pattern that works is to document the manual process first, in writing, before opening the builder. Write down every step you take by hand including the ones you do without thinking, then build them one module at a time and run the scenario after each addition. This is slower on the first day and much faster over the following month, because when something fails you know precisely which step introduced it.
Error handling deserves more attention than it usually gets. In Make, error handlers attach to individual modules rather than to the scenario as a whole, so it is common to have one carefully protected module and nothing at all three steps later. Most failures fall into a few categories: the upstream API returned an error, the data arrived in a shape the module did not expect, an authorization token expired, or the logic itself was wrong. Knowing which category you are in is the difference between a five minute fix and an hour of guessing.
Two habits keep the whole system maintainable. Rename every module to describe what it does in plain language, because six months later "Google Sheets 3" tells you nothing. And check your credit usage after the first full week of any new scenario, since the gap between what you expected to spend and what you actually spent is the fastest way to catch a scenario that is running far more often than you intended.
Frequently asked questions
How many operations does a simple automation use? One credit per module action, so a four step scenario costs four credits each time it runs. A scenario triggered by twenty form submissions a month uses about eighty credits. Scheduled scenarios are more predictable to estimate: multiply the number of modules by how many times a day it runs, then by thirty.
Do I need to know how to code to build these? No. All five are built by connecting prebuilt app modules and setting filters, and the hardest part is usually mapping a field from one app to another correctly. You will run into occasional formatting work, like reshaping a date or splitting a full name into two fields, and Make handles those with built-in functions rather than code.
Is the Make free plan enough for a solo founder? For one or two automations, often yes. The limits that bite first are the two active scenario cap and the fifteen minute minimum interval, which rules out anything that needs to feel instant unless you use a webhook trigger. Webhooks fire immediately on every plan, so the free tier goes further than the interval limit suggests.
What happens if an automation fails and I do not notice? Make logs every run and will email you about scenarios that fail repeatedly, but the default settings are easy to ignore. Add an explicit error handler on the modules that matter, pointed at whatever channel you actually read, and treat a silent scenario as suspicious rather than as proof that everything is fine.
Should I use Make or Zapier for this? Both will build all five. Make tends to cost less at the volumes a solo business generates and gives you more control over branching logic, while Zapier is easier on the first day and has broader app coverage. There is a fuller comparison in our Zapier vs Make breakdown for solo builders if you are choosing between them.
Where to start this week
Build the signup handoff first, and build it before you feel ready. It is short, it touches the part of your business where delay costs the most, and finishing it teaches you the mechanics you need for the other four. Give yourself an afternoon, accept that the first version will be rough, and resist the urge to add branches until the simple path has run cleanly for a week.
After that, add the payment chain when you have enough sales to feel the manual work, and the daily digest whenever you notice yourself opening the same three dashboards every morning. The reminder and the backup can wait until the first two are stable, though the backup should not wait long. The goal is not an impressive automation setup. The goal is a business that keeps its promises on the days you are busy, sick, or simply not at your desk.