The Article Was Finished. The Work Wasn’t.
The article was finished. The argument had survived revision, the links were checked, and the last sentence was finally doing its job.
What remained was publishing it.
That sounds like a button. In practice, it was another piece of work: get the text into WordPress, preserve the headings and quotations, upload the images, attach their descriptions, set the featured image, supply the excerpt, categories, and tags, and choose the publication time. Then carry the article to LinkedIn and prepare the Facebook share.
A piece might have fifteen images, twenty, or more. Each has a place in the article, and each can carry alt text, a caption, and display settings. Add the links, lists, quotations, and other formatting, and publishing becomes the transfer of an entire document structure.
The decisions were already made. I was spending time introducing them to each destination separately.
I built Post Friendly, a Mac application, to shorten that part of the job. Some of it uses AI. Some of it is ordinary software. Some of it still ends with me pasting something into a browser and pressing a button.
The interesting decision was how much work to remove before that button.
Decisions that should only travel once
A finished article contains more than its paragraphs. It has a title, a destination, a publication time, a collection of images, links and formatting, and a way of being introduced to readers. Those things belong to the same piece even when the publishing tools scatter them across different screens.
The excerpt and the social introduction are a useful example. An excerpt describes the piece for someone browsing an archive or seeing a link preview. The social introduction is me addressing people who follow my work. They have different jobs. Preparing both requires judgment. Finding each one again and pasting it into the right box does not.
Post Friendly starts with a Markdown file containing the article and a structured block of publishing information. The images travel with it. The title, site, categories, tags, excerpt, publication time, and social text are supplied together. Alt text, captions, sizing, and alignment stay associated with the images they describe. Body references preserve where those images belong in the article. The featured image is one part of that package.
That arrangement makes a previously scattered set of decisions available to software. The application can read where the article goes, which image belongs at the top, and when the post should appear. I do not have to stand between the file and the destination, interpreting the same instructions again.
The useful change begins before anything gets published. The work has acquired a form that can survive a handoff.
Give the model a destination it can write for
The AI contribution is specific. Post Friendly has a format specification that can be given to the model helping prepare an article. It describes the file the application accepts: which fields exist, how images are referenced, where the article begins, and how the social text is kept separate from the excerpt.
The model can prepare that package as part of the writing workflow. Its output is something I can read and review before it becomes input to the publisher.
This does not make the content correct. An invented claim is still invented when it arrives in a neatly labeled field. A poor description of an image remains poor. Editorial review still belongs where it always did: before publication.
But after that review, the rest of the system has less interpreting to do. The title has a field. The schedule has a field. The image has a filename. Ordinary code can carry those values into the appropriate places.
Post Friendly converts the body into native WordPress blocks, uploads the images with their metadata, assigns the publishing details, and publishes or schedules the result. The article remains editable in WordPress. If a referenced image is missing, publishing is held until it is supplied.
There is no useful ambiguity in whether the required image file exists. Having a model deliberate over that question would add another source of uncertainty to a check software can perform directly.
The model helps prepare the material. The application has a defined job to do with it. The handoff between them is written down.
The platform decides where automation stops
WordPress is one destination. Social distribution introduces different interfaces and different kinds of publication.
LinkedIn’s Posts API supports posting to the feed, including what the documentation calls an article post. That name needs examining. Its article payload supplies a source URL, title, description, and thumbnail. It shares an article; it does not provide the full document-authoring interface needed to create a native long-form LinkedIn article with its body and embedded images.
For this workflow, that is a material gap. A link pointing back to WordPress and an article published inside LinkedIn are different outputs. Support for the first does not complete the second.
Facebook draws a different boundary. Publishing to a Page and publishing to a personal profile are different capabilities. The permission that let third-party applications publish as the logged-in user was removed in 2018, a change documented in the UK Competition and Markets Authority’s examination of Facebook’s platform access. A Page-publishing integration does not supply that missing personal-profile route.
These are constraints on the supported publishing workflow. Improving the article’s formatting or giving an AI a better prompt does not supply a missing interface. Automating the browser would be a separate approach, with its own maintenance and failure handling, rather than an API capability the application had overlooked.
Post Friendly works up to those boundaries. For LinkedIn, it puts the article body on the clipboard as rich text and opens the article editor. I paste it, add the title and cover image, check the result, and publish or schedule it. A separate action prepares the introductory text for the LinkedIn share.
For Facebook, the application waits until the WordPress post is live, puts the prepared introduction on the clipboard, and opens the sharing dialog for the post’s URL. I paste the text and finish the share.
The remaining interaction is real. So is the work removed before it. I arrive at the destination with the material prepared, rather than an empty editor and another reconstruction of the article ahead of me.
The clipboard is carrying content across a boundary the publishing interfaces leave open. Calling that incomplete automation describes its reach. It says nothing about how much work it has removed.
Published somewhere is still pending elsewhere
The part of Post Friendly that best explains the problem is the Pending screen.
A post can be scheduled in WordPress and ready to prepare for LinkedIn, while its Facebook share still has to wait for the page to go live. Another post can already be live with distribution work remaining. Calling both of them simply “published” would discard information I still need.
Pending keeps the article, its destination, and its remaining social actions together. The WordPress publication state is visible. The Facebook share waits for the live page. The LinkedIn preparation can happen earlier. When I have finished the work, I file the post. The application does not infer that the whole job is complete because one destination accepted it.
That last decision limits what the software claims to know. Opening a browser is a handoff. Copying text is preparation. Neither, by itself, establishes that I completed publication in the other service.
Without a place to hold those distinctions, the remaining work lands in memory. Which article was scheduled? Which version went to LinkedIn? Was the Facebook introduction prepared, or was it actually posted? An interruption turns a short publishing sequence into an exercise in reconstructing state.
Keeping unfinished work visible removes some of that reconstruction. It also lets the workflow stop honestly when the next action belongs to me.
The work outside the demonstration
There is an easy way to judge this application and miss its value: count the actions I still perform.
I still choose the topic, conduct and validate the research, develop the argument, write the article, and revise it. I decide which sources deserve trust, which images belong, and whether the piece is ready to carry my name. I also finish the social publications and decide when the distribution work is done. Authorship was never the publishing problem I set out to remove. Nor does a platform-imposed manual step make the preparation around it worthless. A demonstration measured by whether my hands ever return to the keyboard would confuse both with incompleteness.
It would miss the formatting I no longer rebuild, the metadata I no longer reenter, and the social text I no longer have to retrieve from a separate conversation. It would miss the fact that the next step is waiting with its material attached.
That is the distinction worth carrying into a larger operation. A report generator can produce an excellent report while leaving its operator to rename it, find its attachments, enter its details elsewhere, and chase its delivery. The generation can get faster without the surrounding work changing at all. Measuring only the generator makes that outcome look better than it feels to the person using it.
The time worth measuring starts before preparation and ends after distribution. It includes checking, correction, and recovering from interruptions. It includes the work that comes back when an automated step is wrong. A faster component earns its place through what happens to that whole interval.
The finished document is the output a demonstration can show. The person moving it through everything that follows is the dependency the demonstration can leave outside the frame.
Once the demonstration ends, that person still has to finish the job.
Discover more from At Ground Level
Subscribe to get the latest posts sent to your email.
