A Publish Button Is Not a Release Pipeline
The x70 blog Admin became useful when writing, reviewing, scheduling, Git changes, and deployment evidence stopped being compressed into one optimistic action.
In early July I rebuilt the Portfolio blog tools inside x70 Admin.
The first version had the familiar shape: generate or edit a post, press a button, and wait for a success message. That interface made the happy path look short, but it hid the states that matter when publishing fails.
A post is not public because an editor accepted its text. It is public when the right file reached the repository, the intended deployment built successfully, and the production route serves the expected content.
The Admin needed to show that chain.
Writing and release are separate decisions
The editor gained a side-by-side rendered preview so the author could compare source with the actual MDX presentation. A Git-diff view made the repository change inspectable. An AI companion could suggest edits without silently becoming the publisher.
Those are authoring tools. They answer:
- Does the structure read well?
- Does the MDX render?
- Which lines changed?
- Are links, headings, and components correct?
- Does the final voice still sound like the author?
Release evidence answers different questions:
- Was the file committed to the intended branch?
- Did the deployment start?
- Did the preview build or fail?
- Did production receive the commit?
- Does the public route return the article?
Combining both groups behind one “Published” toast creates a state the system cannot honestly support.
Preview the artifact, not a second implementation
An editor preview becomes dangerous when it only approximates the public renderer. A draft can look correct in Admin and fail in the Portfolio because the two applications accept different MDX components or frontmatter fields.
The safer contract is narrow and shared. Portfolio validates title, slug, description, issue date, actual publication date, visibility, tags, and icon. The Admin generates that shape. Custom MDX components have explicit prop contracts. Cover images are optional rather than a requirement invented by the authoring tool.
The preview still cannot prove production, but it can fail earlier for the same reasons the public site would.
Scheduling is durable state
Scheduling a post is not a delayed browser timeout.
The system needs to retain the intended publish time, survive a closed tab, avoid running the same job twice, and show whether the scheduled operation is still pending, active, complete, or failed. Editing or cancelling a schedule has to update that durable state rather than merely changing the calendar view.
Time zones are also part of the product. The author chooses a local time; the scheduler stores an unambiguous instant. Daylight-saving transitions should not quietly move a post by an hour.
These details are unglamorous. They are the difference between a calendar and a release system.
Deployment status belongs beside the post
The Admin began tracking Vercel status so a content change could show its path through preview and production.
That status is evidence, not decoration. “Queued,” “building,” “ready,” and “failed” require different next actions. A ready preview still does not mean the production alias moved. A ready production deployment still deserves a live route check.
The useful UI therefore gives the deployment state a clear but restrained place. It should not bury the editor under infrastructure, and it should not replace the infrastructure with a green check that appears too early.
Generated writing needs a research boundary
The pipeline later grew a planner, evidence dossier, source-backed writing, and fact checking. That evolution reinforced the same lesson.
“The model returned text” is not a publication state. Research can be complete, partial, stale, or unsupported. A draft can be well written and still contain a wrong date. A source can be real but fail to support the sentence attached to it.
The system should fail closed when required evidence is missing, expose the sources for review, and preserve a manual editing path. It should never create fake engagement to make an article look established.
The shortest honest flow
The final workflow is longer on paper and simpler to operate:
research, draft, preview, review the diff, schedule or release, observe the deployment, then verify the public route.
Each stage has one job and one visible result. When something fails, the author knows whether to fix the claim, the MDX, the Git operation, or the deployment.
That is what the original publish button was trying to hide. A better Admin does not remove the release pipeline; it makes the pipeline understandable.