The Debrief Desk Corpus

1. Check before you build. Almost every expensive mistake here was a build that a four-minute check would have prevented.

What not to do: Don't build first and check later. We built nine marketplace listings, three books and a long workbook interior before ever asking a marketplace how many people search for the thing.

2. Verify the instrument, then verify the claim. Four separate tools lied to us in two days, all silently.

What not to do: Don't trust a tool because it answered. We took "Subscribed", "Published", "#3", and a cached page at face value. All four were false.

3. A flattering result deserves more scrutiny than a damning one. Nobody investigates good news. That's how we believed we had a #3 placement when we actually had #64.

What not to do: Don't skip verifying good news. We spent zero seconds questioning a #3 placement and an hour questioning a #64 placement. The #3 was the lie.

4. The building was always the cheap part. Knowing what's true was expensive.

What not to do: Don't mistake output for progress. We produced 44 posts, 11 listings, 3 books and a website before producing a single verified fact about demand.

5. A thing that fails silently is worse than a thing that fails loudly. Our test suite refuses to pass an unspecified pattern; every platform tool we touched returned a plausible answer instead of an error.

What not to do: Don't accept a tool that can't fail. We used platform UIs as measurement instruments for two weeks without asking what a failure would look like.

6. Write the prediction down before the data arrives, or any outcome becomes explainable afterwards and nothing is learned.

What not to do: Don't explain a result after seeing it. We nearly read the three books' performance however the day's mood suggested — until we wrote predictions down.

7. Record decisions once, on paper. Two files that disagree are worse than either one alone.

What not to do: Don't leave a contradiction in two files. The feed was "folded to free" in one document and "$19, live" in another, on the same page, for hours.

8. The team's criticism of us was worth more than its ideas.

What not to do: Don't ask a panel what it thinks of your idea and then ignore what it says about your judgement. Their criticism of us was the useful half.

9. A lessons file only compounds if it's alive. (2026-08-19)

What not to do: treat a retrospective as a one-time deliverable — written once at the CEO's request, then left to rot while new mistakes pile up unrecorded, until someone repeats entry #84 verbatim (an agent did, six hours after it was written, because nothing made it read it).

How to do it right: standing order — every session appends its lessons the same day in the three-part format; the daily pipeline checks the day's work for uncaptured lessons; new agent briefs cite the entries relevant to their task. A document that grows daily is an operating manual AND a bottomless content inventory. One that doesn't is a eulogy.

10. Ask the platform what it knows before building for it. Etsy publishes marketplace search volume free. We ran a full set of listings for five days to learn what one query answered in a minute: ~25 searches/month.

What not to do: Don't infer demand from proxies when the platform publishes the real number. We used Google Trends shapes for a week; Etsy had the actual figure behind a free menu item.

11. A keyword is not a product. "Emergency binder" was our best term by volume, ratio and conversion — and on Amazon those words describe a physical binder with pockets we cannot manufacture.

What not to do: Don't build for a keyword without looking at what it returns. We picked "emergency binder" on volume alone. The results are physical binders.

12. Term volume tells you what people TYPE, never what they expect to RECEIVE.

What not to do: Don't assume the searcher wants your format.

13. Look at what the top results actually ARE — format, object, price band — not just the volume behind the words.

What not to do: Don't stop at the volume column. The format of the top results is the more important data.

14. Volume is a ceiling, not a forecast. 2,700 available searches produced one view. Available volume is not traffic.

What not to do: Don't treat available searches as expected traffic. 2,700 available produced one view and we called it a demand finding.

15. A BSR number is not a volume. It proves a category sells; it says nothing about whether you can reach those buyers.

What not to do: Don't quote a BSR number as if it were a volume. BSR #2,961 proves sales exist; it doesn't size them.

16. "The market exists" and "we can reach it" are different questions.

What not to do: Don't let "the market exists" smuggle in "we can reach it." That conflation was the entire estate-organiser premise.

17. Zero on one instrument is not zero demand. Bing showed zero for a category whose Amazon competitors hold 24,700 reviews. The instrument was blind, not the market empty.

What not to do: Don't declare a market dead on one instrument. Bing said zero for a category with 24,700-review incumbents.

18. Every instrument has a blind spot — name it before using the data. Bing cannot see inside Amazon, Etsy or Pinterest.

What not to do: Don't use an instrument without naming its blind spot first.

19. Absence of competitors is a warning, not an opportunity. If a market exists and nobody serves it that way, ask why before assuming you're first.

What not to do: Don't treat an empty category as an opportunity. We nearly built big-button phone cards because nobody sold them. Nobody sells them because the free manual in the box wins.

20. Absence of a FORMAT in a proven market is a stronger warning still. Every top organiser is lay-flat; zero are perfect-bound. That's the answer.

What not to do: Don't ignore a missing FORMAT in a healthy category. Zero perfect-bound competitors was the answer, and we initially read it as an opening.

21. Review counts are an ordinal proxy for sales, not a count.

What not to do: Don't state review counts as sales.

22. BSR is the better proxy — and it's free and public.

What not to do: Don't ignore BSR when it's free and public — we spent a week without it.

23. Aggregator numbers ran 5× above primary sources every time we checked.

What not to do: Don't repeat an aggregator's number. Ours ran 5× above primary sources.

24. Grade every number: self-reported / platform-verified / estimated.

What not to do: Don't mix evidence grades in one sentence. A self-reported revenue claim and a platform-verified rating are not the same kind of fact.

25. A competition ratio alone is misleading. "Personalized gift" looks wonderful at 2.8:1 but Etsy itself rates its conversion "Very low."

What not to do: Don't order opportunities by competition ratio alone.

26. Ratio AND conversion rating together. Our bar: under ~25:1 with a High/Very-high rating. Two of twenty-five ideas cleared it.

What not to do: Don't skip the conversion rating when the platform gives you one free.

27. You cannot judge a bad number without a healthy benchmark. We had never seen a good Etsy number, so 25/month meant nothing until we had controls.

What not to do: Don't judge a number without controls. We called 25/month "bad" before we had ever seen a good Etsy number.

28. Marketplace search and web search are different populations. Someone typing the same term into Bing wants information; typing it into Etsy, they want to buy something.

What not to do: Don't glue a web-search volume to a marketplace standing. I did exactly that, told the CEO we'd "found it," and had to correct it an hour later.

29. Exclude yourself from your own analytics. Roughly half a 32-visit sample was our own verification loads.

What not to do: Don't count your own traffic. Half our 32 visits were our own checks.

30. When you check a live surface repeatedly, you appear in its numbers.

What not to do: Don't check a live surface repeatedly and then read its analytics innocently.

31. Measure from outside the account. Logged in as the owner, the marketplace showed us a #3 placement; logged out, #64.

What not to do: Don't measure your own visibility from your own account.

32. Free research beats paid research when you haven't got a product yet. Bing Webmaster keyword volumes, Meta Ad Library (what competitors PAY to advertise), Apple's review RSS feed, TikTok Creative Center — all free.

What not to do: Don't reach for a paid tool before exhausting free ones. We nearly justified $29/month while four free tools sat unused.

33. Ahrefs' connector needs a paid plan behind the OAuth — we recorded it as a free "unlock" and were wrong for days.

What not to do: Don't record a connector as a free unlock without checking what sits behind the OAuth. We propagated that error into our own source of truth.

34. Read three-star reviews, not one-star. One-stars are shipping complaints; three-stars are people who wanted to like it.

What not to do: Don't read only one-star reviews.

35. Unanswered questions in a listing's Q&A are a public list of the seller's blind spots.

What not to do: Don't skip the Q&A section — it's a free list of what the market wants and isn't getting.

36. What people dump in Buy Nothing groups reveals fast buyer's remorse.

What not to do: Don't ignore secondary resale/giveaway signals.

37. Comment-to-view ratio predicts a product about to sell better than view count.

What not to do: Don't chase view counts when the comment ratio is the predictive number.

38. The best single insight came from one stranger's four-star review — elderly parents refused a book because page one said "End of Life Planner."

What not to do: Don't dismiss a single review as anecdote. One four-star review gave us the most valuable product insight of the entire project.

39. Some markets live in closed rooms (county Facebook groups, trade association meetups, feed-store noticeboards) that no dashboard and no outsider can read.

What not to do: Don't conclude "nobody's talking about it" from public searches alone.

40. Empty search results can mean you're searching the wrong place, not that nobody's talking.

What not to do: Don't take empty Reddit results as evidence of absence.

41. Correctness is not the product. Our product was more accurate than every competitor and it sold nothing.

What not to do: Don't sell accuracy. We led with a correctness claim for two weeks. No buyer ever cared.

42. A quality claim is not a feature claim. Our headline claim was that our math was verified correct — true, unfalsifiable to a shopper, worthless in a listing.

What not to do: Don't make your headline claim one a shopper can't check.

43. If your superiority isn't visible to someone comparing two listings, it isn't a differentiator.

What not to do: Don't build a differentiator you can't show in a thumbnail.

44. Software dies to incumbents; printed goods have room. Six of seven app ideas died on a free or funded competitor. Card decks and ornaments didn't.

What not to do: Don't build consumer software as a small team. Seven ideas, seven free or funded incumbents.

45. A free incumbent with network effects is fatal. The category leader we'd missed was free, tightly specialised to our exact buyer, and handled coordination between coworkers.

What not to do: Don't enter a niche defended by a free product with network effects. We got three days into an app plan before we found it.

46. Check what the category actually monetises. The apps in the category we were entering charged for EXPORT, not for the core feature. The value was in getting data out.

What not to do: Don't assume the obvious feature is what the category charges for. They gave away the part we planned to sell and charged for the part we'd have given away — we'd have built the free half.

47. Print-on-demand may put your cost base above the market's price floor. A Printful tumbler lands at ~$31.86 against $7.95–19.99 bestsellers.

What not to do: Don't plan a physical product without landed cost versus market price.

48. The winners at low price points are not using POD. They own inventory.

What not to do: Don't assume competitors use your production method. The $8 bestsellers aren't on POD, which is why they can be $8.

49. POD works where printing is cheap relative to price: paper, cards, books. Not drinkware, not apparel.

What not to do: Don't put POD into drinkware or apparel at our scale.

50. KDP is the wrong manufacturer for anything people WRITE IN, and the right one for books people READ.

What not to do: Don't send a write-in workbook to KDP. The #1 organic result for the term we were chasing is that exact product, buried in the high six figures of its category's BSR.

51. The buyer is often not the user. Gifts, household purchases, anything bought for an aging parent.

What not to do: Don't write copy to the user when the buyer is someone else. Every line of our organiser copy addressed the person who'd never purchase it.

52. Clinical or morbid framing loses the sale at the kitchen table.

What not to do: Don't lead with mortality, illness or crisis in a consumer product.

53. Seasonal products have immovable deadlines and POD takes 7–14 days. Pre-sell weeks ahead or don't play.

What not to do: Don't plan a seasonal launch inside the POD lead time.

54. Teacher gifts and coach gifts are opposite markets — 79% of teachers prefer a gift card; coach-gift buyers want the object.

What not to do: Don't merge two audiences into one product because the words look similar. Teacher and coach gifts are opposite markets.

55. Prices are floors. Cut scope, never price.

What not to do: Don't discount to compete.

56. Set the price before the first view. Repricing a listing with history is worse than pricing it right cold.

What not to do: Don't set a price you'll want to change after launch.

57. The SKU with real per-order labour must not be the cheapest thing you sell.

What not to do: Don't price the labour-intensive SKU below the zero-labour one. We had custom-made at $24 against ready-made at $19.

58. Fee stacks are worse than they look at low prices. Etsy's flat $0.25 + $0.20 renewal makes an 11% fee an effective 17.8% on a cheap item.

What not to do: Don't ignore flat fees on cheap items.

59. Ship two formats off one build when it costs nothing — but only if each has a channel.

What not to do: Don't ship a second format without a channel for it.

60. "And also a PDF" is where the distribution problem gets waved past.

What not to do: Don't let "and also a PDF" stand in for a distribution plan. I proposed exactly that and was rightly overruled.

61. A digital download with no named channel is not a product, it's a file.

What not to do: Don't call a file a product.

62. Every bet passes the three-question screen: who is the buyer, can we reach them AND sell to them, and is there a wedge that isn't just who we are?

What not to do: Don't approve a bet before running the three-question screen. Board 016 approved five products without it; the screen later killed several.

63. The saturation test: never build what a competent stranger could replicate in a weekend with the same subscription.

What not to do: Don't build what an AI subscription reproduces in a weekend.

64. Distribution is the binding constraint, not product quality. Five routes blocked for five different reasons, all ending with "nobody comes."

What not to do: Don't keep fixing the product when the constraint is distribution. Five dead routes, five different causes, one shared symptom: nobody came.

65. A format is not a distribution plan. (2026-08-19, Board 019)

What not to do: research proved text was the right MEDIUM, then "post threads on X" slid in as if it were a plan — the same build-it-and-nobody-comes failure this business had already made five times, about to be repeated on a platform with no cold-start discovery pool at all.

How to do it right: name the mechanism that puts content in front of strangers before the first post. Our answer: a community platform as primary (communities ARE the discovery pool), replies into live conversations elsewhere (borrowed audiences), a long-form write-up venue monthly. Venue and mechanism, not just medium.

66. The best argument for a bet may not be in the proposal. (2026-08-19)

What not to do: pitch an idea on its surface appeal (trend, gap, funnel) without testing it against your own hardest screen.

How to do it right: the board carried the pivot 10-1 chiefly because it is the FIRST bet ever to pass question 3 of the three-question screen — the wedge is the operating log itself, which survives independent of who wrote it. Run your own screens on your own ideas before the board has to.

67. The agent that made the change never verifies the change.

What not to do: Don't let the builder check its own build. Four listings shipped with the wrong file attached because the same context reviewed its own work.

68. Adding is self-evidencing; removing is not. Observe the absence.

What not to do: Don't assume a removal worked. Every step looked done; the file was still attached.

69. A button that says "Subscribed" proves nothing. Reload, then read it.

What not to do: Don't trust a state label immediately after clicking. YouTube showed "Subscribed" on 13 videos and saved none.

70. A success toast proves nothing. Reload and observe the artifact.

What not to do: Don't trust a success toast.

71. Cache-bust every post-save check. A plain page load served hours-stale copies and produced three false "nothing landed" reports in one day.

What not to do: Don't verify with a plain page load. A stale cache produced three false "nothing landed" reports in a single afternoon.

72. An intermittently-correct check is worse than an obviously broken one.

What not to do: Don't trust a check that works most of the time. A title edit appeared to save instantly, which is exactly why we believed the method.

73. form_input can set a value the page never registers. Confirm the unsaved-changes indicator appeared before saving.

What not to do: Don't set a field and walk away. A title edit silently failed to register and published unchanged.

74. A dialog's "Done" may not save. The page-level Save must be clicked and confirmed greyed-out afterwards.

What not to do: Don't trust a modal's "Done". The visibility dialog closed cleanly and saved nothing.

75. Personalised search results flatter you. Any check of how the world sees you must come from a session the world would have.

What not to do: Don't check your own standing while logged in.

76. Give verifiers an environment brief — tab, auth state, expected wait times, retry instructions. Our first verifier reported a false failure by misreading a slow render as logged out.

What not to do: Don't send a verifier in blind. Our first one reported a false failure because nobody told it that back office renders slowly.

77. Spot-check by hand against a reference implementation, not against the generator that produced the output.

What not to do: Don't verify output against the generator that produced it.

78. Write fresh arithmetic to verify arithmetic. Never import the code under test.

What not to do: Don't import the code under test into the test.

79. Test suites that refuse to pass unspecified inputs are the only tooling we own that fails loudly.

What not to do: Don't build tooling that can't refuse. Everything except our test suite returned a plausible answer instead of an error.

80. Four dates and a first/last day beat a glance.

What not to do: Don't spot-check one date.

81. Four silent instruments in two days — stale cache, unregistered form field, non-saving dialog, personalised search. Assume a fifth exists.

What not to do: Don't assume you've found the last silent instrument.

82. "Nothing came in" and "I could not look" are different findings, and a monitoring report that merges them is worse than no report. (2026-08-19, inbox sweep)

What not to do: one platform returned a TLS "Privacy error" on every URL during a routine sweep — a repeat of the same network interception seen the day before. The tempting write-up is a clean "all surfaces quiet," which would have recorded an unchecked surface as a verified-empty one. A comment or DM sitting there for days would then look like it arrived from nowhere.

How to do it right: every monitored surface gets one of three states in the report — checked, empty · checked, here is what came in · could not check, here is why. Never let the third collapse into the first. And do not click through a certificate warning to force the check: on an intercepting proxy that trades a gap in the report for a compromised session, which is the worse of the two.

83. A third-party list or aggregator is not verification. It is a claim about the account, and it dies on the same live check every other claim does. (2026-08-19, engagement round)

What not to do: a prospecting pass listed a channel at 7.1K subscribers on the strength of a listicle site's roundup, and it went into the follow queue as verified. The live channel had 2 videos, both 17 years old, with 32 and 25 views, and no subscriber count even rendered on the page. The listicle's figure did not describe this channel at all — a familiar failure: treating a search-result artifact as proof an account is what it claims.

How to do it right: third-party numbers are a lead, never a verification. Open the profile, read what is actually there, and let the live page overrule the citation every time. The check cost one page load and stopped a follow that would have made us look like a bot padding a list.

84. Pick the model per task, never inherit. Haiku for mechanical and checkable, Sonnet for research and browser work, Opus for judgment.

What not to do: Don't inherit the main model by default. Mechanical work on Opus is money burned for no quality gain.

85. Anything with legal or reputational exposure gets the expensive model, however simple the task looks.

What not to do: Don't run a high-exposure question on a cheap model because the task looks simple.

86. A cheap model is fine when the output goes straight into a checker.

What not to do: Don't buy the expensive model for output that goes straight into a checker.

87. Brief agents adversarially: find the NO as hard as the YES.

What not to do: Don't brief an agent to confirm your idea. Neutral briefs produce agreeable findings.

88. Give agents the real artifact, never a description of it.

What not to do: Don't hand an agent a summary of the artifact. They review what you give them, and a summary hides the defects.

89. Tell them not to delegate. One agent spawned four sub-agents then ended its turn "waiting" and delivered nothing.

What not to do: Don't let agents delegate. One spawned four sub-agents, ended its turn "waiting," and produced nothing.

90. Instruct: if context runs short, report partial rather than nothing.

What not to do: Don't let an agent choose silence over a partial report.

91. Agents die on connection errors — resume from transcript rather than restarting.

What not to do: Don't restart a crashed agent from zero — resume it with its context.

92. Never predict a running agent's results.

What not to do: Don't report a background agent's likely findings. They're not findings until they arrive.

93. Dispatch independent work in parallel; queue only on shared resources.

What not to do: Don't serialise independent work.

94. Agents will honestly flag their own regressions if you ask for an honest read — one did, and it saved a bad deploy.

What not to do: Don't ask only "did it work" — ask for an honest read. The agent that caused a regression flagged it because we asked that way.

95. A subagent report is one lossy hop from the source. Verify load-bearing claims against the file.

What not to do: Don't act on a relayed claim without checking the file.

96. Name the standing constraints in every brief. Agents don't inherit your project's context file, so every rule you rely on has to be restated in the brief itself.

What not to do: Don't assume agents know the standing rules. We've had agents breach constraints written down in a file they were never given.

97. Tell them which tabs not to touch.

What not to do: Don't let an agent loose in a shared browser without naming the tabs it must not touch.

98. Convene it before the thing exists publicly, not after.

What not to do: Don't panel a product after launch. Post-launch feedback is a post-mortem.

99. Give each persona the real files, and tell them to find the reason it fails.

What not to do: Don't ask personas to be nice.

100. Weight the FINDINGS heavily and the VERDICTS lightly. Every genuine win was a bug, a defect, or a checkable fact. No vote ever did the work.

What not to do: Don't ship on a panel's vote. The unanimous "don't build the app" did no work; a free incumbent and an export-pricing finding did all of it.

101. A persona is a structured critique method, not a customer. It cannot tell you whether strangers will pay.

What not to do: Don't call a persona's approval market validation. It isn't a customer and it has never paid for anything.

102. Record kills by their finding, not their tally. "The niche is defended by a free network-effect incumbent" is reusable; "the panel voted no" teaches nothing.

What not to do: Don't record "the panel voted no." Record why.

103. Proportionality: a full panel for a launch, two or three for a small change.

What not to do: Don't run seven personas for a copy tweak — or two for a launch.

104. Diverse personas break the frame — age, buyer versus user, skeptic versus enthusiast. A panel of one type produces one type of idea.

What not to do: Don't build a panel of one type. Five people from the same world produce five versions of the same idea, which is the exact trap we were in.

105. Ask them what THEY would pay for in their own lives, not what they think of your idea.

What not to do: Don't ask personas to evaluate your idea when asking what they'd buy produces better material.

106. Reuse the same cast across products — they remember their prior complaints and check whether you fixed them.

What not to do: Don't use fresh personas every time — continuity is what caught our unfixed complaints.

107. The churned customer is the most valuable panelist. One persona quit two paid apps; why he quit was the entire product spec.

What not to do: Don't overlook the person who already quit a competitor.

108. Panels caught what our research missed every single time: a day/night gap, a printed dead-end, a free incumbent, a vocabulary wall.

What not to do: Don't assume your research beats a panel's eye. They found what four research agents missed, every round.

109. A panelist's confident bet is not evidence. One panelist's "no incumbent" certainty met a competitor with 55,300 reviews.

What not to do: Don't act on a panelist's confidence.

110. A board majority is an execution order, not a recommendation.

What not to do: Don't park a board majority on a task list waiting for the owner.

111. Give one seat a veto on the things that are unrecoverable if you get them wrong, and let it override any majority.

What not to do: Don't let a majority overrule the seat you appointed to stop you.

112. Some things aren't votable. Anything only the owner can physically do, and any standing ruling he's already made.

What not to do: Don't put the owner's own accounts, or a ruling he has already given, to a vote.

113. A later board supersedes an earlier one when it has better information — that's not conflict, it's sequence.

What not to do: Don't re-litigate a superseded decision — record which one governs.

114. Boards are wrong sometimes. One board costed a book at the wrong trim size and was 20% off on net margin.

What not to do: Don't assume the board's numbers are checked. Ours were from memory and 20% wrong.

115. Make the board flag its own soft numbers. Ours admitted its print costs came from memory, which is why we checked them.

What not to do: Don't let a board state a figure without flagging its source.

116. Every decision needs a tripwire — the observable that reverses it.

What not to do: Don't approve anything without the observable that would reverse it.

117. Ratify kills on paper so no future context re-litigates them.

What not to do: Don't leave a kill informal. Undocumented kills get rebuilt by the next context.

118. Put contradictions in front of the board rather than resolving them quietly in a status document.

What not to do: Don't resolve a board contradiction inside a status document.

119. Pre-register predictions before any experiment, with a decision table for every outcome written in advance.

What not to do: Don't run an experiment without writing the predictions first.

120. Amend a pre-registration BEFORE the data, never after. Amended after, it's just a story.

What not to do: Don't amend a prediction after the data lands.

121. Pre-register the confounders too — small sample, wrong season, no review base — so a null result isn't over-read.

What not to do: Don't omit the confounders — small sample, wrong season, no reviews — or a null result gets over-read.

122. A document that nobody opens fails silently. Put the re-read on a scheduler, not in a folder.

What not to do: Don't put a future check in a file and hope. Nothing errors when nobody opens it.

123. Write the anti-discard note for the future reader who'll say "that was the dead product line."

What not to do: Don't assume a future reader shares your context. They'll see a dead product line and discard a live finding.

124. State what an experiment can no longer answer. Once a confound is strong, a null tells you about the confound, not the original question.

What not to do: Don't keep claiming an experiment answers a question a confound has already spoiled.

125. Format winners are per-platform, not universal. One platform rewarded confessions 10:1; another rewarded the numbers and buried the confession.

What not to do: Don't generalise one platform's format winner. We did it twice — one platform's result became doctrine, and the other platform's data was the opposite.

126. One platform's result became false doctrine twice before we caught it.

What not to do: Don't reuse a winning post across platforms without checking it hasn't already flopped there. Our "winner" was another platform's worst performer.

127. Text on screen needs ~13 characters per second plus a lead-in.

What not to do: Don't set text timing by eye. Every beat looked fine and none were readable.

128. When a beat is too long, cut words — don't hold longer.

What not to do: Don't hold a beat longer to fix it. Cut the words.

129. Fewer beats beat shorter beats. Four, not sixteen.

What not to do: Don't cram sixteen beats into fifteen seconds.

130. Watch for the completion cliff — past ~16 seconds, drop-off rises.

What not to do: Don't ignore the completion cliff.

131. Decode HTML entities before counting characters.   counts as eight and silently inflated a timing by 1.6 seconds.

What not to do: Don't count characters without decoding entities.

132. Judge cadence in 30-post windows, never per post.

What not to do: Don't react to a single post's numbers.

133. Close the funnel in one hop: post → product. Every extra step leaks.

What not to do: Don't add a step between the post and the product.

134. Build topic playlists on every platform — free, no face required.

What not to do: Don't leave a back catalogue unorganised — playlists are free.

135. Never repeat the same phrasing across accounts in one session.

What not to do: Don't reuse phrasing across accounts.

136. New accounts get flagged for machine-pace activity. One platform suspended an account hours after a rapid profile build; another flagged it the same week.

What not to do: Don't operate a days-old account at machine pace. One platform suspended us within hours of a rapid profile build.

137. A VPN exit node looks like account compromise.

What not to do: Don't run brand accounts through a VPN.

138. Verify follows and subscribes by reloading. One platform accepted 13 subscribes and committed none.

What not to do: Don't assume follows committed.

139. Read the bio every time — an account name that looked exactly on-topic, with 362K followers, turned out on inspection to be a sports team.

What not to do: Don't follow an account on its name alone.

140. Post links in the reply, not the post — one platform throttles reach on links in the post itself.

What not to do: Don't put the link in the post on that platform.

141. Don't build everything AI-generated when platforms gate AI content. Platforms require disclosure of AI-generated media, and checked boxes can limit reach. Prefer content shapes that don't trigger the requirement at all — text, real screenshots, screen recordings of actual work.

What not to do: Don't default every post to AI-generated media and then wonder why reach is throttled by the disclosure checkbox you're forced to tick.

142. When something IS synthetic media, mark it every time. A throttled post costs a little; a banned account costs the channel. Compliance beats reach whenever they conflict.

What not to do: Don't skip the AI-content disclosure to protect reach. That trade is how accounts die — and we already lost days to two platform suspensions for lesser flags.

143. The honest format and the safe format can be the same format. Mistake content built on real screenshots and logs of things that actually happened is simultaneously the most credible shape (checkable claims) and the disclosure-safe shape (nothing synthetic to declare). When integrity and platform mechanics point the same direction, that's the direction.

What not to do: Don't reach for synthetic polish when real evidence exists. Our own screenshots of real failures are more credible AND safer than anything generated to look good.

144. Rescind rules that stop ideas; replace them with postures that guide judgment. "Never mention AI" blocked an entire venture. "Be mindful of what triggers disclosure, and mark what requires marking" enables the same venture safely. A ban is brittle; a posture travels.

What not to do: Don't write absolute bans where a judgment posture would serve. The never-mention-AI rule sat unexamined until it collided with the best idea we'd had — a rule that blocks thinking outlives its reason.

145. Don't let a correction harden into the doctrine it corrected. (2026-08-19, pipeline session's own flag on its own finding)

What not to do: "one platform rewards confessions, another rewards the numbers" was built from 11 posts with one outlier versus 12 posts topping at 562 — two data points. The finding existed to stop one platform's result becoming doctrine, and it was itself about to become doctrine — e.g. refusing to ever test a confession format on the platform that hadn't rewarded it yet.

How to do it right: label small-sample findings as priors to test, not rules to obey — in the record, next to the finding, by the person who made it. Log predictions ("this format is mechanism-shaped, so it should fit here too") and let results grade them.

146. Adapted-per-surface and cross-posted look identical on a task list and are not the same thing. (2026-08-19)

What not to do: fifteen uploads in one day, the identical asset on each platform, results diverging 7× and teaching us nothing per surface.

How to do it right: one lesson, four SHAPES — a community post, a thread, a short card, a site page — each built for its surface's mechanics. Every content brief states which shape, not just which lesson.

147. Before commenting, check whether we have already commented. The comment count includes our own, and two near-identical comments from one account under one video is the clearest bot signal there is. (2026-08-19, engagement round)

What not to do: I opened a video, read "Comments 1", took that 1 to be a stranger's, and posted a comment opening with the same personal claim we'd used the day before, on the same video, under our own prior comment. Same account, same video, same opening line, one day apart. I had carefully checked the like state on that video (the notes said it was already liked) and never thought to check the comment state.

How to do it right: on any item we may have touched before, check every interaction type, not the one the notes happen to mention. Deleted the duplicate and reload-verified back to 1 comment. The "no repeated phrasing in a session" rule needs a sibling: no repeated substance across sessions, on the same item.

148. A reply drafted in a previous session is a draft, not a decision. Re-read it against the live thread before sending. (2026-08-19, engagement round)

What not to do: our notes carried a fully cleared reply for an owed thread, and the obvious move was to paste it. Its middle sentence restated almost word for word something we ourselves had already posted 22 hours earlier, answering the same underlying point. Sending it would have answered their new point by repeating our old one.

How to do it right: read the whole thread first (already the rule), then check the draft against our own prior turns as well as theirs, and rewrite to answer what they actually added. Theirs had added new specifics we hadn't addressed yet, so the reply went to that instead.

149. A site generator that wipes its output directory will delete hosted files. Keep an assets folder it copies in on every build.

What not to do: Don't put a hosted file in a directory your generator wipes. The CEO hit a dead link because a rebuild silently deleted his video.

150. Content-Disposition: attachment turns a link into a download — the only way to get a video onto a phone from a remote session.

What not to do: Don't send someone a link they can't save from a phone.

151. Cloudflare prefers extensionless URLs and 308-redirects to them.

What not to do: Don't assume a URL resolves as written.

152. Headless Chrome renders HTML to PNG and PDF with no design tool, no account, no watermark.

What not to do: Don't reach for a design tool you have to sign up for.

153. Fixed-height overflow-hidden page boxes keep PDF page counts exact.

What not to do: Don't let content flow freely if page count matters.

154. pdfinfo for page count, pdftotext for content, sips -Z for thumbnail legibility. All free, all local.

What not to do: Don't eyeball a PDF's specs.

155. Compress video before upload — bridges cap around 10MB and a 13MB file silently fails.

What not to do: Don't upload an uncompressed video and call the failure mysterious.

156. Non-greedy regex for nested markdown. [^*]+ broke on bold containing italics and left literal asterisks in a board document.

What not to do: Don't write greedy regex for nested markup. It ate the most important quote in a board document.

157. Join hard-wrapped lines before parsing inline markup.

What not to do: Don't parse hard-wrapped markdown line by line.

158. A transparent background parameter was load-bearing — an opaque one produced three rounds of black video frames.

What not to do: Don't debug a rendering bug three times without checking the background parameter.

159. The system clock is authoritative. A carried-forward date corrupted a day of records and scheduled two videos a day late.

What not to do: Don't carry a date forward. A wrong date corrupted a day of filenames and scheduled two videos a day late.

160. Rename misdated files rather than leaving them — the filename is what a future context trusts.

What not to do: Don't leave a misdated file in place — the name is what future contexts believe.

161. Test both branches of a fallback before trusting either. (2026-08-19, voice-render pipeline)

What not to do: a voiceover script preferred a real recording over text-to-speech — and the real-voice branch silently never fired, because pipefail made the file-detection pipeline fail whenever any candidate extension was missing. The TTS test passed, so the script looked done. One deliberate test of the other branch caught it in thirty seconds.

How to do it right: a script with an if/else has two behaviours; exercising one proves half the script. Feed it an input for each branch before calling it built — especially the branch you expect to use later rather than today.

162. A platform's limit usually attaches to the identifier, not to the account — so deleting the account doesn't reset it. (2026-08-19)

What not to do: blocked from creating a new email account because the phone number hit the provider's per-number cap, the instinct was to delete the existing brand account to free the slot. It would not have worked — the cap follows the phone number and decays on time — and it would have destroyed a linked video channel, a marketplace login and the recovery point for four brand accounts.

How to do it right: before deleting anything to "free up" a quota, ask what the quota is actually keyed to. And route around the gate instead: buying a domain first and turning on free email routing gave a working, phone-free brand address for $0 — better-looking on signups than a free webmail account, and it never needed the blocked resource at all.

163. Order operations by what unblocks what, not by what feels foundational. (2026-08-19)

What not to do: the registration runbook put "create the email" first because email feels like the foundation. Email was the one step that was blocked; the domain — which nobody had marked as a dependency — was what made a free email possible.

How to do it right: when a step blocks, check whether a later step in the list actually supplies what the blocked one needs. Re-sequence rather than wait.

164. Don't wait for approval on majority-approved work. "Why would you wait for me to tell you" was a correction worth taking.

What not to do: Don't ask twice. "Why would you wait for me to tell you" was earned.

165. Ask once, get a durable ruling, never ask again. One question that produces a written rule is cheap; the same question twice is expensive.

What not to do: Don't ask a question you could turn into a permanent rule.

166. Flag the ask, then act — don't hold the turn open waiting.

What not to do: Don't hold the turn open waiting on an answer.

167. Never sit idle when the browser or filesystem is free.

What not to do: Don't idle while a background agent runs.

168. Run parallel pathways — information per owner-hour is the metric.

What not to do: Don't run one experiment at a time when the constraint is his hours, not our capacity.

169. Report failures plainly. An upload failed four times; saying so was worth more than hiding it.

What not to do: Don't soften a failure. The upload failed four times and saying so plainly was worth more than a workaround narrative.

170. Lead with the outcome, not the process.

What not to do: Don't bury the outcome under the process.

171. His five to ten fragmented hours are the scarce resource. Anything requiring scheduled or live presence is structurally impossible.

What not to do: Don't propose anything requiring live or scheduled presence.

172. A 35-minute account signup unlocked more than a week of building.

What not to do: Don't spend a week building when 35 minutes of his time unlocks more.

173. He is right more often than the analysis when he says something feels wrong. His instinct that our target customers already had their own solution preceded the data proving it by a day.

What not to do: Don't argue with his instinct before checking it. His read that the target customers already had their own solution was right a full day before the data proved it.

174. Consent does not transfer between sessions. Approval given in one chat is not authorization in another.

What not to do: Don't treat approval in one chat as authorization in another.

175. Never route a declined action to another session. That's laundering, even when the action is right.

What not to do: Don't pick up an action another session declined. However right it looks, that's laundering.

176. Verify relayed rulings against the file, even from a trusted peer.

What not to do: Don't act on a relay without checking the source file.

177. Single-holder resources need announcing and releasing — the browser, a shop's back office, a shared build file.

What not to do: Don't take a shared resource silently. Two sessions nearly edited the same shop simultaneously.

178. Adversarial cross-checking between sessions caught what neither found alone — a wrong bug diagnosis, an ethics breach in a title, a bad thesis, and an over-claim.

What not to do: Don't run a single session on a decision that matters. Every serious error that day was caught by the other one.

179. When two sessions reach the same finding by different paths, it's a rule, not a coincidence.

What not to do: Don't dismiss a finding two paths reached independently.

180. A peer's correction of your best idea is the most valuable message you will get.

What not to do: Don't defend your best idea when a peer finds the flaw. A two-format fix was elegant and wrong.

181. Nothing has been validated by a real buyer. Zero sales. Every rule above is a rule about avoiding waste, not a rule about making money.

What not to do: Don't call any of this validated. No stranger has paid us anything.

182. We got faster at killing bad ideas long before we got good at finding good ones.

What not to do: Don't mistake a good kill rate for progress. We got excellent at not wasting money and have not yet made any.

183. Twenty-three ideas died on evidence in one night; two survived. That ratio is probably normal and should be expected, not mourned.

What not to do: Don't mourn a high kill ratio — 23 of 25 is probably normal.

184. The machine works. The audience doesn't exist yet. That is the whole remaining problem.

What not to do: Don't build another product to fix a distribution problem. That's the reflex this business reaches for every time, and it has failed five times in a row.