AI runs 70% of my distribution. The exact stack.
TL;DR: Four months. Six AI distribution stacks. $400/month at peak. Zero signups attributable to any of them. Then I opened a spreadsheet, listed every distribution action I take in a typical week (40 rows), and labeled each one "AI can do this" or "AI cannot do this without killing the channel." 28 rows went to AI. 12 stayed mine. Output doubled, cost dropped to $19/month, and the 12 I kept are the only reason any of this converts.
The $1,600 mistake
For four months I bought every "AI distribution" promise on the timeline. Apollo for lead enrichment. Lemlist for sequences. An autonomous agent platform that prospects while you sleep. An LLM lead-scorer. An AI scheduler. A separate AI for founder voice replication.
Six stacks. $400/month at peak. Zero measurable signup lift on flowly.run, the productivity tool I ship for freelancers and solo founders.
I knew exactly when to stop. I had paid more for AI growth tools that month than I had collected in MRR from them.
The spreadsheet that fixed it
One evening I closed every dashboard and opened a spreadsheet. I listed every distribution action I had taken that week. The list ran 40 rows. Then I labeled each row with one of two tags.
- AI can do this. Scanning, scoring, drafting, scheduling, summarizing.
- AI cannot do this without killing the channel. Selection, tone, decision, customer reply, cold outreach.
28 rows ended in the first column. 12 in the second. The 12 were the only rows that had ever produced a paying customer.
I had been paying $400/month to automate the 70% of distribution work that does not convert and ignoring the 30% that does.
The 12 I cannot delegate
These will look small. They are the entire engine.
- The final 30% edit of every shipped reply.
- Picking which 1 or 2 of the daily AI-generated drafts are actually worth shipping.
- Founder positioning calls on what stance to take this month.
- Replying to any customer DM or email. Every one. Always.
- The hand-edit of the opener and closer of any long-form post.
- Cold outreach to specific named humans (creators, journalists, podcasters).
- Any reply that names another person by handle.
- Comments under my own posts.
- Any time I am positioning against a named competitor.
- Any pitch that requires reading 3+ pieces of the recipient's prior work.
- The choice of which channel to retire when a metric drops.
- The closing line of every reply. AI cannot land a closer.
Each of these failed when I delegated it. Three of them cost me actual customers.
The list that makes the rest of the stack work
The single most valuable file in my distribution setup is not a prompt. It is a one-page "never-write" list. New rules show up every week. Each rule came from reading a bad AI draft and tagging the exact line where my voice broke.
Sample lines:
- Never start a reply with "Great question."
- Never use "leverage," "unlock," "synergy," "in the trenches."
- Never end a comment with a question if the post is already over 60 words.
- Never name the product in the first 80% of any reply.
- Never quote a statistic without naming the source.
- Never use an emoji unless quoting someone else.
- Never write a sentence over 25 words in a draft for X or HN.
- Never close with "Hope this helps."
Drafts produced with this list need a 30% edit. Drafts produced without it need a 70% edit, and at that point I am writing from scratch. The never-write list is the entire economic difference between "AI saves me time" and "AI costs me time."
This is what the 2026 vocabulary now calls context engineering at indie scale. You are not prompt-engineering. You are designing the information environment around the model so it can do the mechanical 70% and stay out of the 30% that needs skin in the game.
The $19 stack
Five scripts. About 200 lines of Python total. Cron-driven. Slack and email for human approvals.
- Inbox monitor. Polls Gmail IMAP for journalist platform queries every 2 hours. Each query gets scored by Claude Haiku against my 7 stances. Ranked list lands in Slack. I read it in 90 seconds and pick 0 to 2.
- Thread scanner. Pulls HN /front and /newest, my X home, my Bluesky timeline 3x daily. Returns top 5 candidates with a one-line "why this thread" and a suggested reply angle.
- Draft pack generator. End-of-day script produces 5 ready-to-edit drafts across 5 channels using my founder voice doc plus the never-write list. I edit roughly 30% of every draft before shipping.
- Daily digest. Pulls Umami plus Flowly analytics. Emails a 9pm summary of what shipped, what landed, what converted. 2 minutes to read.
- Pitch responder. Drafts journalist replies, 60-word constraint, founder voice. Always blocks on my one-click approval. Always.
Total API spend: about $19/month. Drifts to $24 in heavy weeks. Founder hours pulled back into product work: about 14 per week.
The day I almost killed a story
The pitch responder ran on auto-send for 8 days in March. I had set a low-confidence threshold and trusted the queue. A journalist's follow-up questions to my original pitch went unread for 5 days while the script regenerated polite boilerplate. She stopped replying around message 4. The story she eventually ran skipped Flowly.
The fix that night: every outbound message blocks on my one-click approval. No exceptions. No thresholds. No "low-risk" auto-send buckets.
The cost of that 8-day mistake was one piece of press. The cost of leaving the auto-send running would have been all of them.
This is the version of context engineering nobody publishes. The rule is not "what should the model see." The rule is "what does the model see that, if it gets one thing wrong, ends a relationship the model cannot rebuild."
Where Flowly fits
The reason I noticed the 12-versus-28 split at all is that I had been timing every distribution action inside the product I ship. Flowly is a single workspace for tasks, timers, and analytics for freelancers and solo founders who are tired of running four separate apps to answer one question: where did my week actually go. I had been running my own distribution inside it, the same way a freelancer tracks billable client work. The spreadsheet that started this rebuild came out of Flowly's analytics, not my head.
The lesson generalizes past the tool. If you cannot see the line between what AI did and what you did, you cannot price either one honestly. AI runs distribution. Flowly tells me whether running it was worth the 95 minutes a day I still own.
One ask, one bet
Do the 40-action sort before you buy another AI tool. List every distribution action you take in a week. Label each row "AI can" or "AI cannot without killing the channel." Then make the second column the only thing you spend founder hours on.
Mine is 28/12. Post yours in the comments. If anyone has a real 90/10 split working, with attribution that holds up, I will rebuild my stack to match. I want to be wrong about this. So far nobody has been.
Product: flowly.run. Free tier, 14-day reverse Pro trial, no card.
Most indie hackers who buy a $400 AI growth stack are paying to automate the 30% that converts and ignoring the 70% that bores them. They have it exactly backwards.
The attribution piece is what most founders miss. AI can run a channel and look productive while contributing zero to pipeline, and you only catch it months later when you back into the actual numbers. I run a SaaS that automates social distribution, and the same pattern held internally: anything in the buyer's last few steps before conversion needs a human voice or the channel dies. Your 12-list is the more useful artifact here than the 28.
"Looks productive while contributing zero to pipeline" is the failure mode that's hardest to catch because the dashboard stays green the whole time. Output metrics are easy to generate. The lag between activity and conversion is long enough that most founders have already credited the channel before the real signal comes in.
The "human voice in the last few steps before conversion" framing matches what I see in the 12. The further a task sits from the actual decision moment, the safer it is to delegate. The closer it gets to someone deciding whether to trust you, the more it has to stay mine.
This is a test comment to verify the flow works. Thanks for sharing!
The 28/12 framing hit. I just ran my own version on AI coding tools (Claude/Cursor/Codex daily for months) and the split is almost identical — most of the "value" is in the small set of decisions you cannot delegate.
For me the killer wasn't the coding itself. It was the 30 minutes before any prompt: where do I start, what's the structure, which patterns do I reuse. The AI can write the code. It cannot decide what code is worth writing first. That decision is the 12.
Building something to handle exactly that gap right now. Engine ~90% done. The "never-write" equivalent for me turned out to be a list of decisions I had to make BEFORE the AI ever sees the project — otherwise every output drifts generic.
Question: did your 12-row list shrink over time as you got better at scoping AI, or did it stay stable? I'm betting it stayed stable. The 12 feels like a floor, not a starting point.
It stayed stable in count, shifted slightly in composition. Two tasks migrated out as I got better at writing constraints. Two new ones moved in as I found new ways to break the stack. The number held at 12 for about six months now.
Your pre-prompt 30 minutes is the exact equivalent. The decisions that have to happen before the model sees anything are the ones that determine whether the output is worth editing at all. That's not a scoping problem you can prompt your way out of — it's a judgment call about what matters, which is always yours.
The "never-write list for decisions before the AI sees the project" is the right artifact. The model cannot tell you what's worth building first. It can only execute well once someone has already decided.
This's a massive reality check for a lot of indie hackers(myself included).We love building features because coding gives us instant feedback,but SEO is the complete opposite-it's a black box that requires months of radio silence before the compound interest kicks in.Your strategy of shipping a specific,free micro-tool is exactly how you win the long-term traffic game.Once google figures out your user intent,it's basically free,highly targeted lead generation for life.Huge congrats on sticking through the flatline period,man.It definitely paid off.
Are you open to evaluating/inlcuding OSS models to optimze the inference economics, and eventually push the pricing lower? Or focusing on frontier models only for now?
Not running any OSS models currently — the $19/month spend hasn't created enough pressure to justify the ops overhead of self-hosting. The economics only flip if volume scales significantly or API pricing moves. At current spend the frontier model convenience is worth the delta.
That said the scoring and triage steps that run on Haiku are the obvious candidates if I ever do make the switch. Low stakes, high volume, tolerant of occasional misses. The voice-dependent steps stay on frontier regardless.
I didnt't meant self-hosting, tho self-hosting could also be an option, but there are quite a few serverless inference providers with openai-compatibel endpoints for OSS models,
Curious whether you’ve evaluated frontier vs OSS APIs yet from an intelligence + performance + economics perspective, or if it’s still too early
Haven't evaluated serverless OSS APIs seriously yet. At $19/month the switching cost in testing time exceeds the potential savings, so it hasn't made the priority list. The honest answer is I'd need to be at 5-10x current volume before the economics make the evaluation worth running.
If you've done the frontier vs OSS comparison on scoring and triage tasks specifically I'd be curious what you found. That's where the tradeoff is most likely to favor OSS in my stack.
The 28/12 split is exactly right, and the never-write list is brilliant, I'm stealing that. One thing I'd add: most founders try to automate the outreach before they've figured out who they're actually targeting. The right list matters more than the right email. I've watched people spend months optimizing subject lines while sending to the wrong segment entirely. Is your list-building part of the stack, or is that still a manual step before the automations kick in?
List-building is manual and stays that way deliberately. The inbox monitor scores inbound queries against my stances but the outbound target list — journalists, podcasters, creators worth reaching — gets built by hand one name at a time. That's one of the hard 12 for the same reason you named: automating outreach to the wrong segment is just faster failure. The list is the strategy. You cannot delegate the strategy to the stack that executes it.
the LinkedIn DM agent is the spicy one because most founders dont have the AE/SDR budget to A/B their outreach properly. moving from human-craft to 'agent writes the first draft, human approves before send' is the right cost curve. did you find conversion rate stayed roughly constant or did it drop as you scaled?
the 'comments under my own posts' workflow is also underrated - LinkedIn algo gives 2-3x reach to threads with author replies in the first hour, and the agent can hit that window even when youre asleep.
LinkedIn isn't in my stack — the five scripts run across HN, X, Bluesky, email, and journalist platforms. So I can't give you a real answer on DM conversion rate at scale without making something up.
The author-reply window point is real though and the same pattern exists on HN. Early replies to your own thread change the decay curve. The difference is I still write those by hand — comments under my own posts are one of the hard 12, because the first reply sets the tone for everything that follows and that's not a decision I want to delegate to a window function.
The never-write list is the part most people skip. It's the thing that makes the rest economical.
I see the same 70/30 pattern from the other side. Workflows that survive past quarter one always keep one human decision point in the chain that the AI can never touch. Full automation = output goes up, conversion goes flat or down. Every time.
The skill is figuring out which decision the AI gets to make and which one stays yours. The never-write list is basically you writing that down for distribution. Same idea works for product, for support, for hiring.
The "one human decision point the AI can never touch" framing generalizes cleanly. In distribution it's selection and tone. In support it's probably the moment where a frustrated customer needs to feel heard by a person, not processed by a system. In hiring I'd guess it's the call where you're deciding whether you trust someone with something that matters.
The never-write list is just that decision point made explicit and portable. Without it the boundary drifts and you don't notice until conversion drops.
i did a rough version of your 40-action sort after reading this. mine came out closer to 20/20 than 28/12 and i think the difference is that i'm earlier stage so more of my distribution is relationship-dependent right now. the channels where AI drafts are working for me are the ones where i already have enough surface area that the output quality matters less than the volume. the channels where i'm still building credibility from zero, AI kills it every time even with a good never-write list. curious if your split looked different at month one versus month four
Month one it was closer to 15/25 in favor of human. The channels where I had no presence yet required full manual effort just to get a read on what was landing. You cannot write a voice doc for a channel you have never shipped on. The AI tasks only became reliable after I had enough manual output to calibrate against.
Your 20/20 at early stage sounds right. The split isn't a fixed ratio, it's a function of how much surface area you've already built. AI leverages existing presence. It doesn't create it. The founders claiming 90/10 from day one are either lying about attribution or burning channels they haven't noticed are dead yet.
the 90/10 from day one point is the part worth saying louder. attribution on early stage distribution is almost always retrospective and generous. nobody's tracking channel decay in real time when they're also building the product
Exactly. The 90/10 claim almost always gets made at the peak of output volume, before the conversion lag reveals whether any of it worked. By the time the attribution comes in, the founder has moved on to the next stack and stopped counting.
"The never-write list made me think about interview workflows. When you built constraints for the draft generator, did you find that the list needed to be different per channel — or did one master list cover everything? Asking because I'm working on something where the 'channel' is the interview context (problem discovery vs. solution validation), and I'm wondering if one constraint set can hold across both or if they need to be separated."
One master list plus channel-specific addons. The master list covers voice — the rules that apply everywhere regardless of context. Channel addons cover format and tone constraints specific to that surface. X gets a sentence-length rule. HN gets a "no self-promotion in the first half" rule. They don't belong in the master list because they'd create noise on channels where they're irrelevant.
For your case I'd guess the same structure applies. Problem discovery and solution validation probably share a core constraint set — don't lead the witness, don't stack two questions, don't summarize before they've finished. The divergence is likely in what you're listening for, not how you're listening. That difference probably lives in the stance doc equivalent, not the never-write list.
That "how you listen vs what you listen for"
distinction really clicked for me.
We landed on the same structure —
one base rule set that applies to every
interview, then separate layers for
problem discovery and solution validation.
Biggest challenge has been keeping those
layers clean. How do you handle a rule
that feels universal but only really
shows up in one context?
I put it in the master list and add a context tag. Something like "never summarize before they've finished [discovery only]" keeps it in one place without polluting the validation layer. The tag is a reminder, not enforcement — the model reads the whole doc anyway, but it stops me from promoting a context-specific rule to universal status just because I wrote it during a discovery session.
The real test: if removing the rule from the master list would make a validation draft worse, it's universal. If it wouldn't, it belongs in the layer.
The tag system is elegant.
"If removing it makes validation worse, it's universal" that's a clean test. We've been separating files by session type, but tags in one master doc might be cleaner to aintain.
Going to try this.
Separate files create a maintenance problem the moment a core rule changes — you're updating two places instead of one and they'll drift apart within a month. One doc with tags keeps the source of truth singular. The tradeoff is slightly more noise per read, but the model handles that fine and you stop second-guessing which file is current.
"This is easily one of the best breakdowns on AI distribution I’ve read, Max. Your 'never-write' list framework is pure gold. Phrases like 'unlock' or 'leverage' are instant giveaways that a bot wrote it, and it completely kills the channel. As an aspiring developer building a B2B SaaS dashboard, I’m constantly looking at product discovery and how to find real pain points without sounding like an automated spam bot. Keeping that 30% human guardrail for relationship-building is a brilliant rule. Thanks for saving a lot of us from making that $400/month mistake!"
Thanks. The $400 mistake is worth making once — it's what produces the spreadsheet. Just make it faster than I did.
For B2B product discovery specifically the 30% rule gets more important, not less. The pain point conversations that actually inform a roadmap are the ones where the founder was present enough to hear what wasn't said. That part doesn't compress.
Curious what you're using for the actual outreach writing — do you use AI to personalize the emails themselves or just for targeting/scheduling? That's the piece I've found hardest to scale without sounding robotic.
Targeting only, never writing. The pitch responder drafts a structure but every outbound email to a named human gets a full hand-edit before it leaves my queue — that's one of the hard 12. The personalization that actually lands requires reading 3+ pieces of their prior work and writing a line that proves it. The model can summarize their work. It cannot write the line that shows you actually cared about it. That gap is where most cold outreach dies.
Curious about the WhatsApp piece specifically — are you using the official Business API or a third-party wrapper? Asking because I’m building in that space and the API limitations are a real constraint.
WhatsApp isn't part of my stack — nothing in the five scripts touches it. The channels I'm running are HN, X, Bluesky, email, and journalist platforms. If you're building in that space the API limitation question is real but not one I can answer from experience. Worth asking in a thread where someone's actually shipping on it.
It's interesting that you found the tasks you kept in-house were the reason for conversions, which suggests that the human touch is still essential for driving meaningful engagement.
Yes, and the direction of causation matters. It's not that human touch adds warmth on top of a working funnel. It's that the 12 human tasks are the funnel. The 28 AI tasks are infrastructure that makes the 12 sustainable at volume. Remove the AI and I'm too slow. Remove the 12 and there's nothing to be fast about.
The 70% number is the part most builders quote but never break down. Which slice is the most fragile — content gen, channel routing, or actually getting clicks?
Channel routing. Content gen fails loudly — you read a bad draft and catch it. Click attribution fails slowly — you notice after weeks that a channel stopped converting. Channel routing fails silently in the middle: you keep publishing to a dead channel because the numbers look plausible until they don't. That's the one I'd watch most carefully.
"Silent failure in the middle" is the exact phrase I've been looking for. How do you actually catch it without waiting weeks? Cohort comparison across channels, or something more direct?
Weekly ratio, not raw numbers. I track click-through per post shipped on each channel. The absolute number drifts with volume so it masks decay. The ratio surfaces it in 7-10 days instead of 4-6 weeks.
The second signal is reply quality, not reply count. A channel dying shows up as replies getting shallower before they drop in volume. Harder to automate but faster than waiting for the numbers to fall off a cliff.
The journalist follow-up story is the part that made this click for me.
Most AI distribution posts make it sound like the goal is to automate more and more until the founder is barely involved. This is almost the opposite: automate the boring parts, but protect anything that can damage trust if it’s even slightly wrong.
The “what can the model get wrong that I can’t easily rebuild?” filter is probably the most useful takeaway here.
I haven’t done the full 40-row audit yet, but my guess is my split is nowhere near as clean as 28/12. I’m probably still spending founder time on some mechanical stuff while letting AI get too close to a few relationship-heavy parts.
"What can the model get wrong that I can't easily rebuild" is the right filter and I wish I had named it that explicitly in the post. The journalist story is the cleanest example because the cost was invisible for 5 days and permanent after day 8. No dashboard flagged it.
The messy split being the starting point is fine — the audit is useful precisely because most founders don't know their actual number before they run it. The mechanical stuff staying human is just wasted time, recoverable. The relationship-heavy parts being too close to AI is the one worth fixing first.
The “28 AI tasks / 12 human tasks” framework is probably the clearest explanation of practical AI distribution I’ve seen.
Most people are trying to automate persuasion, judgment, and relationship-building — the exact parts that compound because they’re human. AI is incredible at reducing friction around research, drafting, scanning, and summarizing, but the final layer of taste, positioning, and trust still belongs to the founder.
The “never-write list” insight is especially underrated. Context engineering isn’t just prompts — it’s building constraints that protect voice and credibility.
Also loved this line:
“What does the model see that, if it gets one thing wrong, ends a relationship the model cannot rebuild.”
That’s the real boundary.
"Automating persuasion, judgment, and relationship-building" is exactly the mistake — and it's an easy one to make because those tasks feel like the high-leverage ones worth optimizing. They are high-leverage, which is precisely why delegating them is so costly when it goes wrong.
The compounding point is the one I'd underline. Mechanical tasks automated well save linear time. Human tasks done consistently build something that accumulates. The 12 I kept aren't just the ones that convert — they're the ones that make the next conversion easier than the last one.
It's interesting that you found the tasks you kept in-house were the reason for conversions, which suggests that the human touch is still essential for driving meaningful engagement. I'd love to know more about the types of tasks that fell into the "AI cannot do this without killing the channel" category, as this could provide valuable insight into where AI can complement human effort without replacing it. What specific characteristics or requirements did these tasks have that made them unsuitable for automation?
The common thread: the recipient could verify a real person was behind it in two clicks. Cold outreach to named journalists, replies mentioning someone by handle, comments under my own posts. All of them have a human on the other end who notices if nobody's home. That's the characteristic — not complexity, not length, but verifiability.
the 28/12 split is the real lesson. we see the same pattern building agent systems for clients:
what stays human is consistent: judgment under partial info about a specific person. dm tone, the "is this worth shipping" call, opener of cold outreach. AI cold-starts on fresh context; senior judgment lives there.
re-run the audit every 6 months tho, the line moves as AI gets stronger 🤷
The task-type breakdown is the useful addition here — the split isn't a fixed number, it's a function of how judgment-heavy the work is. Bug fix sprint being 80% human because reading existing code requires knowing what the original author was thinking is exactly the pattern. Fresh context is the constraint; the model has none of it.
The 6-month re-audit point matches what I said to someone else in this thread — my split was 22/18 eight months ago, now 28/12, not because I automated more but because better constraints made previously-undelegatable tasks delegatable. The line moves, but so far only in one direction.
The 40-row sort is applied BI — you built an attribution model for your own distribution, and the signal is cleaner than most startup analytics dashboards I've seen.
The daily digest piece is worth expanding. Pulling Umami + Flowly into a 9pm email is smart, but the next useful step is a 7-day rolling column alongside the daily number. Single-day snapshots often surface the wrong winner because distribution has a lag between action and conversion. A reply you sent Tuesday might show up as a signup Friday, and without the rolling window it looks like Friday's activity drove it.
The 28/12 framing is the same principle I'd give any startup building their first data stack: instrument the inputs that have causal influence on outcomes, not just the ones that are easy to measure. You've been doing it instinctively — the spreadsheet just made it visible.
The 7-day rolling column is the right fix and I haven't built it yet. You're describing exactly the attribution hole I paper over with "organic distribution has a 30-90 day lag" — which is true, but it's also a convenient excuse not to instrument it better. A rolling window would at least surface whether Tuesday's reply or Thursday's thread drove Friday's signup, even if it can't close the loop on the long-tail direct visits.
The "instrument inputs with causal influence" framing is sharper than how I had it. I fell into the easy-to-measure trap for the first two months — tracking post count and engagement because Umami makes that effortless, ignoring the harder question of which specific action in which channel preceded a conversion. The spreadsheet made the input list visible. The rolling window would make the lag visible. Those are two different problems and I've only solved the first one.
Adding it to the next digest iteration. Appreciate the specific build note rather than just "attribution is hard."
That distinction — making inputs visible vs. making the lag visible — is worth its own post. Most founders collapse them into "attribution is hard" and stop there. The rolling window is actually a solvable engineering problem (a date spine + window function in SQL does most of it). The lag problem is harder because it requires committing to a theory of how your content causes signups — something Umami can surface data for but can't decide for you. Worth building the rolling column first just to stop letting the lag excuse block the easier fix.
The date spine point is the nudge I needed — I was treating the rolling window as an analytics problem when it's mostly a build problem with a known solution. The harder part you're naming is the theory of causation, which no tool resolves because it requires a bet on which touchpoints matter. Umami surfaces the data. The theory is still mine to own. Building the window first is the right sequence — removes the easy excuse before confronting the harder question.
Exactly — the date spine is just plumbing, but it removes the excuse that keeps you stuck in "we can't measure this yet." Once that window is in place, the causation question becomes unavoidable in a productive way. That's where the real work is, and it sounds like you're now positioned to actually do it.
Agreed. The plumbing removes the excuse, the excuse was the only thing making the causation question feel optional. Once the window is built the theory becomes the next blocker, which is the right blocker to have.
At this moment in time distribution is harder to achieve than just building the product, you can build the best tool but if no one sees it, it becomes the world's best kept secret, very efficient distribution system
Fully agree — and I'd go further: distribution is now the harder engineering problem. Building is tractable. Getting seen by the right person at the right moment is not. The "world's best kept secret" failure mode has killed more good products than bad code ever has.
The never-write list is the thing that clicked for me here. I've been building Markey (an AI launch tool) and ran into the exact same thing - the AI outputs that flopped were the ones where I skipped the constraint step. The $19 vs $400 story is also a good reminder that output volume isn't the metric. Thanks for sharing the actual scripts breakdown, that's rare.
The constraint step being skippable is the exact failure mode — it feels optional until you've read enough flat drafts to price what skipping it actually costs. Output volume is the metric that feels like progress. Constraint quality is the metric that produces it. Glad the scripts breakdown was useful; most posts stop at the framework and leave out the part you can actually build from.
The never-write list is the real differentiator here. Most AI distribution fails because of voice inconsistency, not technical execution. The constraint-driven approach you take keeps AI from drifting into generic marketing language. One addition: track which drafts pass your manual gate vs which get rejected and why. That rejection data is better training material than any fine-tuning dataset. Curious if you've built any feedback loop from those manual decisions back into the prompt templates.
Haven't built a formal feedback loop yet, but the rejection tracking point is the right call. Right now new never-write rules show up when I read a bad draft and tag the exact line where the voice broke — which is manual and lossy. Turning rejections into structured data and routing the patterns back into the prompt header is the obvious next step I've been doing informally. The rejection log as training signal is a better frame than fine-tuning because it stays interpretable — you can read the list and know why each rule exists. Adding a rejection reason field to the approval queue this week.
The 'AI can do this without killing the channel' framework is the real insight. Most founders fail at AI distribution because they let AI write the final draft and ship it. The leverage shows up when AI does retrieval, ranking, and first drafts, and you handle the final 20% that signals you actually wrote it. Running SocialPost.ai gave me the same lesson on the product side: customers will use AI for the 80%, but they want full control on the moments that touch their voice or their brand. Curious what happened the times you did let AI ship without edits.
The unedited weeks are the clearest data I have. Engagement held roughly flat — likes, upvotes, replies looked normal. Signups dropped. The posts that convert aren't the ones that sound correct, they're the ones where a specific line lands as something only someone with skin in the game would write. Unedited drafts pass the skimming test and fail the "do I trust this person" test. The audience that converts is exactly the audience that can tell the difference.
The AI can draft this, never send this category feels like the missing piece in most AI workflow discussions. A lot of founders confuse speed with trust, but the trust layer is usually the actual business.
"Confusing speed with trust" is the cleanest summary of the auto-send failure mode I've read. The journalist story is exactly that mistake. The script was fast. The relationship was slow. I optimized for the wrong variable.
The draft-never-send bucket is also where I'd put anything going to someone with an audience larger than mine. The asymmetry is too high. One flat reply to the right person costs more than a month of volume.
I tried this for two months across a smaller stack — three tools instead of six — and burned roughly $140 before reaching the same audit you describe.
The two specific rows that wouldn't move from "AI cannot do this" for me, building a tiny iOS memo app solo: replies to Reddit comments where the OP is venting (the AI versions read flat even after voice cloning), and answering iPhone-specific questions in Apple subs where the second-best wording gets downvoted immediately. Everything I tried to push those into AI hands cost me karma faster than it bought reach.
What I'd add to your framework: a third bucket — "AI can draft this, never send this." That bucket quietly grew the longer I ran it. Curious whether the 12 you kept stayed stable, or whether some drifted into the AI column over time?
The third bucket is the right addition and I should have named it explicitly. "AI can draft, never send" is where my cold outreach to named journalists lives. The draft is useful as a structure check. It never ships as written. Calling it a two-column sort undersells the actual workflow.
The Reddit venting reply problem is one I recognize. The model produces the correct sentiment but misses the specific weight of the moment. It reads as someone who understood the complaint intellectually but wasn't in the room. That gap is unrecoverable with prompting in my experience — it's not a constraint problem, it's a presence problem.
On the 12 staying stable: some drifted, mostly in one direction. Two tasks that were firmly mine a year ago moved into the AI column after I got precise enough with constraints. None moved the other way. The tasks that stayed human got more entrenched over time, not less — because the cost of getting them wrong became clearer the longer I ran the stack.
This makes a lot of sense. I’ve seen good products fail just because they were too slow to reach users.
Automation definitely helps, but I feel the real challenge is keeping it personal.
How do you balance that?
The 12 tasks I kept are the entire answer to that. Personalization does not survive delegation — it just looks like personalization until the person on the other end clicks through and realizes nobody is home.
The balance I landed on: automate everything where the output is evaluated on accuracy. Keep everything where the output is evaluated on whether it sounds like a specific human who has read their work.
ran a similar audit, ended up with 9 tasks that had to stay mine. anything where the person could verify me in two clicks stayed human. the $400 for zero lift phase is almost universal.
The "verify me in two clicks" framing is sharper than how I had it. I was thinking about it as voice fidelity. You've named the actual risk: not that it sounds wrong, but that someone can check.
The $400 zero-lift phase being near-universal is the part I wish someone had told me before month one. Would not have stopped me but would have shortened it.
yeah, had them merged too. voice fidelity's upstream - the lookup is the gate. you can nail the tone and still lose someone who actually checks.
Exactly right. Voice fidelity is table stakes — the lookup is the actual test. A journalist or podcaster who likes your reply and checks your profile in 10 seconds will see whether the last 20 posts sound like the same person. If they don't, the reply didn't matter.
The inbox monitor row on my list looked similar. We built goffer.ai for newsletter writers and policy teams - it scans Congressional activity for keyword matches (bill introduced, committee vote, floor action) and sends alerts to Gmail or SMS.
The 28 part: scanning congress.gov, matching keywords, formatting the alert. Runs unattended.
The 12 part: deciding which keywords actually matter for your readers. We learned this early - users with 50 generic keywords got noise. Users with 5 precise ones got signals they wrote entire newsletters around.
The keyword selection cannot be delegated. It requires knowing your audience and your editorial angle. Same principle as your never-write list - the constraint lives upstream of the model, not inside it.
"The constraint lives upstream of the model, not inside it" is the cleaner formulation of what I was trying to say. Stealing that line.
The 50-versus-5 keywords finding is the exact failure mode I see when founders first build anything like this. More inputs feels like more coverage. It's just noise with extra steps. The model cannot tell you which keywords matter for your readers. It can only score against the ones you already chose correctly.
The dependency I'd add: keyword selection isn't a one-time decision. When the policy landscape shifts, a keyword that was low-signal for months becomes load-bearing overnight. That upstream call has to stay human — and it probably won't feel like a decision when it happens. It'll feel like "this alert seems more important this week." Which is exactly the judgment the model cannot replicate.
Read this with my coffee growing cold. The 28/12 ratio is almost
exactly what I land on every time I do the same exercise — and the
auto-send story is the specific bullet I dodged twice this year,
both times by luck.
The row I'd add to "cannot delegate": choosing which old thread to
revive vs let die. The model finds candidates fine. It's terrible at
the "is this still relevant 8 days later" call. I lost a real
conversation last month because a draft sat in my approval queue too
long — by the time I sent the polished reply, it landed as a thread
necromancer.
Your never-write list is the part of this post I keep re-reading.
The rule I keep adding to mine: "never write a sentence that combines
two strong claims into one." The model loves rhetorical stacking and
you can smell it the second you read it back.
One real question — is the 30% edit measured in words changed, or in
time spent vs writing from scratch? Those drift apart fast for me on
long-form.
The thread necromancer problem is real and I don't have a clean fix for it. My queue has a 48-hour expiry now — anything older gets auto-archived and I re-evaluate from scratch rather than ship a stale draft. It creates some waste but it's better than the alternative you described.
"Never write a sentence that combines two strong claims into one" is going straight into my list. You're right that you can smell it immediately. The model stacks claims because stacking sounds authoritative. It reads as generated the second you say it out loud.
On the 30% question: time, not words. Words changed is a bad proxy because the most important edits are often one line — the opener or the closer — and those take 30 seconds to change but represent 80% of the value. When I tracked words changed I convinced myself drafts were good that weren't. Time spent relative to writing from scratch is the honest number. For long-form specifically, I've found the 30% estimate holds on replies and short posts and falls apart completely on anything over 600 words, where it drifts closer to 50%.
Matches what I hit doing long-form. The tough sections for me were the ones with code blocks — the model gets the snippets right but the prose between them sounds like a tutorial generator, not a story. I ended up rewriting that connective stuff almost every time. Those sections easily blew past 50%. Pure prose chapters were closer to 35-40%, much nearer your number. The 48-hour expiry is a discipline I should adopt. My queue right now is more "whenever I get to it" which is exactly the failure mode you described. Curious if 48 hours works across the board or if some channels need it shorter — feels like X reactions probably want a 4-6 hour window before they stop being relevant.
48 hours is not universal. X is closer to 4-6 hours for anything reply-shaped — after that the thread has moved and your comment lands in a graveyard. HN is more forgiving, sometimes 24 hours, depending on whether the thread is still active on /front. Long-form comment threads on IH or similar can survive 48 hours because the decay curve is slower.
The code-block prose problem is one I haven't solved cleanly either. The connective tissue between technical sections is where the tutorial voice leaks in hardest. My current fix is a specific line in the never-write list: "never use 'now let's' or 'next we'll' as a transition." It catches the worst of it. The rest I still rewrite by hand.
"Never use now let's or next we'll" is going straight into my list— that's exactly the failure mode I was rewriting around without naming. Stealing it. The X 4-6h matches what I was suspecting. The lesson I'm taking — a late reply on a fast channel is worse than no reply at all. It signals you weren't paying attention.
Appreciated this whole exchange.
Same. The channel-specific decay curves are the part most queue systems ignore entirely — one expiry rule across all channels is almost as bad as no rule. The "late reply signals you weren't paying attention" framing is exactly right and I hadn't named it that cleanly before this thread.
The never-write list is the most underrated part of this. Everyone talks about prompts. Nobody talks about constraints. But constraints are what separate a draft that ships in 30% edit time versus one that has to be rebuilt from scratch.
The 28/12 split also maps to something I've noticed: AI excels at work where the output is reviewable in 10 seconds. If it takes longer to evaluate whether the AI did it right than to just do it yourself, you haven't gained time — you've just moved the bottleneck.
The March journalist story is the real lesson buried in here. Auto-send is never low-risk. One relationship lost to boilerplate is never recoverable. The human approval gate isn't friction — it's the product.
"If it takes longer to evaluate whether the AI did it right than to just do it yourself, you haven't gained time — you've just moved the bottleneck." That's the cleaner version of the test I was running implicitly and never wrote down. Adding it to the doc.
The 10-second reviewability threshold also explains why the never-write list matters more than the prompt. A good prompt makes the output better. A good constraint list makes the output faster to evaluate. Those are different problems and most people only solve the first one.
"The human approval gate isn't friction — it's the product" is exactly right and the part that took me the longest to internalize. I kept framing the approval step as overhead I'd eventually automate away. The journalist story is what made it permanent.
The never-write list is quietly the most important part of this post. Everyone obsesses over prompts and model selection but the constraint layer is where the actual time savings live. Without it you're just generating plausible-sounding text that still needs a full rewrite.
We hit the same wall building aisa.to (AI skills assessment through conversation). Early on we tried to let the model handle everything in the assessment flow. Turns out about 30% of the conversation requires judgment calls the model consistently gets wrong: when to push back on a vague answer, when someone is actually demonstrating skill vs just repeating something they read, when to change direction entirely. The rest is mechanical and AI handles it fine.
Your 28/12 split rings true. Most founders I talk to claim something closer to 90/10 but when you ask them to show attribution, the number falls apart fast. The honest split is always uglier than the vibes-based one.
One thing worth adding: the split isn't static. Tasks that were firmly in my "AI cannot" column six months ago have migrated over as I got better at writing constraints. The spreadsheet exercise is worth repeating quarterly.
The assessment case is a sharper version of the problem than distribution. In distribution a bad judgment call costs you a comment. In skills assessment a bad judgment call corrupts the actual output the product is selling. The 30% that stays human is load-bearing in a way mine isn't.
The 90/10 claim falling apart under attribution pressure is the most reliable pattern in these threads. The vibes-based number is always the marketing version. The spreadsheet number is always uglier and always more useful.
The quarterly repeat point is the one I'd underline. My split was 22/18 eight months ago. It's 28/12 now. Not because I automated more but because I got better at writing constraints that made previously-undelegatable tasks delegatable. The spreadsheet isn't a one-time audit, it's a calibration tool. Worth saying that more explicitly in the post.
Great breakdown. If you were starting over from scratch, what's the one thing you'd do earlier?
Written the never-write list. I had a voice doc for months that only said what to do. Drafts were 70% wrong. The day I added the never-write section, drafts became 70% right. That one page is worth more than any model upgrade. Start it on day one.
Can you make this concrete with one real example? I'd find it way more useful to see exactly what the AI does start to finish for a single HN comment that ships, including where you step in. The high-level pipeline makes sense, it's the actual handoffs I can't picture.
Cron at 09:00, 13:00, 17:00 pulls top 30 threads from HN /front and /newest. Haiku scores each thread 0-10 for relevance to my 7 stances and returns the top 5 with a one-line "why this thread" and a suggested reply angle. I read the 5 in 60 seconds and pick 1. Sonnet then generates 2 draft comments for that thread using my voice doc plus the thread context plus the chosen stance. I read both drafts, pick the better one, hand-edit the opener (always), hand-edit the closer (always), ship.
AI did about 4 minutes of work across the whole flow. I did about 6. The comment ships in 10 total minutes versus 25-30 if I were doing it fully manual. Multiply that 60% time saving across 5 channels and that is where the 14 hours per week of pulled-back founder time comes from.
Fair pushback. Most distribution threads stop at impressions and engagement because signups are where attribution gets messy fast.
In our case, yes — we do track signups, but I’d be lying if I said organic attribution is perfectly clean. The honest version is usually a mix of:
branded search lift over time
What we’ve consistently seen is that distribution compounds when the content is tightly connected to a problem the product actually solves. Random viral reach rarely converts. Repeated credibility in the same niche does.
One example: a focused distribution loop around operational pain points produced lower engagement than broad thought-leadership posts, but converted materially better because the audience intent was higher.
So I’d separate “content performance” from “business performance.” High-output content can create awareness, but signups usually come from:
And honestly, there are still gaps. Dark social, team shares, screenshots, Slack forwards, AI summaries, and word-of-mouth make clean funnels almost impossible now.
The mistake is pretending attribution is precise. The useful question is whether distribution is creating measurable business lift over time, even if the exact path is fuzzy.
Cron at 09:00, 13:00, 17:00 pulls top 30 threads from HN /front and /newest. Haiku scores each thread 0-10 for relevance to my 7 stances and returns the top 5 with a one-line "why this thread" and a suggested reply angle. I read the 5 in 60 seconds and pick 1. Sonnet then generates 2 draft comments for that thread using my voice doc plus the thread context plus the chosen stance. I read both drafts, pick the better one, hand-edit the opener (always), hand-edit the closer (always), ship.
AI did about 4 minutes of work across the whole flow. I did about 6. The comment ships in 10 total minutes versus 25-30 if I were doing it fully manual. Multiply that 60% time saving across 5 channels and that is where the 14 hours per week of pulled-back founder time comes from.
Genuine pushback here. Every distribution post I read measures output volume and engagement, then quietly assumes that becomes signups. Have you actually tied this stack to real signups, or is it outputs and vibes? If you have numbers I'd love to see how you attribute them, because organic attribution is notoriously messy and I'd rather hear the honest version with the gaps than a tidy funnel chart.
Both, honestly. Signups are the lagging metric I care about most and the one most resistant to clean attribution because organic distribution has a 30 to 90 day delay between first touch and conversion.
What I can measure: weekly output count, channel-level engagement (replies, upvotes, click-throughs to flowly.run), referrer reports from Umami, signup rate from each referrer over a 30-day window. The "hybrid-output conversion roughly 10x AI-only conversion" split I implied in the post comes from looking at click-to-signup on referrers I can tag and from comparing drafts shipped at 30% edit versus drafts shipped at 0% edit during one bad week.
What I cannot measure: the long-tail compound effect of consistent presence. A founder who saw 6 of my HN comments over 3 months and then signed up via a direct visit shows up as "organic, no referrer." That is the bulk of my signups. I assume the volume helps. The numbers agree but do not prove it.
If you build this stack, set up Umami or PostHog before you start, tag every link with UTM params, and accept that you will be flying half-blind on the long tail. That is the nature of organic distribution at this scale. Anyone selling you cleaner attribution is selling you fiction.
Really want to try this but I'm not a developer, no Python and definitely no Playwright. Is there a realistic version of this for non-technical founders, or is that a hard requirement? Would love to know where someone like me should even start.
Start with two scripts, not five. The two with the highest leverage are (1) a daily analytics digest that summarizes your traffic into one email and (2) a draft pack generator for one channel only. Pick the channel that costs you the most time per output.
You can build both in a weekend with Claude as your pair. The non-technical version is the same flow in n8n or Make.com. The pipeline matters more than the runtime. The hardest part is the voice doc, and that one you write by hand regardless.
The journalist failure made me wince, so thanks for writing it up instead of pretending the stack just works. That's the useful part of these posts. Has anything else broken in a similar way since you patched it? Trying to get a realistic sense of the failure surface before I build my own version.
Yes, smaller scars.
One: the thread scanner once recommended a Bluesky thread for engagement. I shipped a reply. The thread turned out to be a quote-post of a tragedy. I deleted within 4 minutes but a few people saw it. Now the scanner has a "sensitive content" pre-flag and the day's top 5 candidates skip anything tagged.
Two: the draft pack generator produced a reply that paraphrased a competitor's marketing copy almost word-for-word. I caught it because the closer was uncharacteristically smooth. The fix was a new line in the never-write list: never use any phrase that sounds like it was already used by a SaaS landing page.
Three: the inbox monitor once scored a podcast booking request as 2/10 because the founder voice doc did not include a "podcast guesting" stance. I missed the email. The fix was adding an eighth stance, then immediately collapsing it back to seven by merging two adjacent ones.
The pattern is the same: every failure produced one line of context engineering. The stack is mostly the accumulated failures of the founder, written down.
Has any platform actually flagged or deboosted your AI-assisted posts? That's honestly the one thing stopping me from setting this up.
Not that I can detect. The 2026 detection heuristics target unedited LLM output with characteristic structural tells (em dash density, three-bullet conclusions, "Here is the thing about X" openers). The 30% human edit removes those tells. The posts that get traction are always the ones where my edit pass adds a number, a specific personal example, or a contrarian line the model did not generate.
Maybe I missed it, but you reference these 7 stances over and over and never actually show what one looks like. That's genuinely the part I clicked through for. Can you break down the format of a single entry? And I'm curious why 7 specifically, since that feels oddly precise compared to just picking 5 or 10.
The doc is one page. Seven entries. Each entry has the same four fields.
Name. Two to four words. Mine include "single-tool stack undervalued," "AI removed design blocker not speed," "distribution is a feedback-signal problem," "founder voice is the asset."
First sentence template. The opener I have used enough times that I can identify the stance from the first 8 words.
Three bullets. The atomic claims this stance makes. Each bullet must be a complete idea, not a header.
One example reply that nailed it. A real comment or post of mine, copied verbatim. The example is the calibration target for the model.
The stance doc plus the never-write list is the entire context the LLM gets per task. Total prompt header: about 1,200 tokens. Per-request input adds another 300-800 depending on channel. Output 200-400. Cheap.
The reason 7 works and 15 does not: I cannot hold 15 stances in my head consistently. The model can. But the human approval step at the end will fail if I cannot recognize my own stance in the draft. Seven is the ceiling of what I can recognize at a glance.
Solid post, but I'm stuck on this part. I've used Apollo and Lemlist and they already handle outreach fine, so why hand-roll Python scripts for it? Genuinely asking what they were missing, because maintaining your own stack sounds like real overhead for a solo founder.
I did. For 4 months. They failed for the same reason most "AI distribution" SaaS products fail at indie scale: they are optimized for outbound B2B SDR workflows where the slow 30% is "personalized intro line" and the bulk 70% is "send 100 emails per day." My slow 30% is "decide whether this is worth shipping at all," which no SaaS exposes as a step. Those tools assume you already decided. I had not.
The Python stack is about 200 lines total across the 5 scripts. It gives me a seam where the human picks live. SaaS tools paper over that seam and charge for it. The seam is the entire product.
Nice writeup. Curious about the model side, are you running one model across the whole pipeline or swapping per step? And if you mix them, what made you land on that split instead of just defaulting to one provider?
Haiku for the scanning and scoring steps where I am triaging 50-100 candidates per day. Throughput and cost matter more than voice there. GPT-4o for short-form draft generation (replies, posts, pitches) because it tracks instructions tighter on the 60-word constraint and stops adding extra paragraphs. Claude Sonnet for long-form blog drafts and journalist pitch responses where voice fidelity is the load-bearing metric.
I rotate when a model starts drifting from my voice doc, which happens about every 8 weeks. The assignment above is correct as of this week. By next quarter it will probably look different.
$19/mo total? I'm paying more than that for Lemlist alone. Where does that actually go?
Roughly Claude Haiku for monitoring and scoring ($6), GPT-4o for thread relevance ranking and short-form drafts ($7), Claude Sonnet for blog first-drafts and pitch responses ($4), and about $1-2 in Playwright cloud minutes for form filling. Some months it nudges $24. It has not crossed $30.
We are looking for someone who can lend our holding company 300,000 US dollars.
We are looking for an investor who can lend our holding company 300,000 US dollars.
We are looking for an investor who can invest 300,000 US dollars in our holding company.
With the 300,000 US dollars you lend us, we will open a game programming and e-commerce company.
We will use the 300,000 US dollars you invest in our holding company to establish a game programming company and an e-commerce company.
With the 300,000 US dollars budget you will provide to our holding company, we will open a game programming and e-commerce company.
Why would we establish a company in these two business sectors?
The game company we will establish will produce our own game projects and generate significant revenue by publishing our games for a fee on major gaming platforms such as the Play Store, Apple Store, Microsoft Store, and Steam.
We will release the game projects we produce as paid downloads on digital stores, generating significant revenue by charging a fee for each download.
The e-commerce company we will establish will promote our game projects and increase the download rate of our game.
The e-commerce company we will establish will advertise our game projects, helping to introduce our game to a wider audience, and in this way, the download rate of our game will increase rapidly.
In short, our game company will produce game projects and publish these games on digital stores. Our e-commerce company will promote these game projects, increasing download rates and thus generating significant revenue.
By working in coordination between our game company and our e-commerce company, we will create great games and the download rates of the games we make will increase rapidly.
Today, the gaming industry is a large, innovative sector that generates significant returns, so by focusing on the gaming industry, we will achieve substantial income.
Because we have a strong infrastructure and advertising network, and an expert team, we will be able to grow the company rapidly by focusing on the gaming sector.
Since we have the infrastructure ready in the gaming industry, we will be making big money in a short time.
Because the gaming industry is a highly in-demand sector, and because we have a strong infrastructure and foundation, entering this sector will allow us to generate significant revenue.
How will we advertise the game projects we will produce?
We will increase the number of downloads for our game using 5 different advertising tactics.
Thanks to the 5 different advertising tactics we will use, our game will be downloaded by an average of 10,000,000 people in just 2 months.
Thanks to our strong advertising strategy, we will increase our game's download rate in a short time.
Advertising strategy: By continuously promoting our game on global social media platforms like Facebook, Instagram, YouTube, X, Telegram, LinkedIn, and TikTok, we will attract a large audience to our game.
Advertising strategy: We have 170 unique social media applications for each country. By using these applications, we will promote our game to many countries and increase its international popularity.
Advertising Strategy: Our game will feature a referral system that will benefit both existing and new users. The system will work as follows: each registered user will receive a unique referral code, which they can share with others to bring in new customers. When a new user registers, they will enter this referral code in the designated field. The system will automatically recognize the code, and the user who shared the code will receive 2 US dollars for each new customer they bring in. Additionally, the new user who registers using the referral code will receive a 20% discount on the game purchase. This will motivate existing users to recommend the game to more people by earning income from their referrals, and will make new users more willing to join thanks to the discount. This will create a rapid and natural spread among users, allowing our game to reach a wider audience and grow quickly.
Advertising strategy: By using advertising platforms like YouTube Ads, Google Ads, Facebook Ads, and Instagram Ads, we will have our game's promotional video viewed by millions, which will increase the number of downloads.
Advertising strategy: We will place advertisements for our game on blogs and news websites.
Thanks to our strong advertising network and strategy, our game will receive 10,000,000 downloads in just 2 months.
By releasing our game on multiple app stores instead of just one, the download rate will increase even more.
We will release our game on major digital stores such as the Play Store, Microsoft Store, App Store, and Steam.
By implementing these 5 advertising tactics, we will increase our game's download rate in a short time.
We aim for our game to have an average of 10,000,000 downloads within 2 months.
How will we generate revenue from the game project we will produce?
Our game will cost 7 US dollars. Since it will be a paid game, we will earn money for each download.
The game will feature a purchase system. Some characters, weapons, and vehicles in the game will be offered for a fee. Users can purchase this content for a certain price to strengthen their characters and improve their performance and progress in the game more quickly and effectively.
Thanks to the in-game purchase feature, we will generate significant revenue.
By sharing our game on multiple digital stores instead of just one, we will further increase our revenue.
We will add short ads to our game using Google AdMob and generate revenue from these ads.
When our game's download numbers increase, we will advertise the products of companies for a fee.
Today, the gaming market is a highly demanded sector, and by entering this market, we will generate significant revenue in a short time.
With our expert game programming and e-commerce team, we will create great games, attract large audiences to our games, and generate significant profits.
Thanks to our strong advertising network and advertising tactics, our game will receive an average of 10,000,000 downloads in just 2 months.
Since we will be releasing our game on many digital stores, our game will definitely get a total of 10,000,000 downloads.
We will have earned a total average of 70,000,000 US dollars from our game.
Since the download price of our game will be 7 US dollars, we will earn 70,000,000 US dollars just from the number of downloads.
Even companies that make simple games are earning billions of dollars these days.
The gaming industry is a very profitable sector.
By investing in our holding company, you too will earn significant returns and increase your wealth.
How much revenue will you generate by investing in our game project?
If you lend our holding company 300,000 US dollars, I will return your money as 950,000 US dollars on February 26, 2027.
If you invest 300,000 US dollars in our holding company, we will return your money as 950,000 US dollars on February 26, 2027.
I will invest the 300,000 US dollars you lent to our holding company in the gaming sector, increase its value, and return it to you as 950,000 US dollars on February 26, 2027.
I will repay the 300,000 US dollars you lent to our holding company as a loan to you as 950,000 US dollars on February 26, 2027.
You will receive your money back as 950,000 US dollars on February 26, 2027.
By investing in our holding company, you will have increased your money within a few months.
How to contact us:
To learn how you can lend our holding company 300,000 US dollars, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can invest 300,000 US dollars in our holding company, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can increase your money by investing 300,000 US dollars in our game project, send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
For detailed information, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can lend our holding company 300,000 US dollars and to get more detailed information about our game project, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
My WhatsApp contact number:
+212 619-202847
My Telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88
AI seems to be taking over, lovely... If you are looking for leads to help boost your sales and marketing... I have lists of high networth investors and could tailor customers that could either invest or boost customer sales. We have also helped founders get featured on Forbes, Bloomberg and many more. shoot me a message on telegram @caseyimafidon
This hits at the right time for me.
I’ve been trying to make more of my distribution workflow AI-assisted, and my default instinct was to push it closer to full automation. Your post is making me rethink that.
The part that stands out is that the final judgment is probably the whole point: choosing which threads are worth entering, editing the last 30%, deciding when not to mention the
product, and not auto-sending anything that could damage trust.
I’m going to try the 40-action sort this week. My guess is I’ll find a similar split: lots of things AI can prepare, but fewer things it should actually ship.
Do the sort before you buy anything. The list will tell you exactly where to spend and where to stay human. Most people buy first and audit never.
One thing the sort will probably surface: the judgment calls you listed — which threads to enter, when not to name the product — those aren't just the 30% that stays human. They're the 30% that determines whether the other 70% was worth running at all. The AI output is only as good as the selection decisions upstream of it.
Post your split when you have it. Curious whether beauty and lifestyle channels shift the ratio.
The multi-tool problem nobody talks about: using Claude Code + Cursor + Copilot on the same project.
Each one starts fresh. Each one has different defaults. Each one will make a different decision about the same architectural question — and none of them will tell you they disagree with the others.
Six months in, the codebase reflects three different opinions about how to structure the same thing.
The fix: a CLAUDEmd file (works as Cursor rules too) that defines the non-negotiables before any tool touches the code. Stack, patterns, what's forbidden. All tools read the same source of truth.
It's not about which tool is better. It's about making them agree with each other.
Anyone else running multiple AI tools on the same codebase? How do you keep them consistent?
The CLAUDE.md as shared source of truth is the code equivalent of my never-write list. Same principle: the constraint lives upstream of the model, not inside it. Without it each tool optimizes locally and the codebase accumulates three silent opinions about the same problem.
The distribution version of your problem is running the same pipeline across Claude, GPT-4o, and Haiku without a shared voice doc. Each model drifts toward its own defaults. The output sounds like three different founders. The fix is identical to yours — one document all models read before touching anything.
This comment was deleted a day ago.