yoshibuilds

For indie hackers who ship.
1 micro-tool/week, built in public.
Real revenue numbers — flops included.
→ WellKeptSite · WallyWatcher

[yoshibuilds @yoshibuild]

I run 2 SaaS products AND sell source code on Gumroad. Here's how I decide which model fits a new build:

1. Does it deliver ongoing value? If the tool is useful once (a screener, a template, a script) → one-time sale. If it has to keep working for you (site monitoring, price tracking) → subscription. The model follows the value pattern, not my preference.

2. Can I support it every week? SaaS means uptime, tickets, churn. I only put a subscription on products simple enough to run themselves. Everything else becomes source code — sold once, barely any support.

3. Who's the buyer? Builders buy source code to learn and modify. Non-technical users buy SaaS for "it just works." Different hats, barely overlapping audiences — so I'm not cannibalizing myself.

4. The portfolio effect. SaaS = slow, recurring revenue. Source code = launch-day spikes, then passive. They smooth each other out. A slow SaaS month gets covered by a good launch week.

My actual split: WellKeptSite and WallyWatcher are SaaS — 24/7 monitoring IS the product. The breakout screener is source code — run it yourself, modify it, it's yours.

Neither model is "better." The mistake is picking one religion. Match the model to the product.

I build in public weekly — SaaS metrics and Gumroad numbers, wins and losses. Source code for the one-time tools is on Gumroad (link in bio).

[yoshibuilds @yoshibuild]

7 things that look like progress but aren't:

1. Redesigning your landing page. Your 40 visitors didn't bounce because of the font.

2. Adding features before 10 users. You're not "staying ahead" — you're hiding from the scary part, which is talking to people.

3. Watching competitor launches. Research feels productive. It's consumption with a notebook.

4. Perfecting your bio and logo. Nobody ever bought because of a great header image.

5. Rewriting the same post 5 times. Post it. The algorithm doesn't grade drafts.

6. Learning a new framework "for the next project." The next project needs customers, not a new stack.

7. Tracking 15 metrics. If you can't name the ONE number that matters this week, the other 14 are decoration.

Real progress is boring: ship, talk to users, fix one thing, repeat. Everything else is procrastination with better branding.

[yoshibuilds @yoshibuild]

Why I really build in public. The selfish reasons nobody admits:

1. Free QA. I post a bug, someone replies with the fix in 10 minutes. My "audience" is an unpaid engineering team that works for replies.

2. Forced shipping. Announcing "ships Friday" in public means I can't quietly delay it to Monday. Shame is a better project manager than any app.

3. Ideas come to me. I posted my stack once and got 5 tool recommendations better than anything I'd have found googling. Broadcasting is inbound R&D.

4. The archive compounds. Every post is a searchable record of decisions. "Why did I price at $19?" — I just scroll back. My timeline is my documentation.

5. Trust before product. When I launch, strangers have watched me work for weeks. They don't buy the tool — they buy the 50 posts that came before it.

Build in public isn't generosity. It's the highest-ROI habit I have. The transparency is just packaging.

[yoshibuilds @yoshibuild]

Before building anything, I spend 10 minutes on this competitor check:

1. Google "[problem] tool" — open the top 5 results. If they're all blog posts and forum threads from 2019, that's not competition. That's an empty shelf.

2. Check for paid alternatives. A paid competitor is GOOD news — it means people already pay for this. No paid competitor means you have to educate the market AND sell to it. Much harder.

3. Read the 1-star reviews of the closest competitor. Every complaint is a validated feature request. "No Excel support" × 20 reviews = your v1 spec, written by angry users.

4. Check their last update date. Abandoned 2 years ago? You don't need to be better — you need to be alive. "Actively maintained" beats "feature-rich" for solo tools.

5. Price check: find the cheapest and most expensive option. Price in the middle. Too cheap signals "toy," too expensive needs a sales page you don't have yet.

10 minutes. If the idea survives this, it's worth 4 days of building. If it doesn't, you just saved yourself a week.

[yoshibuilds @yoshibuild]

48 posts. 27 followers. The honest breakdown nobody posts:

Most of my posts get 10–22 views. Not a typo. Dozens, not thousands — I could fit my audience in a classroom.

One post broke the pattern: the SaaS vs. source-code one, 136 likes. 10x everything else. Same account, same week, same author.

The replies worth having didn't come from tutorials. They came from the opinionated ones — the twice rule, the Mods post.

Verified builders argue with takes; they bookmark guides silently.

So the uncomfortable lesson after 48 posts: volume doesn't compound. Spikes do. And spikes come from saying something arguable, not something useful.

Useful gets saved. Arguable gets shared.

I'm done pretending I don't know the difference.

[yoshibuilds @yoshibuild]

AI forgets what your character looks like between images. I fixed it with a stupidly simple workflow:

1. Design the character ONCE from fixed parts — face, eyes, hair, colors. Lock it. "Anime girl, black hair" as a prompt generates a different person every time.

2. Generate one clean reference sheet: front view, neutral expression, plain background. This image is now the source of truth.

3. Every new scene starts from the reference, not from text. Image reference every single time. Text describes the scene; the reference describes the person.

4. Anchor the face in words too: the same short face description in every prompt. Redundant on purpose — it's a checksum.

5. Generate in batches, compare against the reference, keep the closest. Consistency is curation, not luck.
I ran this on a test character: same bob, same bangs, same amber eyes — across a neon street and a flower meadow.

Two different worlds, one person.

Stop describing your character. Show the model who she is.

[yoshibuilds @yoshibuild]

I ship every Friday. The checklist I run Thursday night is why Friday doesn't hurt:

1. Env vars set in production — not just in .env.local

2. Error tracking actually receiving events (send a test one)

3. Database backup ran this week, and I verified I can restore it

4. HTTPS forced, no mixed content warnings

5. 404 page exists and doesn't look abandoned

6. Opened it on a real phone, not just devtools mobile view

7. Payment flow tested end-to-end, then refunded

8. Rate limits on every endpoint that costs me money

9. Logs I can read at 2am — one place, timestamps, request IDs

10. Rollback is one command, and I've run it once on purpose

11. Debug routes and console.logs deleted

12. Someone who isn't me clicked through the whole thing
#12 catches more bugs than 1–11 combined. Every time.
Skipping the checklist doesn't save an hour. It borrows three from next week, with interest.

[yoshibuilds @yoshibuild]

The part of Stripe everyone gets wrong isn't the checkout. It's the webhook.

I lost events for weeks before I learned this. Here's the setup that finally stopped the bleeding:

1. Verify the signature first. Every event. The stripe-signature header against your webhook secret. No signature, no processing — this is what stops forged events cold.

2. Return 200 fast, work later. Acknowledge receipt immediately, push the real work to a queue. Stripe retries for days if you're slow, and slow handlers create duplicate fulfillment.

3. Store every event ID. Stripe will redeliver. "Already processed this ID" should be the most boring line in your codebase.

4. Log the raw payload before you touch it. When something breaks at 2am, the payload is the crime scene — you want it untouched.

5. Test with the Stripe CLI, not with real money. stripe listen --forward-to is the closest thing payments has to a free staging environment.
Webhooks aren't a feature. They're a promise your system makes to money. Treat them like it.

[yoshibuilds @yoshibuild]

@LeeWyattCorp great question. the boring one — a deny-only guard. block rm -rf, force pushes, db drops. never grant, only refuse. a mod that can only say no is the only kind i'd trust with permission checks, because you can't prompt-inject a blacklist into saying yes.

[yoshibuilds @yoshibuild]

Claude Code shipped Mods this week and I think people are underrating it.

Not another feature — a platform shift. Mods are JS/TS functions that hook into the tool itself: prompts, tool calls, permission checks, even UI rendering. You no longer just change what the AI outputs. You change how the tool behaves.

Block dangerous commands. Inject your own review step. Render a custom status bar showing context usage. Anthropic's own /diff and AGENTS.md support already run as Mods, and the community is already shipping wild ones — a "Token Weather" status bar, a "Blast Radius" interceptor that puts an approve/cancel panel in front of risky commands.

I sell Claude Code prompt packs on Gumroad. Mods are the obvious next product format for people like me. Prompt pack = words. Mod = behavior. The ceiling just got 10x higher — and so did the bar.

The catch everyone will learn the hard way: Mods run unsandboxed, with full user permissions. Anthropic's own warning is "install only from sources you trust."

First paid Mods won't win on features. They'll win on trust.

[yoshibuilds @yoshibuild]

How I name my products. 4 rules, 60 seconds:

1. Say what it is. "Reseller Profit Tracker" — a reseller knows instantly what it does. Clever names are for companies with ad budgets. You have neither.

2. Say what it works with. "(Sheets & Excel)" goes in the title. Every compatibility question answered in the title is a support ticket you never get.

3. No made-up words. If someone can't spell it after hearing it once, it's wrong. Products get recommended by voice, in DMs, in passing — make it transmittable.

4. Check the search. Type the name into Google and Gumroad. If 10 similar products show up, add one differentiating word. If nothing shows up, you might own the term — even better.

The test: read the name to a friend, wait 10 seconds, ask what it was. If they remember, it passes. If they say "something tracker?" — back to work.

Boring names convert. Clever names get compliments and zero sales.

[yoshibuilds @yoshibuild]

@ShivamPatxl that's the failure mode in one sentence. a prompt that skips the approval gate looks like a text file but behaves like a permission change — and nobody reviews prompts the way they review PRs.

[yoshibuilds @yoshibuild]

If I started from zero today, here's the exact 30-day plan:

Days 1–7: Lurk and listen. Pick 3 subreddits where your buyers hang out. Sort by top/month. Write down 20 pains people describe in their own words. Don't build anything. Don't post. Just collect.

Days 8–10: Pick ONE pain with 100+ upvotes and zero real solutions. Describe your fix in one sentence. If you can't, keep looking — you don't have an idea yet.

Days 11–17: Build the smallest version. No auth, no design, no settings page. If it takes longer than 7 days, you're accidentally building v2. Cut scope.

Days 18–20: Give it to 5 strangers free. Not friends — people from the thread where you found the idea. Ask each one: "what almost stopped you from using this?"

Days 21–23: Fix what they said. Only what they said.

Days 24–30: Launch. Post the story (not the features) on X, reply to the original thread, list it for sale. Then go back to listening.

Total cost: $0. Audience needed: zero. The only requirement is 30 days of refusing to build the wrong thing.

[yoshibuilds @yoshibuild]

5 things I stopped doing to ship every week:

1. Stopped building auth in v1. Nobody ever said "I love this tool, wish it had login." Someone pays → then I add accounts. Revenue first, infrastructure later.

2. Stopped designing. Default styles, one accent color. Every hour on design is an hour not shipping. Users forgive ugly; they don't forgive missing.

3. Stopped reading success stories. They're survivorship bias with good lighting. I read post-mortems instead — failures teach, wins just entertain.

4. Stopped optimizing for scale. My tools would break at 10,000 users. I have a tiny audience. Premature scaling is procrastination dressed as engineering.

5. Stopped waiting to feel ready. "One more feature" is fear, not strategy. The launch post goes out Friday whether I'm confident or not. Confidence comes after shipping, never before.

Every "stop" bought me a day back. That's how 7 days became enough.

[yoshibuilds @yoshibuild]

Every Sunday I spend 20 minutes on this review. 5 numbers, nothing more:

1. Revenue. Gumroad + SaaS, total and per product. One number. If it's zero, I write zero. Hiding it from yourself is how you quit quietly.

2. Signups/downloads per product. Tells me which launch actually landed. I log it weekly — trend beats absolute numbers.

3. Traffic sources. One line per product: "X post → 12 visits, Reddit reply → 30 visits." After a month your top 2 channels are obvious. Everything else is noise you can ignore.

4. Replies and DMs. Count them. 5 thoughtful replies beat 500 views. Views are vanity; conversations are pipeline.

5. Hours built vs hours distributed. If I spent 30 hours building and 2 distributing, the ratio is broken. My rule: at least 1 hour of distribution per 4 hours of building.

What I deliberately ignore: follower count, likes, impressions. They feel like progress and measure nothing.

Six spreadsheet rows. 20 minutes. Every Sunday, no exceptions. You can't fix what you don't look at.

[yoshibuilds @yoshibuild]

My last launch got 3 downloads in week one. Here's exactly what I did instead of panicking:

1. Nothing for 48 hours. Launch day numbers are noise. Most downloads came days 3–7 from replies and reposts, not the launch post itself.

2. Asked all 3 downloaders one question: "what almost stopped you from downloading?" One said the description was confusing. I rewrote it that night. That single fix was worth more than 100 new visitors.

3. Posted the flop. "3 downloads this week. Here's what I think went wrong." That post got 10x the engagement of the launch itself. People root for honesty, not highlight reels.

4. Changed one variable. Not five — one. I changed the title. Next launch I'll test the price. One variable per launch, or you learn nothing.

5. Shipped the next thing anyway. The best cure for a flop is a new launch. Weekly cadence means a bad week costs me 7 days, not 7 months.

A flop isn't a verdict. It's a data point with an ego attached.

[yoshibuilds @yoshibuild]

great question. paying customers get a fast lane, not a free pass.

one payer asks → I check with 3 more users first.
two payers ask → it gets built.

the rule was never "ignore everyone." it's "don't build on a single data point." money makes the data point heavier, just not conclusive.

[yoshibuilds @yoshibuild]

3 lessons from my first SaaS

1. I built for 6 weeks before showing anyone. By launch day I was too tired to market it. Now: I post the idea on day 1. If nobody cares, I find out in hours, not months.

2. I added features nobody asked for. "Users might want reports!" They didn't. Every unrequested feature is a week you'll never get back. Now: no feature ships without a real person asking for it twice.

3. I priced by guessing. Picked a low number because it "felt right" — it felt right because I was scared to charge more. Now: I price the head start, not my insecurity. $19 minimum, always.

The common thread: every mistake was me avoiding discomfort. Showing unfinished work. Saying no. Charging real money. Building was never the hard part.

I still make new mistakes weekly. That's what this account is — real numbers, real decisions, wins and losses.

[yoshibuilds @yoshibuild]

The exact structure of my launch posts. I reuse this every time:

Line 1: the result, not the product.
"Just shipped: Reseller Profit Tracker Spreadsheet. Free."
Not "I'm excited to announce..." Nobody cares about your excitement. Lead with what they get.

Paragraph 2: the pain, in their words.
"Spreadsheet chaos. 'Am I actually making money on this?'"
If they don't feel seen here, they're gone. I steal this language from Reddit threads and DMs — never invent it.

Paragraph 3: what it does, concretely.
"Tracks every item: buy cost, list price, sold price, shipping, fees. Auto-calculates profit, margin, ROI."
Verbs and nouns. No adjectives. "Powerful" and "seamless" mean nothing.

Paragraph 4: proof it's real.
"Ships with 40 sample items so you can see it working before touching your own data."
Remove the risk of trying. A screenshot works too — anything that says this exists.

Last line: one action, low friction.
"Type 0 in the price box and it's yours."
One verb, one outcome. Not "check it out!!" with three links.

What I never include: features nobody asked for, my backstory, "excited to announce," more than one link.

Steal this structure. It works because it's not about my product — it's about respecting the reader's 10 seconds

[yoshibuilds @yoshibuild]

Anatomy of my Gumroad product page — every section and why it exists:

Title: "Reseller Profit Tracker Spreadsheet (Sheets & Excel)"
Boring on purpose. It says what it is and what it works with. Nobody searches for "revolutionary profit solution."

Price: $0+ (pay what you want)
Free removes all friction for a product with zero reviews. The "+" catches the few who pay anyway — and every payer becomes a testimonial I can quote.

Section 1: "Who it is for"
One sentence: people who sell used items on eBay, Mercari, Poshmark. If you don't see yourself, you leave — good. Wrong buyers write bad reviews.

Section 2: "What is in the file"
Exhaustive list, not marketing copy. Every column named. Buyers can't touch the product before paying, so the description has to replace the demo.

Section 3: "How to use it"
Three steps. If it takes longer to explain than to use, the product is too complicated. This section is a complexity test.

Section 4: "Not for you if..."
I list what it CAN'T do. This kills refunds before they happen. "No monthly reports, no fee presets — that's the Pro version." Honesty here outsells any upsell copy.

The pattern: each section answers one fear. "Is this for me?" "What do I get?" "Is it hard?" "What's the catch?" Kill all four and the buy button clicks itself.

[yoshibuilds @yoshibuild]

How to get your first 10 users with zero audience. No hacks — just what actually worked:

1. Start where the problem lives. My screener's first users came from the exact Reddit thread where I found the idea. Don't build an audience first — borrow someone else's. Find the thread, solve the thread, reply to the thread.

2. Make v1 embarrassingly small. 10 users don't need a polished product — they need one painful problem gone. Polish is for user 1,000.

3. Ask for the reply, not the signup. "Tell me what breaks" beats "sign up here." Replies become testimonials, bug reports, and feature requests — all worth more than a silent signup.

4. Ship in public, daily. Not just "launch day" — every day. "Fixed X today." "Added Y." Each micro-update is a touchpoint. By launch day, strangers feel like they've watched you build it.

5. Give the first 10 a reason to stay. I answer every DM personally. At 10 users, support IS the product. They'll remember being heard when you have 10,000.

The uncomfortable truth: your first 10 users come from manual work, not marketing. DMs, replies, comments. It doesn't scale — that's the point. Do things that don't scale until you've earned the right to scale.

[yoshibuilds @yoshibuild]

@egych @RomanShalabanov Thank you!
I’ll fix that