Content Creation Workflow for Solo SaaS
Build a content creation workflow for solo SaaS: copy the states, approval rules, revision paths, and weekly capacity limits from brief approval to publish.
TL;DR A draft marked finished can still have an untested example and nobody scheduled to check it. My proposed content creation workflow moves an approved brief through drafting, review, revision, approval, and publication, with explicit evidence required at each handoff. For a solo founder, I recommend separate writer, reviewer, and publisher sessions, plus a weekly work limit that includes corrections.
A document called “final” is a poor handoff to your future self. Consider this hypothetical interruption: Friday's tutorial is drafted, a support issue takes over, and Monday arrives with no record of whether the example was tested.
I want that uncertainty resolved before adding another topic to the calendar.
The useful question is not whether the document contains enough words. It is whether this version has passed the checks needed to publish it. Here is the workflow I would use when the writer, editor, and person shipping the product are all me.
Start the content creation workflow at brief approval
For this process, a content creation workflow is the set of states, decisions, and handoff records that takes an approved assignment to a checked live page. Each state needs an entry condition, an exit condition, and a next action when the work fails review.
I start after the brief is approved. If you still need to decide what belongs in that document, use the brief-first process for SEO and content writing. Here, the job is executing the assignment and deciding whether its output deserves publication.
Keep the approved brief attached throughout production. Before pulling it into active work, confirm that its product fit, competitive rationale, and place in the topic cluster still make sense. My priority is an affordable, specific contribution over a bigger volume estimate. Missing difficulty data stays unknown.
That is an intake check, not an invitation to redo research every morning. Reopen planning when new evidence challenges the assignment. Otherwise, work from the approved scope.
Copy this content creation workflow template
Use the following table as a proposed operating policy. Copy it into a document or spreadsheet beside your content board. The owner is always the founder; the role names specify which responsibility is active.
| State | Entry condition | Owner | Exit evidence and next state | Failure or return route |
|---|---|---|---|---|
| Ready | Approved brief attached; capacity available | Founder as planner | Selected assignment and work budget recorded; move to Drafting | Changed premise goes to Parked for reassessment |
| Drafting | Ready assignment selected | Founder as writer | Complete draft, checked sources, usable example, and version saved; move to Review | Missing evidence pauses drafting; unworkable scope goes to Parked |
| Review | Draft version and handoff note attached | Founder as reviewer | Acceptance checks pass and decision is logged; move to Approved | Repairable defects go to Revision; failed premise goes to Parked |
| Revision | Review lists specific defects and acceptance conditions | Founder as writer | Defects addressed in a new version with change notes; return to Review | Unresolved dependency stays blocked; failed premise goes to Parked |
| Approved | Reviewer signed off on a specific version | Founder as publisher | Preview passes publication checks; publish that version and move to Live | Content changes return to Review; formatting defects stay here until fixed |
| Live | Approved version published | Founder as publisher | Live page checked; URL, publication date, and follow-up action recorded; close production | Material content errors reopen Revision; display defects get a publishing fix |
| Parked | Assignment rejected or deliberately deferred, with reason recorded | Founder as planner | A changed premise is reassessed and brief reapproved; return to Ready | Archive if there is no defensible reason to resume |
Treat blocked as a flag on the current state. Add the missing dependency, next action, and date to revisit it. A draft waiting for a product test remains in Drafting; calling it “Review” would conceal unfinished work.
Keep Ready and Parked outside active production. Drafting, Review, Revision, Approved, and Live awaiting verification all count toward your work-in-progress limit. Release the slot only after the live check passes.
Leave a handoff record even when nobody else is involved
At each transition, record the artifact version, decision, unresolved issue, and next action. “Needs work” fails this test. “Test the email notification instructions before review” passes it.
Here is a hypothetical record for an uptime-monitoring tutorial:
Article: Configure website downtime notifications
Brief: approved assignment linked here
Current state: Revision
Artifact: draft-b
Reviewer: founder, acting as editor
Decision: revise
Defect: setup example omits the notification test
Acceptance condition: demonstrate the test and expected result
Next action: run the example, update instructions, save draft-c
Return route: Review
Publication date: tentative until approval
Resolution: test completed; expected notification received
Evidence: test log and screenshot attached to draft-c
Writer handoff: instructions updated; draft-c ready for Review
Reviewer decision: acceptance checks passed; approve draft-c only
Publisher handoff: preview checked against draft-c; publish draft-c
Live check: instructions and evidence display correctly; links work
Closure: live URL and publication date recorded; release WIP slot
The handoff keeps your content creation workflow resumable after a product interruption without reconstructing the decision from memory. Keep it short enough that you will actually update it.
Run a content approval workflow with distinct decisions
Separate drafting from review in the calendar. Finish the writing session, save the version, then return in a scheduled reviewer session. You still own both roles, but each session has a different deliverable.
The writer produces an answer. The reviewer decides whether the answer meets the approved promise. The publisher checks that the approved answer survived formatting and deployment.
Make approval depend on observable evidence
In this content approval workflow, the reviewer checks:
- Task completion: Can the intended reader do what the brief promised?
- Contribution: Is the promised example, template, demonstration, or analysis actually present and usable?
- Evidence: Have factual claims been checked against their linked sources? Are hypothetical examples clearly labeled?
- Product accuracy: Do described capabilities exist, and can the instructions be followed as written?
- Scope and connections: Does the page stay within its assignment and include the planned, relevant internal links?
Google's self-assessment guidance asks creators to examine originality, added value, trustworthiness, and factual errors. It also suggests feedback from people unaffiliated with the site. Those are useful foundations for a review, without making a checklist a ranking guarantee. See Google's guidance on helpful, reliable content.
When an explanation feels ambiguous, ask a trusted reader to attempt the task if someone is available. That is an optional check, not a fictional editor role you must hire to keep the process moving.
Distinguish revision from rejection
Revise when the assignment remains worthwhile and a defined change can satisfy it. In the hypothetical monitoring article, missing test instructions call for revision. Record the defect, the required evidence, and the return to Review.
Reject when the underlying assignment no longer holds. Suppose the brief promises an integration the hypothetical product does not offer. Better prose cannot repair that premise. Move it to Parked, record the reason, and reassess the brief before restarting.
Approve only a specific version. If you subsequently add a product claim or rewrite the example, send the changed version back through review. Approval should not silently transfer to content the reviewer never checked.
This is the central rule of the content creation workflow: a failed check changes the next action, even when the publish date is tomorrow.
Set capacity before filling the visual calendar
Here is a hypothetical weekly budget I would use as a starting experiment: five hours of content work, at most one new article started, and at most two active pieces at any time. These are proposed constraints, not industry benchmarks or a promise that an article takes five hours.
The second active slot is room for a correction or revision. It is not permission to start another fresh draft while review waits.
| Day | Proposed time budget | Role and work | Expected handoff |
|---|---|---|---|
| Monday | 30 minutes | Planner: check active work and pull an approved brief only if capacity allows | Ready to Drafting, or existing blocker gets priority |
| Tuesday | 120 minutes | Writer: draft and verify the worked example | Drafting to Review if complete |
| Wednesday | 60 minutes | Reviewer: check claims, usefulness, and scope | Review to Approved, Revision, or Parked |
| Thursday | 60 minutes | Writer and reviewer: repair defects, then reassess the new version | Revision to Review, then Approved if it passes |
| Friday | 30 minutes | Publisher: preview, publish, check live page, record follow-up | Approved to Live, or keep the publication tentative |
This gives the content creation workflow a calendar with work sessions, not just publication dates. Put the current state, next action, and tentative publishing slot on the same article card. Mark a slot committed only after approval.
If the example needs more testing than the budget allows, carry the article forward. Do not take time from review to preserve the appearance of consistency. If an urgent product issue consumes the writing block, reduce the week's publishing commitment.
When active work reaches the limit, finish, unblock, or deliberately park something before starting another assignment. A blocked article still counts until you explicitly park it and record the restart condition.
For choosing where to keep this view, see content calendar software versus a spreadsheet. Start with whichever format makes the state and next action easiest to maintain.
Keep human approval in an AI content creation workflow
In an AI content creation workflow, I recommend delegating bounded drafting and editing tasks while keeping the same acceptance checks. A generated draft enters Drafting. A generated critique is review input. Neither constitutes approval.
My suggested handoff to an AI assistant includes the approved brief, verified source notes, and the specific passage to work on. Ask it to identify missing explanations, propose a clearer sequence, or shorten repetition. Require unsupported assertions to be flagged for checking.
For a revision, give it the review defect and acceptance condition. Then inspect the changed passage and any claims introduced elsewhere. Do not mark a defect resolved because the assistant says it fixed it.
Google's guidance emphasizes accuracy, quality, relevance, and value when using generative AI. It also warns that generating many pages without adding value may violate its scaled-content-abuse policy. See Google's guidance on generative AI content.
My operating consequence is straightforward: faster drafting earns no extra publishing slots until human review capacity supports them. Keep responsibility for every published claim with the named author.
Close the loop without rewarding draft volume
Before closing a card, check the live page against the approved version. Open its links, inspect its table or example, and confirm that the reader can use the promised deliverable. Record any follow-up as a concrete action.
At the next weekly planning session, review where work stopped. Repeated evidence gaps suggest changing how you prepare drafting inputs. Repeated scope rejections suggest revisiting topic selection. Unused drafts are a reason to lower intake, not automatically raise production targets.
I am building Boomranq around that upstream decision: turning a product description into a winnability-first, 30-day SEO content calendar for small, low-authority SaaS sites. It is in development. The intended planning layer addresses what deserves your limited writing capacity and how related assignments fit together.
The content creation workflow then protects that investment through publication. For this system, success means an appropriate assignment became a useful, checked page within a work budget the founder could sustain. If a draft fails that test, the next calendar entry should name the repair.