solobuild
Publishing content by hand is a slow leak on a solo business. You write the post, then you copy it into the blog editor, then you rewrite a shorter version for LinkedIn, then you paste a link into a newsletter draft, then you update the spreadsheet where you track what went out. None of those steps are hard. Together they eat an hour or two every week, and they are exactly the kind of work that gets skipped when a client deadline lands. This guide walks through how to automate the publishing half of that workflow so that writing stays the only manual step, using a Notion database as the source of truth and Make as the engine that moves content from there to wherever it needs to go.
The approach here is deliberately modest. The goal is not to remove yourself from your content. It is to remove the copy-paste, the status updates, and the "did I already share this" checks that add friction without adding value.
Start with a single source of truth
Every publishing automation depends on one place where content lives and where its status is tracked. If a draft exists in Google Docs, its headline exists in a spreadsheet, and its publish date exists in your calendar app, no automation tool can stitch that together reliably. So the first job is to consolidate. For most solo founders, a Notion database is the right container because it holds long-form text, structured properties, and a status field in the same row.
A workable content database needs fewer properties than most templates suggest. Title, Status, Publish Date, Channel, and a Summary field cover almost everything. Status should be a select property with a short list of stages such as Idea, Drafting, Ready, Published, and Failed. Channel should be a multi-select so a single piece can target the blog and a LinkedIn post at the same time. The Summary field holds the short version you would paste into social platforms, which matters because most social APIs reject anything over a few hundred characters and you do not want an automation truncating your writing mid-sentence.
Resist the urge to build a large content operating system on day one. Automation tools read database properties far more reliably than they read page bodies, and every property you add is another field the automation has to map. Notion's own webhook actions, for example, can send page properties but not page contents, according to the Notion help center. That single limitation shapes the whole design: the text you want published should live in a property, or your automation needs a separate step to fetch the page body through the API.
One pricing detail matters before you commit. Notion's help center states that database automations are available on paid plans, and free workspaces can only create Slack notification automations. The pricing page adds a wrinkle by listing Plus as "buttons only" for automations and reserving custom database automations for Business. Plus is $10 per seat per month on annual billing, and Business is $20. A solo workspace is one seat, so the real cost is small, but you should check what your specific plan allows before designing around a trigger you may not have. You can compare the tiers on Notion's pricing page.
Choose your trigger carefully
The trigger is the event that starts the automation, and this is where most solo builders lose money without noticing. The obvious choice is to have your automation platform watch the Notion database for changes. Make offers a Watch Database Items module that does exactly this, and it works. The problem is how it works. It polls, meaning it checks the database on a schedule and looks for rows whose last edited time has changed since the previous check. On the Make Free plan the minimum interval is 15 minutes, and on paid plans it can run every minute.
Every one of those checks consumes credits, which is what Make now calls its billing unit. A Make community thread from January 2025 describes a user whose Watch Database Items scenario was running every minute and burning through their allowance on days when nothing was published. Other threads report the trigger firing when no real change was made, or missing a second edit that happened within the same minute as the first. These are not bugs you can configure around. They are the nature of polling a tool that updates its "last edited" timestamp on its own schedule.
The better pattern, and the one Make community members recommended in that same thread, is to flip the direction. Instead of Make asking Notion whether anything changed, have Notion tell Make when something changed. Notion's database automations support a "property edited" trigger with a condition like "Status is set to Ready" and a "send webhook" action that fires an HTTP POST to any URL. Make provides a custom webhook module that generates that URL in about ten seconds. When you move a row to Ready, Notion pushes the page properties to Make instantly, and the scenario runs exactly once. No polling, no wasted credits, no missed edits.
If your Notion plan does not include database automations, a database button is the fallback. A button property can also send a webhook, so you add a "Publish" button to each row and click it when a piece is done. That is one manual click instead of five manual steps, which is still a meaningful trade. It also gives you a deliberate moment to confirm the piece is actually ready, which some builders prefer over a status change that can be triggered by accident.
Build the Make scenario
Make is the right automation platform for this job for a practical reason: the visual builder makes multi-channel routing easy to reason about, and the free tier is generous enough to run a real publishing workflow. As of September 2026 the Free plan includes 1,000 credits per month and up to 2 active scenarios. Core is $12 per month for 10,000 credits and unlimited scenarios, and Pro is $21. A weekly publishing workflow that touches three or four channels will use well under 100 credits a month, so most solo founders never leave the free tier for this use case. You can sign up for Make and build the first version in an afternoon.
The scenario itself has a simple shape. The custom webhook receives the Notion payload. A Notion "Get a Page" module fetches the full page so you have the body text as well as the properties. A router then splits the flow by channel. One branch formats and posts to your blog platform, another prepares a social post, a third creates an email draft. At the end of each branch, a Notion "Update a Database Item" module sets Status to Published and records a timestamp. If any module fails, an error handler on that branch sets Status to Failed and sends you a short notification so you can fix it by hand.
Two details make this reliable rather than merely functional. First, put the status update at the end of each branch, not the beginning. If you mark the piece Published before the blog post actually goes live and the API call fails, your database now lies to you. Second, add a filter right after the webhook that checks the status value in the payload. Notion automations can fire on any property change if you configure them loosely, and a filter that only lets "Ready" through costs one credit and prevents a lot of confusion.
For the blog branch, the target depends on where your site lives. WordPress has a native Make module that can create posts, set categories, and attach featured images. Ghost and Webflow have modules as well. If your site is a static build on something like Astro or a custom Next.js deployment, you will likely use an HTTP module to commit a markdown file to a GitHub repository, which then triggers your deploy. That sounds intimidating but it is a single HTTP request with a base64-encoded body, and Make's HTTP module handles it without code.
Handle social scheduling without overbuilding
Social platforms are where publishing automations get complicated, and it is worth being honest about the trade-offs. Make has direct modules for LinkedIn, X, Facebook, and Instagram, so you can post straight from the scenario. The downside is that each platform's API has its own quirks around media, character limits, and authentication tokens that expire. When a token expires, your scenario fails quietly at 6am and you find out at lunch. Solo builders who post to one platform can live with this. Those posting to three or more usually reach for a scheduler.
A scheduler like Buffer sits between Make and the platforms. Make creates a post in Buffer through its API, Buffer handles the platform-specific formatting and timing, and you get a single dashboard to see what is queued. Buffer's Free plan supports 3 connected channels and 10 scheduled posts per channel, which refill as posts go out. Essentials is $5 per channel per month on annual billing. For a solo founder posting a few times a week to LinkedIn and X, the free tier holds up for a long time.
The reason to route through a scheduler rather than post directly is separation of concerns. Make is good at moving data between systems. Buffer is good at the last mile of social publishing, including the preview, the best-time suggestion, and the retry when a platform is flaky. Keeping those roles separate means that when LinkedIn changes its API, you wait for Buffer to update rather than rebuilding your own module. It also means you can pause the queue for a week without touching your automation.
There is one scenario where skipping the scheduler makes sense. If you only ever cross-post a link to a new blog article with a one-line summary, and you only do it on one platform, the direct module is fine and saves a tool. The rule of thumb is that direct posting works for one channel with plain text, and a scheduler earns its place once you have images, multiple platforms, or any interest in timing.
Add the email and tracking layer
The last stage of most publishing workflows is telling your list. The mistake here is to fully automate the send. An automation that publishes a blog post and immediately blasts your newsletter with a templated "New post: [Title]" email will produce the flattest emails you have ever sent. A better design is to have Make create a draft in your email platform with the title, the summary, and the link already filled in, then leave the send to you. Kit, GetResponse, and most other platforms expose a draft-creation endpoint, and Make has modules or HTTP support for them. You open the draft, add two sentences of context, and hit send. The tedious part is done and the human part is preserved.
Tracking closes the loop. Because every branch ends by writing back to Notion, your content database becomes a publishing log without any extra effort. Add a URL property for the live blog link, a date property for when it went out, and a checkbox per channel. Make fills these in as each branch completes. Six months later you can filter by channel and date to see what you actually shipped, which is information most solo founders do not have because it lived in five different tools.
One practice from an Indie Hackers discussion on automation is worth adopting: document the manual process first, then automate one step at a time in order of how costly a mistake would be. Start with the blog publish because a failed post is visible and easy to redo. Add social second. Add the email draft last, since a mistake there reaches the most people. Building in that order means each failure you encounter during setup is a small one, and you learn the shape of your own workflow before trusting it end to end.
Comparison table
| Tool | Best For | Free Tier | Starting Price |
|---|---|---|---|
| Notion | Content database and source of truth | Yes, but no database automations | $10/seat/month (Plus, annual) |
| Make | Routing content between tools | 1,000 credits/month, 2 active scenarios | $12/month (Core) |
| Buffer | Last-mile social scheduling | 3 channels, 10 scheduled posts each | $5/channel/month (annual) |
| Zapier | Simpler setup with wider app coverage | 100 tasks/month, 2-step Zaps only | $19.99/month (Professional, annual) |
Zapier is included because it is the most common alternative to Make and its "New Database Item" trigger for Notion fires only on real additions rather than polling for edits, which some builders prefer. The trade is price. Zapier's paid tier costs more than Make's and includes fewer runs, and its free plan limits you to two-step workflows, which is not enough for a router-based publishing scenario.
Frequently asked questions
Can I automate content publishing for free?
Yes, for a modest workflow. Make's free plan has enough credits to run a weekly publish across a few channels, and Buffer's free plan covers three social accounts. The gap is Notion, where database automations require a paid plan. If you want to stay fully free, use a Notion database button to send the webhook instead of a status-change automation, or accept the polling trigger in Make and keep the interval at its slowest setting to conserve credits.
Should I use Make or Zapier to automate publishing from Notion?
Make is cheaper and its visual router handles multi-channel publishing cleanly, which is why this guide uses it. Zapier is easier to set up for a single straight-line workflow and has a Notion trigger that avoids the polling problem. If your workflow is Notion to one blog and nothing else, Zapier's simplicity may be worth its higher price. If you are routing to three or more destinations, Make's pricing and router make more sense.
How do I trigger Make when a Notion status changes?
Use a Notion database automation with a "property edited" trigger set to your Status property, a condition of "Status is set to Ready," and a "send webhook" action pointed at a Make custom webhook URL. This pushes the change to Make instantly and uses no credits for polling. If your Notion plan does not include that automation, a database button with a webhook action does the same thing on a click.
What happens if part of the automation fails?
That depends on whether you built an error handler. Without one, the scenario stops at the failed module and the remaining branches never run. With one, you can route the failure to a Notion update that sets Status to Failed and a notification to your email or phone. Build the error handler before you trust the scenario, and test it by deliberately breaking a connection once.
Can Make publish the full body of a Notion page?
Yes, but not from the webhook payload alone. Notion's webhook actions only send page properties. To get the body, add a Notion "Get a Page" or "Get Page Content" module after the webhook, using the page ID from the payload. That returns the blocks, which you can convert to markdown or HTML before posting to your blog.
Conclusion
The best publishing automation for a solo founder is the one that removes copying and status-tracking while leaving writing and sending in your hands. A Notion database gives you one place to draft and one place to see what went out. A Notion webhook, rather than a polling trigger, gets that content to Make without burning credits on empty checks. Make's router sends it to the blog, to a scheduler, and to a newsletter draft, and then writes the result back so your database stays honest. None of this requires code, and the free tiers of Make and Buffer will carry most solo workflows for a long time.
Build it in stages, blog first and email last, and keep a Failed status so problems surface instead of hiding. Once it runs for a month you will notice the hour it gives back each week, and more importantly you will notice that you publish more consistently because the friction after writing is gone.