How it works
AI writes the content. Software and a separate editor model check it. You decide what goes live. That is the whole arrangement, stated plainly.
Before anything is written, we gather current material on the topic: documentation, reporting, public data, product pages, standards bodies. The text of those sources is what the draft is built from. Nothing starts from a model recalling what it thinks it knows.
A writing model turns the research into an article, in your brand voice and to your content plan. Every factual sentence carries the source it came from, attached to the draft rather than pasted into the text. Its social posts come later, written from the finished, checked article.
Software then goes over the draft mechanically. It checks that each factual claim has a source attached, that quoted text appears word for word in the source it is credited to, that links resolve, that numbers and dates match the source, and that nothing on your prohibited list has slipped in.
A second model, which did not write the draft and does not see the writer reasoning, reads the draft against the sources and reports what it can and cannot confirm. Checking with the same model that wrote the piece tends to confirm the piece, so we do not do that.
What survives lands in your approval queue with its sources listed, written in your voice and ready to proof. You read it, click through to the sources if you want, and approve, request changes or reject. Nothing publishes until you approve it. If you add human review, a reviewer reads each piece against a written checklist before it reaches this queue; the decision to publish is still yours. A finished piece you are not ready to send can be saved to your library instead: it is on no schedule, and nothing in the library reaches a reader until you move it back. You also decide whether the source list appears on the published post, all of it or a selection. Requested changes go back through the same pipeline and come back for approval again.
The gate is your approvalApproved work publishes to your channels: WordPress, a hosted blog, your social accounts. A website we do not publish to directly can collect approved articles itself with a delivery key and report back what it did with each one. For an article we fetch the published page back and confirm it is live and matches what you approved. For a social post we ask the network what it did with it, because nobody can read a timeline back byte for byte and we would rather say what we checked than imply more. Either way the URL is recorded against the item.
What it looks like
Screens from a demo account for an example coffee roaster. The business and every article shown were written for the demo, and the check results shown are illustrative.
On the page
The same trust layer ships on every plan, on every post, when it goes live.
Google does not offer an instant-submit API for articles, so we keep your sitemap fresh and correct so Google finds new posts quickly on its next crawl.
Honesty
What makes the output usable is not the writing model. It is the material it writes from, and the checks that follow.
AI models write every piece. We are not going to pretend a room of journalists is doing it, and you should be suspicious of any service at this price that claims otherwise.
Research comes first so the draft is built on documents that exist. Deterministic software then verifies the parts a machine can verify: quotes, numbers, dates, links, source coverage. A second model, kept separate from the one that wrote the draft, reviews the result against those same sources.
Those checks catch a great deal and they do not catch everything. That is why the last stage is an approval. Nothing publishes without an approval of that exact version, given by you, a teammate you invite, or an assistant you have authorised to approve for you. The system is built so that a publish cannot happen without that approval on record.
When a check fails
A held piece does not quietly disappear and it does not go out regardless. It goes to your queue marked as held, with the reason attached.
From there you can send it back for a rewrite, publish it without the failing claim, or drop it. The daily schedule continues either way.
After it is live
Content decays. The six stages above end at a published post, and what happens to that post afterwards is part of the same plan rather than a service you buy on top.
For your tracked searches, the position of the piece we published is read every day. A piece that slips at least five places from a position on page one and stays down for a week of daily readings has lost something a reader was going to see.
That piece, or one that turns six months old without ever having been refreshed, is added to the next week’s plan as a refresh rather than acted on quietly. The card names the position it fell from, where it sits now and the search it is about, so you are approving a rewrite for a reason you can read.
A refresh runs through the same checks and the same approval as anything else, and when it publishes it updates the post already on your site: the same address, the same comments, the same date. It is not re-announced on your social accounts, because it has been live for months.
By default at most a fifth of each plan goes on upkeep, you can set that share anywhere between none and half, and a piece can only be refreshed again after sixty days. Anything you wrote or imported yourself is left alone.
People answer what you publish, and the inbox gathers it in one place: comments under the posts we published for you on Facebook, Instagram, Threads and LinkedIn company pages, mentions of your account on X, direct messages on Instagram, and reviews on your Google Business Profile. The other networks give our posting provider nothing to read, and some of these hand over only part of a thread, so the inbox states what it can read network by network rather than letting an empty list stand for silence.
Comments are read on the posts published in the last 30 days. Everything arrives on a schedule through the day rather than the moment it is written, because the provider sends no notice of anything new, and the inbox shows when each network was last read.
You read the thread and write the reply in PlainQuill. Nothing is sent automatically: every reply goes out because somebody on your account pressed send. It is shown as sent only once the network confirms it, and a reply the network refuses is shown as not sent, with a sentence saying why.
Your own hand
The approval gate exists so nothing a model wrote goes out under your name unread. It is not there to make you approve your own sentences.
Type a post, pick the networks, send it. Your own words on your own account, so writing it is approving it, and there is no queue step asking you to approve a sentence you typed a moment ago. Length and hashtag checks still run before anything is stored.
Hand us a page or a block of text and get one post per network written from it. A model wrote those, so they wait in your queue like everything else a model wrote. Each is checked against the source you gave: a figure, a quotation or a link that is not in it refuses that post and says which check failed.
Connect an assistant you already use over Model Context Protocol. With the access you choose, it can read your brief, plan, schedule and measured performance, read a finished piece in full, and write social posts into your queue. You make the key and can revoke it. If you choose to, it can also approve a finished piece on your behalf: a different kind of interface to the same decision you make when you click approve. You remain responsible for what publishes, exactly as when you approve a piece yourself. That takes two permissions you grant yourself, the approval area on the key and assistant approval in Settings, both off until you turn them on. It can then approve only a piece that passed every check and is not held or flagged, and no more than 30 days past its planned day (one whose day has passed is scheduled for the next open slot, never published at once), no more than a day's worth of pieces plus two (and never fewer than 40) each day, and only bound to the exact version it read. Every approval names the key in the piece history and in your daily or weekly mail, whichever your mail preference is.
You can also bring an archive you already wrote onto the blog we host: a WordPress export file or a sitemap, up to five hundred posts at a time, published with their original dates and a redirect list to put on your old host. That is content portability rather than a search migration, and it stays labelled as your writing, because we did not research, check or edit a line of it.
Setup
A WordPress site, a hosted blog on a PlainQuill subdomain or on a subdomain of your own such as blog.yourdomain.com, or any other website your developer connects with a delivery key, plus the social networks your plan includes.
We read your existing site and propose a voice, an audience and a topic set. You edit it until it is right. Everything after that follows it.
Topics, the search each article targets, formats and a schedule, proposed by us and approved by you. Production does not begin until the plan is approved, and the searches you say you want to own are read while it is being written.
Planning
A writer who does not know your business guesses. Before anything is written, the plan is built from three things that are specific to you: the pages already on your site, what people are actually typing into search engines, and what you have told us you will and will not say.
At setup we fetch your homepage and up to thirty-nine more pages in full, chosen by your sitemap's own priority, and index up to five hundred more. The index is refreshed each time a new week is planned, and your robots.txt is obeyed throughout. The fetched pages are what your brand brief is built from. The brief cannot reference a page of yours that was not actually fetched, so what it says about your business is traceable to something we read.
Topics are drawn from the public suggestion endpoints at Google, Bing and DuckDuckGo. That is which queries those engines suggest, not how many people search them, and you will not find a search volume figure anywhere on this site. Sitemaps of up to three competitors you name are read as well, for the subjects their URLs name.
A topic that overlaps a page already on your site is scored down rather than excluded, so a strong subject can still win. A topic already proposed to you is filtered out by default. If a business has worked through its research, a subject can come round again as a deliberate refresh.
A plan covers one week of publishing, Monday to Sunday. The next week’s plan is proposed on your planning day, Thursday unless you choose another, and you can have it planned early at any time once the week before it is approved, up to 12 weeks ahead of the current week. Billing is unchanged: your subscription is monthly or annual and your writing allowance is counted per calendar month; only the plan is weekly. You approve each plan before a word is written. On any item you can change the topic, the angle, the search query it targets, the notes to the writer, the format and the date. You can skip an item, or move it to another day. Each draft is then written the day before it is due, so there is time to read it.
What the planner works from: demand for the subject, your brief, the searches you have said you want to own, and what you have already published. On a blog we host it is also told which of those published subjects were read, and for a search property you have connected, whether Bing Webmaster Tools, Google Search Console or both, which of them drew impressions and clicks. Those last two are kept apart on purpose: being read and ranking are different measurements, and neither is evidence about the other. Nothing there is a forecast, and a piece is not judged at all until it has been live a week. It sees nothing you have not connected: no analytics account, no webmaster property and no ranking data arrive on their own, and where a signal is absent the planner is told nothing rather than being told a zero. Anyone whose planner learns from what ranks is describing a connection you would have had to authorise first.
No free trial
Every PlainQuill article is real work, done fresh for your business. Before anything is written, current sources are fetched and read. A writing model drafts from them in your voice, with each factual sentence tied to its source. Software then checks every quote, link, number and date against those sources, and a second model that did not write the piece reads it again and reports what it cannot confirm. A piece that fails is reworked or held back with the reason shown, never published anyway. Only then does it reach you for approval. That is several model runs, live source fetching and two layers of checking for every article, every day. It costs real money each time, far more than a single prompt to a language model.
Free trials are never really free: every business that offers one recovers the cost from its paying customers. We would rather keep that cost off our members' bills. So instead of a trial there is a refund. Ask within 7 days of a payment and you get all of it back while fewer than 7 articles have been generated since that payment. From 7 on, you get back the part that covers the articles not yet generated. Anyone who tries PlainQuill in good faith is covered, and the members who stay are not paying for everyone who only wanted something free.
See it live
PlainQuill runs on PlainQuill. Our own blog is researched, written, checked, held for approval and published by the same pipeline a customer buys, on the same schedule. It is not a screenshot, not a sample, and not a page built by hand to look good here.
Every article ends with the sources it was checked against, as links you can open and read. Judge the writing, judge the sources, and judge whether the claims in the piece are actually in the pages underneath it. That is the whole argument for this product, and it is checkable in about two minutes.
Get started
Real output on your own site, from the first week. Read the drafts, check the sources, keep what you approve. Ask within 7 days of a payment and you get all of it back while fewer than 7 articles have been generated since that payment. From 7 on, you get back the part that covers the articles not yet generated.