Blog autopilot
Automated blog content generation you still publish.
It researches a query people are actually typing, drafts the whole article in your brand voice, illustrates it, and files it as a draft. Nothing reaches your website until a person has read it and pressed publish.
Free to start · No card required
How it works
A content program, not a prompt box.
Most “AI blog” tools hand you a text field and a word count. This one runs the loop a content team runs: find the query, research it, write the piece, keep a person in front of the publish button, and give your website a clean way to fetch what survived.
Ideas researched, not invented
Every article starts on somebody else’s page
Each piece begins with a live search pass over your niche rather than with a blank prompt, so the topics are ones people are actually typing. The pass returns titles, a target keyword and the source URLs behind each idea, and the source list is stored on the article row.
- Gemini google_search grounding does the research; the draft may only link to what it returned, or to your own site.
- You can bias the pass toward specific queries — including the tracked keywords the SEO engine says you are currently losing on.
- Your company description is fenced as untrusted data, never as instructions.
A finished article, not an outline
Built the way a page that answers a query has to be built
A thousand to eighteen hundred words of markdown in your brand voice, written to the format the day calls for — a guide, a how-to, a listicle or a comparison. Each of the six blocks below is a line in the drafting brief, not something hoped for, and each is numbered to where it lands on the page beside it.
- 1A 16:9 cover image to your art direction, and illustrations placed under the article’s own section headings rather than sprinkled.
- 2A direct answer to the title in two or three bolded sentences inside the first fifty words, so an answer engine can lift the paragraph whole.
- 3Key takeaways: three to five scannable bullets under the opening.
- 4H2s phrased the way searchers type, each opening with a self-contained forty-to-seventy-five-word answer.
- 5At least one table, framework or checklist — structured data written as a table, not as a paragraph describing one.
- 6A closing FAQ of three to five question-and-answer pairs, each question a heading.
Spaced, not batched
A failed run costs an hour, not a day
Articles publish on a fixed cadence with the format rotating through the week, so a blog doesn’t arrive as one indistinguishable burst. The obvious way to schedule that is a single attempt at a fixed hour. We shipped that first, and one failed provider call silently cost a whole day of publishing — twice — before anyone noticed the gap in the archive.
- So the planner is a pure function of the clock and the blog_posts table: once an hour it asks what is still outstanding, and each duty stays due until the database proves it happened.
- Retrying is the normal path, not the exception — which is also why a burst of twenty articles in one afternoon is something this never does.
The duty stays due until the database proves the article exists.
What actually gets published
What lands in the draft, down to the credit.
Read it before you turn it on. The length, the pictures, the status string, the weekly shape and the price are each a constant or a debit in the code.
- Length and format
- 1,000–1,800 words of finished markdown, written to the format the day calls for: a guide, a how-to, a listicle or a comparison.Structured data is written as a real table — a comparison gets one row per dimension and one column per contender.
- Images
- A generated 16:9 cover image, plus illustrations placed under the article’s own section headings.Drawn to your art direction — theme, medium, palette, and a list of things to keep out. Cover images are a Pro-plan feature.
- Stored with the body
- The slug, the target keywords, the meta description and the full source list.The detail endpoint returns ready-made Article JSON-LD built from them — see the integration guide.
- Status on save
- generated→ a person marks it published →publishedpublished is the only status the public read API will serve. There is no setting that skips this.
- Format rotation
- MonGuideTueHow-toWedListicleThuComparisonFriGuideSatHow-toSunListicleThe rotation running on FounderReply’s own workspace — the blog on this domain, all times UTC.
- Whose schedule this is
- Ours. Your workspace runs the same engine on demand: from the dashboard, from one call to the blog generate endpoint, or from the generate_blog_posts tool over MCP.Same writer, same research pass, same publish gate — you decide when it runs instead of a cron deciding for you.
- Conquest and refresh
- Monday, a conquest batch of two pages, published unlisted. Thursday, a refresh pass that redrafts the two stalest posts in place, at the same URL.Stale means no content change in roughly four months, or a target keyword ranking outside the top ten — so the update date moves only when the content genuinely did.
- What it costs
- One credit per saved article, debited as it is written; a generated cover image costs five more.A run only drafts what your balance can pay for, so a workspace out of credits quietly generates nothing rather than failing loudly.
- After you publish
- With a blog base URL and an IndexNow key in your site config, the new URL is pinged for indexing; the day’s target keywords are seeded into the rank tracker, so the SEO engine starts watching the queries the blog just went after.IndexNow feeds the Bing chain. Google discovers the page through your sitemap — nobody can promise it faster than that.
Nothing publishes itself
Two things sit across the pipe, and one of them is you.
A draft passes a link check the model does not control — anything it introduced that does not trace back to a stored source is stripped from the body before the article is saved — and then it stops. It stays stopped, at status: generated, until a person reads it, edits it if it needs editing, and marks it published.
It is the same human gate the approval queue puts in front of every social reply, applied to writing instead of to replies.
The limits
What it will and will not do
Written as rules rather than as reassurance, because a rule is checkable and reassurance is not.
Blog autopilot, as a contract
Every line on both sides is a behaviour in the shipped code, not a policy we intend to adopt.
The read API
Your published posts, over one GET.
FounderReply stores the articles; your website renders them. Bodies are omitted from the list, so it is cheap enough to call from a build step — fetch a full article from the same route plus its slug.
# every published post, newest first
curl "https://founderreply.com/api/public/blog?workspace_id=<uuid>"
# optional params
# visibility=listed | unlisted | all (default: listed)
# limit=1..200 (default: 50)
# offset=0.. (default: 0){
"ok": true,
"total": 24, "limit": 50, "offset": 0,
"posts": [
{
"id": "…", "title": "…", "slug": "…",
"type": "guide",
"keywords": ["…"],
"meta_description": "…",
"cover_image_url": null,
"created_at": "…", "published_at": "…",
"updated_at": null,
"intent": "core", "visibility": "listed"
}
]
}No API key, and no drafts
Not a demo
Every article on this domain was written exactly this way.
The FounderReply blog is this program running on our own workspace — researched from live search, drafted, illustrated, filed as a draft, and published by a person. Read the output before you buy the machine.
FAQ
Before you let it write for you.
What actually runs, what it costs, and what it will never do without you.
Keep reading
Ready when you are
Let it draft. You publish.
Point it at what your company does, and read the first drafts before anything goes near your website.
Free to start · Nothing publishes without you · No card required