The Pickuma Editorial Workflow: From 'This Tool Looks Interesting' to Published Review

This article describes the complete editorial workflow behind every article on Pickuma — from the moment a tool catches my attention to the moment the published article begins its life in search results, newsletters, and social media.

I am writing this because the workflow is the invisible architecture of the site. Readers see the finished article; they do not see the four-hour testing session that produced one useful benchmark, the abandoned draft that taught me I could not review that tool fairly, or the promotion sequence that determines whether an article gets read or quietly sinks. Every editorial decision here is a bet about what readers value and what the economics of content production can support.

Phase 1: Idea Sourcing and Selection

Ideas come from four sources, and I track each one in a Notion database with a status field that moves from "candidate" to "testing" to "drafting" to "published" to "rejected."

The first source is my own tool research. When I need to pick a database, a framework, or a CI platform for a project, I document the evaluation process and the result becomes a review. About 40% of articles originate this way. It is the highest-quality source because the testing motivation is genuine — I need to make a decision, and the review is a byproduct of that decision.

The second source is reader requests. About 25% of articles come from emails, newsletter replies, and GitHub Discussions posts asking "have you reviewed X?" or "can you compare X and Y?" These requests are valuable because they surface demand before I invest the testing time. I log every request in the Notion database and track how many times a tool is mentioned. When a tool crosses five requests, it moves to the front of the queue. The Supabase vs Firebase comparison was a reader request that had been mentioned 14 times before I started testing.

The third source is community signal. About 20% of articles come from monitoring what tools are being discussed on Hacker News, in developer Discord servers, and on the r/programming and r/webdev subreddits. The signal I look for is not "people are talking about this tool" but "people are asking whether this tool is actually good." Hype threads are noise; comparison requests are signal.

The remaining 15% are meta articles — workflow documentation like this one, strategy retrospectives, and transparency reports. These originate from my own editorial planning.

The most important column in my Notion idea database is "Why now." Every tool idea has a shelf life, and if I cannot articulate why reviewing it in the next 30 days matters more than reviewing it six months from now, the idea stays in the candidate column. Tools that are in the middle of a hype cycle benefit from a review that captures the current state; tools that are three years old and stable benefit from a review that can be written anytime. Timing determines relevance, and relevance determines traffic.

Phase 2: Testing and Research

Once a tool graduates from candidate to active, the testing phase begins. This phase has a fixed structure and a variable duration depending on the tool category, as described in the separate review methodology article. The testing phase produces two outputs: a set of benchmark results and a structured notes document that captures every observation — positive, negative, and neutral — in chronological order.

I use a template for the testing notes that has sections for setup experience, first-hour impressions, edge cases encountered, documentation quality notes, performance data, and overall verdict with supporting evidence. The notes are rough and unpolished; their job is to capture the raw material that will become the review.

The testing phase typically takes 15 to 30 hours spread across 5 to 14 days. I do not batch testing — I test one tool at a time so that the experience of using the tool is as close as possible to how a real developer would encounter it. Testing two similar tools simultaneously produces contaminated impressions because the second tool is always evaluated relative to the first, not on its own merits.

At the end of testing, the tool either passes into the drafting phase or gets rejected with a note explaining why. The rejection rate is approximately 35%, as detailed in the methodology article.

Phase 3: Drafting with AI Assistance

The drafting phase is where AI enters the workflow, and the division of labor is explicit. The AI (Claude, via the same API that powers several tools reviewed on this site) receives the testing notes document and generates a first draft structured against the six evaluation criteria. The prompt includes the notes, the category template, and instructions to write in my editorial voice — first person, direct, opinionated, with no hedging language.

The AI draft typically takes 3 to 5 minutes to generate and produces 2,000 to 3,500 words. I then spend 3 to 5 hours rewriting it. The AI is good at structure — organizing raw notes into a logical flow, pulling out themes, drafting comparison tables — and bad at judgment. It cannot decide whether a 12-second cold start time is "fast" in context because it has no context for what fast means in that tool category. It cannot decide whether a documentation gap is a minor annoyance or a dealbreaker because it cannot weigh the importance of different features.

The rewriting phase is where the article becomes a review, not a summary. I add the verdicts, the warnings, the Callout asides with hard-won lessons, and the specific evidence — benchmark numbers, exact error messages, configuration snippets — that the AI draft omits or approximates. I also remove any hedging language the AI inserted. The words "generally," "typically," "often," and "tends to" are deleted unless they are supported by data. A review that hedges is a review that is afraid to be wrong, and a review that is afraid to be wrong is not useful.

I have experimented with different AI drafting approaches and found that giving the AI less structure produces better first drafts. If I provide a detailed outline, the AI fills in each section dutifully and the result reads like a template. If I provide only the testing notes and a one-sentence summary of the article's thesis, the AI is forced to discover the structure itself, and the result is more organic — sometimes wrong about the structure, but wrong in interesting ways that are easier to fix than a correctly-structured boring draft.

Phase 4: Editing and Quality Control

The rewritten draft goes through three passes before it is ready to publish.

The first pass is a technical accuracy check. I re-run any benchmarks that the article cites and verify that the numbers in the draft match the current version of the tool. I check every link, every configuration snippet, and every version number. A review that recommends supabase-js@2.38.0 when the current version is 2.42.0 loses credibility with the readers who check version numbers, and those are the readers I am writing for.

The second pass is a readability edit. I read the draft aloud — not silently, aloud — and flag every sentence where I stumble or run out of breath. Long sentences that work on the page often fail when spoken, and a reader's inner voice is closer to speech than to reading. I also check for repetitive sentence structures. AI-generated drafts tend to start every paragraph with the subject of the previous paragraph, creating a monotonous rhythm that the human ear detects as "AI-written" even if the reader cannot articulate why.

The third pass is a frontmatter and metadata check. Title, description, published date, author, category, tools list, read time, and AI-assisted flag are all verified. The description specifically gets rewritten three times — it is the first thing a search visitor reads, and a good description does not summarize the article, it tells the reader what they will know after reading it.

Phase 5: Publishing Checklist

The publishing process is a 12-step checklist that has evolved through trial and error. The steps are:

1. Verify all image alt text is descriptive and accurate
2. Run bun run build locally and confirm zero errors
3. Check the article preview at three viewport widths (mobile, tablet, desktop)
4. Verify all internal links resolve to the correct URLs
5. Confirm the article renders correctly in RSS (check via local feed)
6. Add Open Graph and Twitter card images (auto-generated from the title via Astro integration)
7. Commit with message format: content: [article-slug]
8. Push to main branch, triggering Cloudflare Pages deploy
9. Verify the live article loads within 5 seconds across three geographic regions (tested via Cloudflare's speed test tool)
10. Submit the URL to Google Search Console for indexing
11. Schedule the newsletter issue in Buttondown
12. Draft social posts for Twitter, Bluesky, and Mastodon plus a Reddit cross-post if the topic fits a relevant subreddit

The entire publishing checklist takes about 30 minutes, and I do it in a single focused session with notifications disabled. Context switching during publishing produces errors — the wrong social link, the wrong newsletter subject line, a skipped verification step — and the cost of fixing those errors is higher than the cost of blocking out 30 uninterrupted minutes.

Phase 6: Promotion Sequence

The promotion sequence is timed and sequenced. The social posts go out immediately — within 15 minutes of the deploy confirming. The newsletter goes out the following morning at 9 AM Eastern, because newsletter open rates on the site's mailing list peak between 8 AM and 10 AM Eastern on weekdays based on six months of send data. Reddit cross-posts go out 24 to 48 hours after the article is live, once there is enough organic engagement to reference in the post title or comment.

I also add internal links from older articles to the new article within 24 hours of publication. This improves crawl discovery and helps new articles appear in search results faster. The link update cycle is: identify 3 to 5 older articles that are topically related, add a natural one-sentence mention with a link to the new article, commit, and deploy. This takes about 20 minutes per new article and is the single highest-ROI promotional activity I do.

The promotion sequence that has failed most consistently is the "publish and hope" approach. An article that is promoted only through the site's own channels — homepage, RSS feed, newsletter — reaches the existing audience and stops. An article where I also spend 20 minutes finding and engaging with relevant discussions on Reddit, Hacker News, and Discord reaches a new audience that compounds into backlinks, social shares, and search rankings. The difference in first-month traffic between a promoted article and an unpromoted article is approximately 4 to 1, and the gap widens over time because promoted articles earn backlinks that unpromoted articles do not.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.