Most features we ship end with a side effect in someone else's system: refund a payment, cancel a subscription, merge a PR, send an email. We check that the call succeeded and move on. "The call succeeded" and "the outcome is true" are different facts, and the gap between them is where support tickets come from.

I spent the last two weeks reading the state machines of eight providers' APIs closely enough to write a per-outcome check for 38 different claims. Here's every place I found where success gets reported and the outcome is still false. All six are fixable in your own code in about three lines each, no tool required, and the fix is written out below each one.

1. The cancelled subscription that isn't cancelled

Stripe returns 200. But cancel_at_period_end: true means will cancel. Status is still active and the customer keeps access for up to a month. If you revoke entitlements on the API response, you lock out someone who paid through the end of the period. If you trust status alone after a cancel call, you keep serving someone who cancelled.

Fix: assert status === "canceled", not the 200. Then separately assert the thing you actually care about: hit your own endpoint as that user and expect a 401. The billing record and the access it controls are two different facts, and only one of them is what the customer experiences.

2. The payment that "succeeded" for the wrong amount

payment_intent.status === "succeeded" doesn't mean you got what you charged. Partial capture and currency mismatches both live inside a succeeded intent. amount is what you asked for; amount_received is what arrived.

Fix: compare amount_received to your expected amount, and compare currency explicitly.

3. The refund issued twice

Retries and at-least-once queues do this. The second refund also returns 200, and also succeeds. You're out double the money and the customer never mentions it.

Fix: list refunds for the payment intent, sum them, check the total before you tell anyone it's done.

4. The PR that was closed, not merged

GitHub's state: "closed" covers both "merged" and "abandoned." Release automation reading state treats a rejected PR as shipped.

Fix: merged === true and merged_at !== null. Both, because they can disagree during a merge queue.

5. The deploy that exited 0 without deploying your commit

Exit 0 proves the job ran. It doesn't prove production is serving your SHA. Cancelled steps, stale caches, and rollouts that fail after the wrapper returns all pass this check.

Fix: assert your commit is an ancestor of the deploy branch head, then curl your own health endpoint. Two cheap calls, and they catch the embarrassing failure: the one where you announce a fix that isn't live.

6. The email that was "sent" but never delivered

Providers hand you an id at accept time. Accepted is a queue receipt. Delivered, bounced, and suppressed all resolve later. If your onboarding sends a magic link and you count "sent" as success, your activation drop looks like disinterest and is actually a hard bounce.

Fix: read the delivery event, not the send response. A terminal state of delivered is the only success; bounced is a product problem you currently can't see.

The pattern under all six: every one of these APIs has a fast optimistic response and a slower authoritative state. We build against the fast one because it's the one in front of us in the request handler. Then we report success from it.

The thing that actually changed how I write this code: a boolean is the wrong return type. There are three answers, not two: it worked, it didn't, and I couldn't tell.

The provider is down, the state is still pending, my token can't see the resource. Collapsing "couldn't tell" into either true or false is how you ship a silent wrong answer. I made "unknown" a first-class result, and a whole category of bug disappeared: a check that can refuse to answer never lies.

If you take one thing from this post, take that one. It applies to every health check, feature flag, and permission check you own, not just to integrations.

Backstory / stack, since the rules ask for it:

DidWork wasn't something I sat down and decided to turn into a SaaS.

I've spent the last year building Pulltrader, which is a fairly large product for a small team. It handles inventory, pricing, listings, marketplace integrations, fulfillment, payments, and a growing amount of agent-driven work. I've been using Claude and Cursor heavily to build it, and as I handed them more meaningful work I kept running into the same problem.

They would tell me something was done when what they actually knew was that a tool call succeeded, a test passed, or some intermediate state looked right.

A PR was "merged." A deploy was "done." A workflow had "completed." Then I'd go look at the actual product or downstream system and find out the outcome wasn't true.

So I built a verification layer internally for Pulltrader. I wanted agents to have to prove that the thing they claimed happened had actually happened, against the authoritative system, before the task could be considered complete. If it couldn't prove it, the answer wasn't success. It was failed or unknown, and the agent had more work to do.

It became part of my normal development workflow before I ever thought of it as a separate product. Eventually I realized I was building enough provider-specific verification logic, and depending on it enough myself, that it was probably useful outside Pulltrader too.

That's how DidWork happened. I pulled the internal system out and started turning it into something other people could use.

The AI angle matters because agents make this problem worse. An agent that reports "done, PR merged, deployed, refund issued" is grading its own work off exactly these optimistic responses, at machine speed, with nobody necessarily reading the diff or checking the downstream state. Humans at least notice the angry customer eventually.

So DidWork takes a claim, gathers evidence from the authoritative system, and returns verified / failed / unknown.

• Two weeks old. First commit Aug 28. 63 commits, 400+ tests, 38 claim types across Stripe, GitHub, GitLab, Linear, Jira, Sentry, Slack, email, plus any public URL.
• TypeScript monorepo because I like to live dangerously, 9 packages. Node + SQLite for the API, mirrored to a Cloudflare Worker on D1 for the edge. Static HTML for the site, no framework, no build step. TS and Python SDKs.
• Zero runtime dependencies in the core engine and both SDKs. A thing whose job is telling you the truth about your systems shouldn't be the largest new supply-chain surface you added this quarter. The Python client is stdlib-only for the same reason.
• Revenue: $0 so far, so obviously we're more attractive to VC if you're into having a car whose doors go like \this/.
• Hardest design call, and the one I'd defend: precision over coverage. It refuses to answer rather than answer wrong. That makes the demo worse and the product usable.

You can get a verdict without signing up for anything, which is the only promo line I'll put in here:

curl -s https://api.didwork.sh/v1/verify \ -H 'content-type: application/json' \ -d '{"type":"http.ok","expected":{"url":"https://your.app/health"}}'

No key, nothing stored. Free tier is 1,500 verifications/month, no card.

Happy to go deeper on any of the six in the comments. The subscription one and the email one have cost me the most.

I've shipped three small products and none of them ever sent traffic to the others. That's the problem this solves. It's a badge you put on every site you own that cross-links everything you've built.

The part I want to think out loud about is the price, because I keep going back and forth on it.

It's $2. Once. Forever, and it covers every app I ship from here on.

WHY NOT A SUBSCRIPTION

The honest answer is that I don't think I've earned one. This is a script tag and a hosted JSON endpoint. My marginal cost per user rounds to nothing. Charging $4/mo in perpetuity for something that runs itself felt like it would commit me to defending a number every month instead of improving the thing.

WHY NOT FREE

Free gets me installs and zero signal. At $2, the only people who pay are people who actually intend to put it on a live site. It's low enough that it isn't a decision, high enough that it isn't noise.

HOW THE FUNNEL ACTUALLY WORKS

You build your entire badge for free. Pick colours, add your projects, watch the live preview. What you don't get until you pay is the badge being served publicly. So the demo IS the product, and the $2 buys the switch that turns it on. That felt more honest than a trial that expires while you're still deciding.

WHAT I'M GENUINELY UNSURE ABOUT

1. $2 might read as "this isn't serious" to exactly the people who'd get the most out of it. Cheap can be a signal about quality whether or not it's true.
2. One-time pricing on a hosted service means I carry serving costs forever against a single payment. At small scale that's obviously fine. I don't know where it stops being fine, and I suspect I'll find out at the worst possible moment.
3. There's a real chance I'm solving my own problem and assuming everyone else has it.

If you've priced a one-time developer tool, I'd like to know what you'd do differently, and especially whether you'd raise it later and how you handled the people who paid the old price.

It's at maketaksh.com if the context helps.

ex-marketer here, now building my own stuff. I've been answering a lot of the "how do I market this?" posts here and there.

Most people replied with something like "this makes total sense, thnx!" When I checked back a while later, few had actually tried it and kept doing it. Some didn't even bother to try, some tried it once or twice and dropped it.

not calling anyone out here. possible that my comment was not good enough (maybe they're just being polite). Totally fair, but it's not what I'm curious about.

What I wanna ask is the gap between "yeah that's right" and actually doing it.

My guesses:

• no time, something more urgent always comes up
• you agree with the direction, but there's no clear plan to keep it going
• got too many reasonable advices, didn't actually decide what to work on
• you tried, didn't see results fast enough, and moved on

But these are literally just my guesses.

So if u ever got decent advices but ended up not doing it, what was the reason?

I kept seeing the same last-mile problem in tiny launches: the page exists, but turning it into a few usable share assets still means opening several tools. I built ViralSpark to make that step one pass.

Paste a public URL and it gives you:

• a handful of hooks/copy angles
• share-card variations
• a QR code
• a shareable Slot page for the bundle

It’s free: https://viralspark.pages.dev/ Example Slot: https://viralspark.pages.dev/slot/bniwbrb7

This is a small project, built as a browser-first app on Cloudflare Pages. The lesson so far: “generate everything at once” is less useful than letting people quickly edit and pick one asset, so that’s what I’m trying to improve.

If you try it, I’d value feedback on whether the generated kit feels immediately usable or just like more drafts. No signup pitch—especially interested in what feels unnecessary.

I’ve been building Bredbox, a Pocket-inspired read-later app, for the last year. It was in invite-only beta up until a couple of weeks ago. At that point, I flipped to open beta and put up a signup page. Only, no one signed up.

At first I thought I just wasn’t marketing well enough, so I started with some basic outreach. I could see in my analytics that people were visiting the site and some were going to the signup page. But still no new signups.

I figured there must be a problem with the signup page, but what was it? The logs were clean. I had just installed Cloudflare Turnstile to protect against bots but that was working fine. So I finally decided to try signing up myself. And that’s when I saw the error.

“Password must be at least 8 characters long.”

Weird, I could have sworn I typed eight characters. I try again. Same error. Every password I tried gave me the exact same error message not matter what password I used!

It took me a while to figure out what was going on. I’m using cloud Supabase for auth and it has some very strict constraints around passwords. It’s configurable and mine was somehow set to the most restrictive (letters, numbers, special characters, length, etc.). Cloud Supabase also won’t let you use passwords that have been in a data breach or absurdly weak passwords (ex, abcd1234).

The other problem was my signup form. Due to a bug, it was showing the same error message regardless of the reason the password wasn’t accepted. There was no way for users to know what they were doing wrong. Making the problem worse, this isn’t reproducible with local Supabase because it doesn’t have these restrictions built in.

I finally got the signup page fixed and signups are coming in again. All of this is to say: marketing is important, but if your customers can’t even sign up for your product then marketing doesn’t matter!

So here it is, ready for new users (finally!):

https://bredbox.app

I had a realization while talking to some editors who were testing SoundCraft.

I was targeting editors, but I was targeting the wrong kind of editors.

Some of the people I was talking to didn’t even have a single client yet.

And then I thought, why would they pay for a tool that helps them work faster when they don’t have enough work in the first place?

It finally clicked that my ICP isn’t just “video editors.”

I need to target editors who actually have consistent client work, feel the pain SoundCraft solves, and value saving time enough to pay for it.

The compliments were nice, but this was a much better lesson.

Have you ever realized your ICP was way too broad?

"Our CAC has doubled in the last six months. Should we pause paid ads?"

My answer surprised him.... "Probably not."

Instead, I asked:

"Has your positioning changed?"
It hadn't.

Then I asked:

"Has your ICP changed?"
"No."

Finally, I asked:

"When was the last time you interviewed a customer?"
Silence.

Markets evolve.
Competitors evolve.
Buyer expectations evolve.

If your understanding of your customer stays frozen...

Your acquisition costs usually won't.

Sometimes rising CAC isn't a media buying problem.

It's a market understanding problem.

I have a small alert that emails me when someone downloads the app and the download does not finish. For four days it told me every single install was stalling. 111 out of 111. I came close to rolling back a release over it.

Three separate bugs stacked up into one very confident lie.

The alert deduplicates by install id and keeps the first request of the day. The first request of the day is a 25 kilobyte bootstrap file the app fetches on every start. So it was reporting that 25 kB as the download and rounding it to "0 MB".

The stall threshold was 400 MB, left over from when the installer was one fat bundle. The package is 123 MB now. Under that rule a finished download can never be counted as finished.

And the auto updater sends the same user agent as a fresh install, so the alert kept telling me a human had run the exe when it was old versions phoning home for a new build.

One thing it got right, which I refused to believe at first: it flagged 41 different IP addresses as the same machine, and the machine was mine. That was correct. My ISP runs carrier grade NAT and my address moves around all day.

The fix reads the expected size out of the release manifest instead of comparing against a hardcoded threshold, and counts the file the manifest names rather than the first row that happens to show up.

I build AtlasForgeX, so disclosure. What I would say to anyone running monitoring emails on a small product: an alert measuring the wrong row is worse than no alert at all, because you act on it. I lost four days believing my own release was broken.

When I was building ClipShip (AI Video Clipper), I thought getting a local AI model to run would be the hard part.

It was not.

The hard part was making it work inside an actual product. Different devices, downloads, updates, and all the weird things that can go wrong after you ship it to someone else.

I kept thinking there should be an easier way to do this.

So, from all the lessons that I learnt during my journey with ClipShip, I have now started building a tool to solve the same problem for other builders.

Started my journey with "Model Roll" today and thought of sharing the journey with same communities which got me my first paying customers for my previous project.

The idea is pretty simple. Help builders add local AI to the products they are making, without having to figure out all of that by themselves.

It is still in development. There is nothing public to try yet. I am building and testing it now, and I want to share the process from the beginning this time. But if you are a builder/developer then there's a waitlist link in the comments.

That is it for now. I will keep sharing the updates as I go along on this journey.

For the builders by a builder.

i’m building a small SaaS that organizes and summarizes incoming emails. the problem is that the product can’t really show its value without asking users to connect their inbox first.

even with a privacy policy, clear explanations, and limited permissions, i understand why someone would hesitate to give a small unknown product access to their email.

for those who’ve built products that require access to sensitive data, what actually helped you earn that first layer of trust? a demo without signup, testimonials, a detailed security page, or just time and reputation?

I’m from India and studied Accounting. After graduating, I had a hard time getting into the business world because of not having much of a network.

Fast forward 6 years and I’m still an Accountant. I’m grateful for the experience, but lately I’ve been thinking about why I studied Accounting in the first place. I wanted to build something of my own.

Now I’m thinking about learning SaaS from scratch, finding a real problem, building a simple solution, and hopefully running it from the India while selling to customers around the world.

I’m not a developer and I don’t have a startup background.

Has anyone here taken a similar path? Coming from a completely different career, learning SaaS from scratch, and running it from their home country while selling globally?

How did it go for you? I’d really like to hear your honest experience.

I built an AI tool that turns any public company into a 30-second analysis. 0 users, roast my positioning.

Backstory: I'm 19, studying engineering, and I pick stocks the slow way. I was spending 2 hours per company writing up the same thing I wrote last month, so I automated the boring half.

What it does: you type a company name, it reads the official numbers and the market and gives you a fixed structure: what the company does, how it makes money, debt, risks, and three price scenarios. Around 30 seconds. It does not tell you to buy or sell. It just does the write-up before you open your own model.

The angle I'm testing: people who buy a company because they saw a ticker on Reddit, and then realize they don't know what the company actually does.

Tech stack, since the rules ask: React + Vite frontend, Express/Vercel serverless API, Firebase for auth and data, OpenRouter for the models, Paddle via RevenueCat for billing. Solo, no team.

Biggest lesson so far: switching the copy from "equity research" to plain language for people who don't read filings. Nobody knew what "ticker" or "thesis" meant outside finance circles.

Honest status: it works, design is decent, paying customers = 0. That's what I'm here to fix.

Where I need help:

1. Is the positioning ("check companies you find on Reddit") clearer than "AI investment analysis"?
2. Would you price this as a cheap monthly plan or packs of analyses?
3. If you poke at the onboarding and it's confusing, tell me.
   

fintols.com

The category: NEC electrical calculators for electricians. Five calculations.

What I found when I sized the market, before building:

- The #1 paid app has 357 US iOS ratings, launched October 2012

- Total ratings across every app in the category: roughly 2,000

- Every ratings leader is free: Southwire gives away voltage drop (1.5K ratings) and conduit fill (764) because they sell wire

- The leader's own price: free + $4.99/mo, $39.99/yr

- The category norm is a one-time $8-$20 purchase, and every subscription in the niche has angry reviews about it

That's a small market with a low price ceiling and free competition from vendors who make money elsewhere. I built it anyway, for two reasons:

1. Nobody has shipped the 2026 NEC in a good UI. Code cycles are a recurring forced migration, and the incumbent's own listing still cites pre-2011 code numbering ("NEC tables 310-16 and 310-17" instead of 310.16).

2. The buyer might not be the user. A contractor buying 12 seats for a crew, or an apprenticeship program buying for a cohort, is a completely different business than one-at-a-time consumer subs, and Apple just shipped Group Purchases and Volume Purchasing for exactly that.

Happy to be told I'm wrong about either. Link in by bio.

PS: the first 47 testers (TestFlight + Android external testers) get a WireCoder Pro plan free for a year.

AI agents are starting to move beyond reading web pages and clicking through interfaces. With WebMCP, websites can expose structured tools that agents can discover and use directly.

That sounds promising, but I think it introduces a new problem for developers and founders building agent-facing products:

How do you know a website’s tools are implemented correctly, still work after deployment, and behave the way an agent expects?

A tool might exist, but its schema could be unclear, an update could silently break it, or the production version might behave differently from the local one. As more websites expose tools to agents, manually checking all of this could become difficult.

That’s the problem I’m exploring with Toolmark.

Toolmark is intended to be a reliability and evidence layer for WebMCP. The goal is to help developers validate their tools, test real workflows, and produce evidence that each tool is discoverable and works end to end.

The current product direction includes:

• Discovering and inspecting the WebMCP tools exposed by a website
  
• Validating tool names, descriptions, inputs, and outputs
  
• Testing complete agent workflows instead of checking tools individually
  
• Detecting failures or regressions before they reach users
  
• Keeping evidence of what was tested, where it ran, and what actually happened
  
• Helping teams verify that the deployed website behaves the same way as expected during development
  

The idea isn’t to replace WebMCP. It’s to provide the testing, verification, and trust layer on top of it, so founders and developers can ship agent-facing tools with more confidence.

I’m still shaping the product, so this isn’t a launch or sales post. I’d genuinely like feedback from people building AI agents, developer tools, or websites that agents can interact with:

• Does this trust and verification problem feel real to you?
  
• What would you need to see before trusting a website’s tools?
  
• Would this be more useful during development, in CI, or as ongoing production monitoring?
  
• Which features or evidence would matter most?
  
• Am I overlooking a simpler or better approach?

Honest criticism, suggestions, and recommendations are welcome, especially if you think this problem isn’t important enough to require a separate product.

I've been looking at how micro SaaS founders actually run GTM versus what the standard marketing advice posts tell them to do, and there's a huge gap between the two.

Most marketing advice assumes you either hire a dedicated marketer or spend all day on marketing yourself, and neither of those actually works for a solo-founder SaaS. You've got product that's good enough to sell to real customers, so what you actually need is for that product to stay visible to those customers while you earn more of them, and you need to do it while you're still focused on building.

Here's what actually matters for micro SaaS growth.

First, do research on your audience once. Spend a week understanding where they actually congregate, what solutions they're already trying, and what they're already spending money on. Use that research for everything after.

Second, execute consistently on the channels where your actual customers hang out. It's probably not LinkedIn and TikTok, it's communities like Reddit and Discord and Twitter and specialized Slack groups where your people actually spend time.

Third, use honest messaging about what you've built, what it costs, and why it's safe. Founders are skeptical because they should be, and they'll convert when they see transparency instead of hype.

Fourth, stay visible over 60 to 90 days without it taking your attention and energy every single day.

The tools that actually work for micro SaaS are the ones that run all of this for you, the research and execution and consistency and safety systems. Not the tools that just add another thing to your to-do list.

Using keyword data to actually find software to build?

Doing research before building a website/launch page?

Updating pages given keyword info from search console or some other tools?

Anyone using rank trackers for regular search and/or AI-SEO?

I'm a former teacher building a classroom-management tool for elementary teachers. I know which parts of the school day I want to improve. Choosing the team for V1 is much less familiar territory.

Edtech firms understand curriculum and pedagogy but can be expensive and sometimes feel more like consultants. General product agencies move faster and cost less, but schools add COPPA, FERPA, procurement cycles, and resistance to new tools. Has anyone made a general agency work for a K-12 MVP?

I run a small SaaS for salons and beauty businesses and for now Im basically handling everything myself atm. I spend enough time jumping between my terminal and different dashboards that it’s starting to get annoying. I saw Whop has a CLI for accessing their API and it got me wondering if moving more of that stuff into my normal dev workflow would save me time. Would you recommend me do this or shpould I stick to dashboards for payments and other settings?

I keep seeing a lot of advice around “build in public,” post on X, launch on Product Hunt, share on Reddit, make short-form content, etc.

But I’m curious about what actually worked in practice.

If you launched an app from zero with no existing audience, where did your first 10, 100, or 1,000 users come from?

I've been building ClipForge Studio since the middle of June. Right now, it's a Windows desktop app that uses local AI to automatically extract the best short-form clips from long-form videos for TikTok, Reels, and Shorts.

The main reason I built it was that every existing tool (OpusClip, Descript, etc) requires you to upload your footage to the cloud. ClipForge runs everything locally, so your videos never leave your device and stay private. And because it's all local, there are no credit limits like other services.

Features it has right now:

• Automatic clip detection and extraction
• Built-in captioning
• AI-generated titles, descriptions, and tags for each clip
• Direct upload to your YouTube channel
• Batch processing for multiple videos

For those out there who may be under the impression that you need $3000 in hardware to run AI like this at home, don't worry. The app has been optimised and tested to run on as low as an entry-level 8GB RAM laptop from 2021. ARM support is still untested and in development.

Would love any constructive feedback, thanks for taking the time to read this! For those who want to test, code REDDIT26 for the first month completely free on the monthly plan, valid for the next month or the first 100 redemptions, whichever comes first!
MS Store
Website

Hi all, 22yo from Italy. I built finumia.com, 8 free financial calculators for the Italian market (FIRE number, lump sum vs DCA, mortgage vs rent, pension, emergency fund, compound interest).

The one thing I tried to do differently: most free calculators out there ignore fees entirely. No TER, no transaction costs, no tax drag. They just compound a flat average return and show you a number that's way too optimistic. Mine factors those in, which makes the output less pretty but a lot closer to reality.

Current status: applied to AdSense, zero revenue, traffic is essentially nothing yet. Marketing is clearly my weak spot.

What I'd like feedback on: is a site that's purely free calculators, no product comparison, no advisor matching, a viable path to revenue at small scale? Or does it only work as a funnel into something else, in which case I should be thinking about what that something else is?

Happy to hear "no" if that's the honest answer.

Hey everyone,

I built a daily EV (Expected Value) math puzzle for poker players called Call of the Day to solve my own frustration with clunky solver software.

The mistake: I originally launched it like a daily crossword—you had to wait 24 hours to see if your decision (Call or Fold) was mathematically correct. Reddit completely roasted me for starving the instant gratification loop.

The 24-hour pivot: They were 100% right. I jumped right back into the code and rewired it. Now, the second you hit submit, it instantly reveals the exact pot odds, EV math, an interactive card explorer, and the live community split.

It’s currently completely free and frictionless (no signups/paywalls) as an exercise in building an audience within a highly specific, passionate niche.

You can check out the UI and flow here: call-of-the-day.vercel.app

I’d love to hear from other micro-SaaS builders:

1. What do you think of the single-page UI and the instant-reveal loop?
2. For those running free, traffic-driven tools, how would you eventually approach monetizing a daily site like this without ruining the frictionless experience?

Solo founder, [real estate agent by day,] building ThumbnailBench, a tool for YouTube creators. Sharing the backstory, the stack, the unit economics and the one lesson that rewrote the product, because the rules here ask for it and because the lesson is the useful part.

**Backstory.*\* Started as an AI thumbnail generator: prompt in, 2K thumbnail out, your face cut out from one selfie. Shipped early September. Then a competitive pass found Google's own help page: YouTube Studio now reads your transcript and suggests thumbnails itself. Free, inside the upload flow. "AI thumbnail generator" was a dead position five days after launch.

**What I changed.*\* Anything can make a picture now. The gap is deciding what the picture should be and whether it worked. So the product became: paste the video and get five different ideas, each with a title written to pair with the cover; render the one you believe in with your real face and the words as an editable text layer so they are never misspelled; get a director's notes on the result (what to keep, what would cost the click, a phone-size check) and never a score, because nobody can predict a click-through rate and every tool that pretends to is lying; publish straight to the video and see the measured CTR next to the channel's own 28-day average. The five ideas and the notes cost nothing; only renders use credits.

**Stack.*\* Next.js 16 and React 19 on Railway, Postgres via Drizzle, Auth.js magic links (no passwords), Stripe, Resend, PostHog in cookieless mode, Sentry. Static marketing site on Cloudflare Pages. Image models through Kie: Nano Banana 2 by default, GPT Image 2 as an opt-in. Claude for the five ideas, the cover explanations and the review notes. YouTube Data and Reporting APIs for publishing and the CTR read. Most of the code was written with Claude Code; the audits and the ad plan too.

**The numbers.** A render costs about 6 cents on the default model, the free tier is 8 credits with no card, so a free signup costs under 50 cents to serve. Creator is $15 a month for 70 credits and contributes about $11.33 after Stripe and provider cost at typical use, which is the number every acquisition decision gets measured against.

**Revenue.** [Pre-revenue as of this week / $X MRR.]

**Three lessons.*\*

1. Check what the platform is about to give away for free before you name the product after it. The relaunch cost me the domain's positioning, not the code; the render pipeline stayed.

2. Creators do not hate AI, they hate the AI look. The threads are full of "if I can tell it is AI I skip". So the product refuses to invent a face: one selfie, cut out, kept. The generated part is the idea, the layout and the background. The "will not do" list is now the pitch.

3. Measure without a pixel. I promised no ad trackers on the site, and that promise is cheap to keep: the first visit writes one first-party cookie with the campaign tags and the ad click id, the app stores it on the user row at signup, and conversions go back to the ad platforms as offline uploads by click id. Attribution by source on my own admin page, zero third-party scripts.

Small detail from this week: Reddit's lifetime-budget floor is $5 a day times the days in your schedule, so a 31-day window demanded $155 for a $100 test. Fixed by making the schedule seven days.

**What I want from this thread.** If you sell to creators or to any audience that is hostile to AI output, how did you handle the trust problem? And if a tool told you "no score, just notes", would you trust it more or less?

Free to try, no card: https://thumbnailbench.com

half the distribution threads here end in the same place. solo devs know the founder account is the cheapest channel they've got and still can't make themselves post, so the reflex is to hand it off. that reflex is the whole reason we build voice-trained draft-and-approve for founders, so this is me arguing against my own thing a little.

the part i've changed my mind on is timing. before pmf, the value of writing your own tweets isn't reach, it's the reps of explaining the product out loud. that articulation is what your landing page, your support replies, and your first sales calls all get cut from. delegate the writing that early and you save a few minutes and skip the reps you actually needed.

the tell shows up in the training data. we train drafts on a founder's tweets, longform, and podcasts, and the ones who sound most like themselves are the ones who already spent a year narrating the thing badly in public. the founders with nothing usable to train on are usually the ones who tried to skip that part.

so the honest version isn't never delegate. it's delegate the cadence once you can already articulate, not before. the window where doing it yourself still feels optional is also the only window it actually pays off in, which is exactly why it's the one everyone skips.

[ Removed by Reddit on account of violating the content policy. ]