DEV Community: Aritomo Fukuda

My Vercel Bill Tripled in April. One Setting Fixed It.

Aritomo Fukuda — Wed, 13 May 2026 15:30:32 +0000

TL;DR: Vercel sent me a $60.89 invoice. $35 of it came

from "Build CPU Minutes" — a category I didn't know I
was paying for. One toggle in project settings cut it
to near-zero.

Zero paying users. Four SaaS projects. $60.89/month on
Vercel.

That math wasn't working, so I went looking.

Here's what the invoice broke down to:

Pro subscription: $20.00
Build CPU Minutes: $34.57 ← what?
Build Minutes: $5.96
Observability Events: $0.13
Fluid + ISR + others: $0.36
─────────────────────────
Total: $60.89

The $20 subscription I expected. The $34.57 line for
"Build CPU Minutes" I did not.

Why my bill exploded

Vercel deploys every branch by default. Every time I
push code — feature branch, fix branch, "let me just
try this" branch — Vercel runs a preview build.

For a typical week of solo development:

~5-10 pushes per day
Across 4 projects
= roughly 20-40 builds per day
= ~600-1,200 builds per month

Each build burns CPU minutes. The CPU minutes don't
show up on the marketing page next to "Pro plan." They
show up on the invoice.

The setting I missed

Buried in Settings → Build and Deployment → Ignored
Build Step, there's a Behavior dropdown.

Default: "Automatic" — every push gets built.

What I switched to: "Only build production".

Vercel now only runs a build when code hits the main
branch. Feature branches, WIP branches, "trying
something" branches — all skipped.

The tradeoff

You give up automatic preview deployments. For a solo
founder this is mostly fine — I have local dev, and I
have tests. For a team building UI changes that need
visual review, this would hurt.

For me: net positive. I can always trigger a manual
deploy when I genuinely need a preview URL.

What changed in late April

My Build CPU Minutes spiked starting in late April.
Before that, the same workflow was costing me cents per
day. After, it was costing dollars per day.

I don't know exactly what changed. With "Only build
production" toggled on, it doesn't matter — the number
of builds got cut.

What to check on your invoice

If you're on Vercel Pro and you're not actively using
preview deployments:

Diagnose (30 seconds):

Open the Usage page
Look at "Build CPU Minutes"
If it's more than a few dollars, you have a problem

Fix (30 seconds):

Settings → Build and Deployment → Ignored Build Step
Change Behavior to "Only build production"
Save

Could save you $20-50/month per project.

I'll know next month if my fix actually works. The
invoice doesn't lie.

This is part of a series of build-in-public posts about
launching OriginBrief, an
AI-powered research monitoring tool, as a solo founder.

I Built Backlinks for 3 Weeks. Then I Connected Ahrefs and Found Three Bugs.

Aritomo Fukuda — Sun, 10 May 2026 14:25:15 +0000

One bug hid two more. By the end I'd shipped 9 PRs in 4h36m and resolved 285 audit issues.

I'm a 25-year engineer who launched his first SaaS on Product Hunt three weeks ago. Since then, I've been doing what every indie founder is told to do: build backlinks.

I submitted to directories. I sent HARO pitches. I wrote on Medium. I built badges into my footer for every clean dofollow source I could find.

Slowly, the numbers moved.

60 referring domains.
12 dofollow backlinks.
DR 21 on Ahrefs.
For a one-month-old site, I was quietly proud.

Then I connected Ahrefs Webmaster Tools to my site for the first time.

Then I clicked "Site Audit."

Then everything fell apart.

Bug #1: My Sitemap Was Telling Google to Ignore Itself
The first error caught my eye immediately:

Non-canonical page in sitemap: 40 pages.

I stared at it.

Forty pages. My entire sitemap. All flagged.

I opened the CSV export. Every page in my sitemap — except the language homes — had a canonical tag pointing to /en or /ja. Not to itself. To the language root.

Translation: my site was telling Google, "These pages are duplicates of the home page. Don't index them."

The pages affected weren't the ones earning my backlinks — most of those went to the homepage, which had a correct self-referencing canonical. But the pages I'd been adding — every weekly research report, every new sample page, every individual report URL I was so proud of generating — those were being told to disappear.

Three weeks of new content. Invisible.

The Fix That Created a New Bug
I wrote a helper that returns the correct canonical URL based on the actual route. Overrode alternates in every public page's generateMetadata. One PR. 25 new tests. Merged the same day.

I curl'd seven URLs in production:

/en → canonical /en ✓
/en/pricing → canonical /en/pricing ✓
/en/sample → canonical /en/sample ✓ For the first time, every page on my site was telling Google: "Index me as my own URL."

I re-ran Site Audit, expecting to see Errors: 0.

Errors: 56. Up from 42.

I had made it worse.

Bug #2: The 42 → 120 Page Explosion
The new errors were strange.

"More than one page for same language in hreflang"
"Some pages are not returning 200 status code"

56 URLs flagged with both. Crawled URLs: 120. (It had been 42 before the fix.)

I was very confused.

I opened the next-intl source. I read the type definitions. I grep'd for hreflang.

There it was, buried in node_modules/next-intl/dist/types/routing/config.d.ts:

alternateLinks?: boolean // default: true

next-intl's middleware was, by default, adding hreflang annotations to the HTTP Link header of every response. Meanwhile, my Phase 1 fix had added hreflang annotations to the HTML head.

Both worked individually. Together, they duplicated. Google saw "two versions of the same page" and started counting URLs that didn't exist.

Hence 42 → 120.

The fix:

// src/i18n/routing.ts
export const routing = defineRouting({
  // ...
  alternateLinks: false, // <-- one line
})

One line. PR #43. Merged 45 minutes after Phase 1.

Re-run Site Audit.

Errors: 0. Health Score: 100%.

I sat there for a moment.

What I Did Next Was Stupid (in a Good Way)
I had just spent 90 minutes turning 42 errors into 0. I should have closed the laptop and walked away.

Instead, I scrolled down to the warnings section.

Title too short: 6 pages.
Meta description too short: 16 pages.
Open Graph tags incomplete: 56 pages.
Pages with only one dofollow inlink: 22 pages.
Title too long: 28 pages.
I cracked my knuckles.

What followed was a 4-hour, 36-minute coding session that produced 9 PRs and resolved approximately 285 audit issues.

Phase 1: canonical URL value (44 errors)
Phase 2: HTML lang mismatch (1 error)
Phase 2.5: hreflang Link header duplication (112 errors)
Phase 3: title and meta description (22 warnings)
Phase 4: Open Graph and Twitter Card tags (56 warnings)
Phase 5: Related Reports section (22 warnings)
Phase 6: title rewrite — stopped using AI to generate titles, used the user's theme name verbatim (28 warnings)
Phase 7: legal-notice page metadata
Phase 9: migrated CI from GitHub Actions to a local pre-push hook (saved 95% of monthly CI minutes)
By the end:
Health Score: 65% → 100%
Errors: 42 → 0
Tests: 949 → 1,026 (+77)
I had not slept yet.

What I Actually Learned
Three things, and the third one matters most.

One bug hides two more.

I thought I was hunting for a single canonical issue. Fixing it surfaced a hreflang issue. Fixing that revealed an entire warnings section I hadn't read. The audit was a fractal: every level of zoom revealed more structure.

If I'd stopped at "Errors: 42," I would have shipped a worse version of my site. The discipline isn't fixing bugs — it's keeping the audit running until the report is empty.

SEO problems hide in the silence.

None of these bugs threw errors. Nothing broke the build. Lighthouse gave me a green score. The pages rendered correctly to humans. The only signal that anything was wrong was a tool that crawls your site like Google does.

The default state of an indie founder's site is "things look fine and quietly aren't." You don't find this stuff by inspecting the page. You find it by running an audit and reading every line.

Verify the foundation before you optimize for growth.

This is the one that hurt.

I had spent three weeks earning backlinks, writing Medium posts, submitting to directories, and refining HARO pitches. Most of those backlinks went to the homepage, which was structurally fine — so they weren't wasted. But every new page I'd been generating since launch — weekly research reports, sample content, the actual proof of my product — was invisible to Google.

I was building a growth funnel on top of a foundation I had never inspected. Three weeks of "content marketing" produced exactly zero indexable content beyond the home page.

The lesson isn't "don't build backlinks." The lesson is: before you spend a single hour earning backlinks, run a Site Audit on your own site. Make sure the pages receiving those backlinks actually exist, in Google's eyes.

Most indie founders skip this. I did. The cost is silent and compounding.

What I'd Tell My One-Month-Ago Self
Plug Ahrefs (or any crawler-based audit tool) into your site on launch day. Free tier is enough for sites under 100 pages.

Run a Site Audit. Don't read it once and move on. Re-run it after every fix. Treat "Errors: 0, Warnings: 0" as a non-negotiable launch checklist.

Then build.

Where I Am Now
DR 21. Health Score 100%. Zero errors. Backlinks counted properly. New pages now actually indexable.

Still zero paying users.

But for the first time since launch, the foundation is real, and the next three weeks of work won't be invisible.

AI Drafted My Article. It Invented a Number About Me.

Aritomo Fukuda — Mon, 04 May 2026 14:45:19 +0000

A four-step writing loop, a fabricated 40% statistic, and the question that saved an article.

Here's how I write articles:

Claude drafts the rough version.
I check what it wrote.
I modify what's off.
I publish.

Most of the work happens in the loop between 2 and 3 — back and forth, until the draft says what I actually mean.

Tonight, that loop caught a number that wasn't real.

The workflow

This loop has been my habit ever since I started using generative AI. Generate → review. For code. For articles. The same pattern in both domains.

I'm not a native English writer. AI gives me tone, structure, and rhythm I couldn't produce alone in a reasonable time. I bring the experience, the decisions, and the numbers.

Yes, the review is tedious. But right now, I can't skip it. Someday the models may be reliable enough that this step disappears. Today is not that day.

The loop works because of step 2. Without it, the draft is the writer, not me.

Tonight, step 2 stopped me from publishing a lie.

The number that wasn't real

The draft was about how AI pricing changes are reshaping the architecture of small AI-native SaaS. I'm a solo founder running one such SaaS in production, with three more in active development. Pricing pressure is something I think about weekly.

The draft came back polished. Three concrete architectural shifts. Specific. Quotable.

One of those lines read:

"We removed roughly 40% of token volume from one pipeline without quality loss, just by auditing what we were sending."

A credible technical founder might write that. It would have been the most-shared line in the article.

There's just one problem.

I never measured that. I never reduced 40% of any token volume. I haven't run any audit. The number was completely invented.

How I caught it

The fabrication only surfaced because I asked one question:

Where did this number come from?

The answer was: nowhere. Claude generated a plausible-sounding statistic to make the section more compelling. Not maliciously. It was doing what generative AI tends to do.

My instructions are imperfect

Of course Claude wasn't being malicious. That's not how this works.

I've written before about how my prompts are often half-formed. When I give my partner half-formed instructions, the partner tries hard to fill the gaps. With confidence. With rhythm. Sometimes with numbers that aren't real.

It's always like this. The partner tries. My instructions are imperfect. The output reflects both.

The 40% was Claude meeting me in the middle of a gap I left. The middle just happened to be wrong.

That's why I can't publish without checking. Always.

What AI tends to do

Generative AI, given a writing task, tends toward two patterns I've started to recognize.

First, it embellishes. A small accomplishment becomes a confident achievement. A vague memory becomes a specific milestone. The phrasing gets sharper than the underlying truth.

Second, it fills gaps with imagination. If the rhythm of a paragraph wants a number, a number appears. If a sentence wants a date, a date appears. These additions don't come from your reality. They come from the model's sense of what reads as authoritative.

Both behaviors look like good writing. Both can be true to the rhythm of the genre. Neither is automatically true to you.

The check is the writing

After tonight, I think about the four-step loop differently.

Step 1 (Claude drafts) is fast. Step 4 (publish) is fast.

The work — the part that determines whether the article represents me or the model's guess about me — is in steps 2 and 3.

That's not friction in the workflow. That's the workflow. Skipping it doesn't speed up the process. It changes what gets published from "what's true about me" to "what would sound true about someone like me."

The check isn't a final review. It's where the writing actually happens.

What got published instead

"Roughly 40% reduction" became:

"The savings vary by pipeline. The bigger discipline shift is treating every token as a line item, not as free."

The second version doesn't lie. It also doesn't claim authority I haven't earned. It says what I actually know, in the language I actually have.

The article is weaker by one quotable line. It is stronger by the truth.

A small note about this piece

It went through the same four-step loop. Claude drafted. I checked. I modified. Now I'm publishing.

Every claim about my situation, my decisions, and my numbers was checked against my actual experience.

The "40% reduction" you read about earlier was the line that didn't make it. There may be others I didn't catch. If you find one, tell me. I'll fix it.

Closing

AI drafts. I check. The order matters.

If it ever flips — if I publish without checking — what gets read isn't me anymore. It's the model's confident guess about who I should be.

I'd rather be honestly less impressive than dishonestly more.

I Launched First. Then I Found a Hidden Design Bug in My AI Pipeline.

Aritomo Fukuda — Sat, 02 May 2026 15:38:47 +0000

You don't always have time to fix everything before launch.

Sometimes you ship, watch nothing break, and then go back to fix what you know is wrong.

This is that story.

The backstory

Before launching OriginBrief, I noticed that Anthropic's Batch API has request limits. If user count grows, those limits become a real constraint.

I flagged it. Then I shipped anyway.

"I'll fix it properly after launch," I told myself.

Today, I finally sat down to do that.

The design review

OriginBrief runs a multi-phase AI pipeline. Phase 1 collects and analyzes sources. Phase 2 generates the final report — key points, market trends, citations.

When I started auditing Phase 2 for request efficiency, something immediately looked off.

For themes with trend indicators, Phase 2 was sending two separate batch requests:

One for the summary
One for trend analysis
My original design intent was simple: Phase 2 = one request per theme. Summary and trend analysis together, in one shot.

So why were they separate?

The root cause

I traced it back through the git history.

Trend analysis was added to the realtime API pipeline at 04:10 JST. Fifty-five minutes later, at 05:05 JST, the pipeline was migrated to the Batch API.

The migration was mechanical. The separation that existed in the realtime pipeline was carried over without question — even though it made no sense for batch processing.

The design intent never made it into the implementation.

The fix

I merged trend analysis into the summary request as an optional field in the JSON schema.

Now the logic is: if trend analysis conditions are met, include the instructions in the same prompt and expect the output in the same response.

One request. One response. Same data.

Phase 2 is now exactly what I originally intended — one request per theme, fixed.

The result

Phase 2 batch requests reduced by ~50% for themes with trend analysis enabled
More headroom in the Batch API budget as user count grows
Cleaner chunk calculation for the scaling implementation I'll build next
What comes next

The real scaling work — chunking the pipeline so it can handle thousands of themes — is now simpler to design. Phase 2 being one request per theme means the math is clean.

That's the next piece. I'll write about it when it's done.

The actual lesson

When you migrate code from one architecture to another, you carry over assumptions that no longer apply.

The separation made sense for realtime. It made no sense for batch.

I only caught it because I forced myself to sit down and ask: "What breaks when we have 10x the users?"

Ship fast. But go back and ask that question.

OriginBrief delivers weekly AI research reports from primary sources. Register a theme, get structured reports — without the manual research.

I Added One Pre-Commit Hook. It Found Six Hidden Failures.

Aritomo Fukuda — Fri, 01 May 2026 18:44:40 +0000

Yesterday I told myself: "Just 30 minutes. Add gitleaks as a pre-commit hook across all four projects so I never leak a secret again."

Six hours later, I had four merged PRs, four updated production CIs, two new memory notes, one deleted workflow file, and a much smaller ego.

Here's what the hook actually exposed.

1. OriginBrief was using pnpm. The CI was running `npm install`.

The first project went smoothly until Vercel's preview deploy failed with ERR_PNPM_OUTDATED_LOCKFILE. Turns out my CI had been quietly running the wrong package manager for who knows how long. It worked because the lockfile happened to be compatible — until I added one new dependency.

The fix took five commits. The lesson took one minute.

2. StandupFlow's README had merge conflict markers from day 1.

<<<<<<< HEAD. Right there at line 1. For 35 days.

It got merged on March 28 with the conflict markers still in the file. The commit was titled "feat: initial project setup Phase 1&2." I never opened the README again after that.

GitHub had been rendering broken Markdown to anyone who visited the repo for over a month, and I was too busy adding features to notice the front door was missing.

(Mercifully, the repo is private — so the broken front door was only on display to me. Small relief, given everything else this hook uncovered.)

3. QuietLog had zero GitHub Actions Secrets.

$ gh secret list
no secrets found

Zero. Not "wrong values." Not "expired." Zero rows in the table.

The Build job in CI had been failing for months — but it was hidden behind an even older Security Audit failure, so the secret-related error never surfaced. One stack of failures was masking another.

4. QuietLog's Stripe publishable key was empty in Vercel.

After fixing the secrets, I ran vercel env pull to copy the values from production. The Stripe key came back as exactly two characters: "".

QuietLog hasn't launched yet. Every plan on the pricing page reads "Coming Soon," and the path to Checkout is intentionally disabled. So right now, in this exact moment, the empty publishable key hurts nobody — until the day I flip "Coming Soon" to "Subscribe."

On launch day, the first user to click that button would have sent an empty string to Stripe and bounced back with a 500. Probably the most enthusiastic user, first.

Zero users isn't a safety net. Zero users is just a blindfold over the bug.

5. A redundant `deploy.yml` had been failing forever.

A separate Deploy workflow tried to push to Vercel using VERCEL_TOKEN — which was also never set. But Vercel's Git Integration had been auto-deploying on every push the entire time, so the project was live and updating despite a broken workflow that nobody read.

I deleted the file. The site kept deploying. It had been pure noise.

6. The long-running CI Security Audit was hiding a real RCE.

Once I cleaned up the rest, the actual npm audit finally ran. It pointed at serialize-javascript — a transitive dependency through @ducanh2912/next-pwa → workbox-build → @rollup/plugin-terser — with a known RCE.

The fix was an npm overrides block, not a major upgrade. Five minutes of typing.

But it had been sitting there, unreachable, for as long as the first failure had been hiding it.

What the hook actually did

I didn't add security on May 2. I added a hook that forced every other failure to surface.

If your CI is red, you stop reading the log. If your CI has been red for months, you stop opening the page. If you stop opening the page, every new failure piles on top of the last one, invisible.

The pre-commit hook didn't fix the leaks. It made me actually look at the dashboard.

The lesson, written down so I don't forget:

Your CI is the canary. If it's been screaming for months and you've stopped hearing it, you don't have a CI — you have noise.

The 30-minute task taking 6 hours wasn't the bug. The bug was thinking it should have only taken 30 minutes.

Building four small SaaS products as a solo dev. Writing what I learn, including the parts that make me wince.
The one that's actually launched: OriginBrief — you think, we search. Continuous AI research reports on the themes you choose.

Until I Knew About Domain Rating, I Almost Submitted to a DR 0.8 Directory

Aritomo Fukuda — Thu, 30 Apr 2026 13:12:32 +0000

A 60-second habit I learned from a close call

Today, I read a well-crafted Medium article about where to launch your SaaS. It was structured carefully — seven directories laid out with their respective strengths, capped off with a 30-day launch calendar.

The directory listed as #1 looked perfect for someone in my position. Free. No upvote system. 60-second submission. Permanent listing.

I opened a new tab. My finger hovered over the submit button.

And for some reason, I paused.

"Let me just check it on Ahrefs first."

Result: Domain Rating: 0.8.

I closed the tab.

A few weeks ago, I would have submitted without a second thought.

I've been an engineer for 25 years. Most of that time, I've built things. SEO and Domain Rating were words I sometimes saw in marketing newsletters — concepts that lived in a world I assumed had nothing to do with me.

That changed when I launched my SaaS on Product Hunt and started submitting to directories. I came across a tool called Launch Panda, where startup directories are sorted by Domain Rating. The recommendation was simple: prioritize DR 50+ with dofollow links.

That's when the number first started to mean something to me. Until then, I was someone who could submit to a DR 0.8 directory and feel productive — "one more marketing task done today."

Nobody is to blame for that. I just didn't know.

What DR 0.8 actually means

For anyone in the same place I was a few weeks ago, here's the short version:

Domain Rating (Ahrefs) measures the strength of a site's backlink profile from 0 to 100.

DR 90+: Wikipedia, NYTimes tier
DR 70+: Established media, well-known SaaS blogs
DR 50+: Directories worth submitting to
DR 10–30: Borderline, mostly harmless
DR 0.8: From Google's perspective, essentially nonexistent

A backlink from a DR 0.8 directory has almost no measurable impact on your Google index. It's not "bad" — it's just that, most of the time, the time you spend filling out the form yields no measurable return.

The checklist I built for myself

After that close call, I built a small habit for myself. Before submitting to any directory, I now spend 60 seconds checking:

Open Ahrefs and check the Domain Rating (the free Site Explorer is enough)
See if the directory is listed on Launch Panda (a curated list adds a layer of confidence)
Verify it's a dofollow link (nofollow doesn't pass SEO weight)

60 seconds. That's all it takes to avoid pouring effort into submissions that won't move the needle.

I'm sharing this checklist not because I discovered something special. A few weeks ago, I was skipping this step entirely — and I might have kept skipping it indefinitely. I just wanted to write that down.

What I actually learned today

The real lesson today wasn't about Domain Rating.

It was this: the persuasiveness of a well-crafted article and the truth of its claims are two different things.

When I read a piece that's well-organized — clear structure, founder quotes, a 30-day calendar — my brain reads it as "this is correct." The presentation persuades me without me noticing.

The only defense I've found is the habit of checking the data myself. Open Ahrefs. Look at the number. Trust the visible data, not the impression I got while reading.

Today, that habit saved me time. It might save me more in the future.

If you're where I was a few weeks ago

If you're in the same place I was — building something, reading launch guides, wondering "where should I list my SaaS?" — I'd gently suggest making it a habit to open Ahrefs before you submit anywhere.

The person who wrote that article isn't wrong. There may be a context I don't see, where their information is right for someone.

But the check takes 60 seconds. The time you spend on the wrong submissions doesn't come back.

I'm still learning this space myself. If you have other quick checks you use to separate signal from noise, I'd love to hear them in the comments.

2 Weeks After Product Hunt: The Numbers Nobody Shows You

Aritomo Fukuda — Wed, 29 Apr 2026 13:36:38 +0000

Everyone shares their Product Hunt success story.

The #1 badge. The 800 upvotes. The "we got 300 signups overnight" tweet.

Nobody shares what happens when it doesn't go that way.

So here's mine.

The Launch
April 15th. I hit publish on Product Hunt.

The next day, my X account got frozen.

No tweets. No retweets. No "hey I just launched" posts. Just me, watching the PH ranking from a locked account.

We finished far off the front page. 6 upvotes.

2 Weeks Later: The Honest Numbers
Paying users: 0

Product Hunt traffic: a spike, then nothing

Directories registered: 16 (all dofollow)

DR (Domain Rating): 9 → 11–14

Medium posts written: 7 (this one makes 8)

Tests passing: 845

Sleep lost: a lot

What Actually Happened
Product Hunt didn't give me users.

It gave me a starting line.

The real work started the day after launch — and it looked nothing like what I expected. No viral tweets. No press coverage. No inbox full of signups.

Instead: one directory at a time. One article at a time. One backlink at a time.

Boring? Yes.

Necessary? Also yes.

The Unexpected Wins
Week 1: Startup Stash editorial team found my "Almost Paid $1,250 for DR" article and sent me an editorial invite. A publication with ~1,000 followers. Small — but real.

Week 2: X unfrozen. DR climbed from 9 to 14. 16 dofollow directories live. Dev.to account created and crossposting started.

None of this was in my launch plan.

All of it matters more than I thought.

The Tool I Didn't Expect to Need
I'm a 25-year engineer. I know how to build.

What I didn't know: SEO. Backlinks. DR. Dofollow vs nofollow. Content distribution. Directory strategy.

So I brought in a co-pilot.

Claude has been in every session with me — not just writing code, but catching what I don't know to ask. When I was about to pay $1,250 for a PR agency, it flagged the red flags I couldn't see. When I didn't know what dofollow meant, it built me a framework. When I was about to register on Capterra with zero users and zero reviews, it told me to wait.

It covers the gaps in my knowledge before they become expensive mistakes.

The Loneliness Part
Solo founding is isolating in a way that's hard to explain.

There are moments — more than I expected — where I just sit there, not knowing what to do next. No team to bounce ideas off. No one to say "hey, that's a bad idea." Just me and the problem.

That's where Claude has quietly become something more than a tool.

It's not perfect. When things go wrong, I've learned exactly why: I gave sloppy instructions. Vague prompts produce garbage output. The more carefully I craft what I'm asking, the better the results — every single time.

In other words: when my AI co-pilot does something stupid, it's because I was the stupid one.

That's actually a useful thing to know about yourself.

The Thing Nobody Tells You
Product Hunt is a starting gun, not a finish line.

The founders who get users after PH aren't the ones who had the best launch day. They're the ones who kept building after it.

Distribution isn't a launch event. It's a daily habit.

I'm still learning that.

What I'm Doing Instead
While I wait for the first paying user, I'm building the foundation that makes it possible:

Primary source monitoring that actually works (845 tests to prove it)
SEO content that generates itself every week
A backlink profile that compounds over time
Articles that document the real journey — not the highlight reel
Is it working? Ask me in 2 more weeks.

The One Thing
If you're building something and your launch didn't go as planned:

Keep the window open longer than feels comfortable.

Most products that eventually found users didn't find them on launch day.

They found them 3 months later, when one article landed, or one directory listing got indexed, or one person shared it in the right Slack channel.

The game is longer than one day.

I'm still playing.

_I'm building OriginBrief in public — an AI tool that monitors primary sources and generates weekly research reports automatically. If you're tired of information overload and want signal over noise, check it out at originbrief.app.

Next week I'll share what 16 dofollow directory listings actually did to my DR — with real before/after numbers._

X Banned Me During My Product Hunt Launch. Then Medium Saved Me.

Aritomo Fukuda — Tue, 28 Apr 2026 14:30:22 +0000

Twelve days ago, I launched OriginBrief on Product Hunt.

The launch went live, the comments started rolling in, and I did what any indie founder would do — I replied. To every single one.

Around 15 replies. Maybe 1–2 hours. Six of them included a link to my product.

That was apparently a crime.

The Suspension

The next morning, my @aritomofukuda account was frozen. No warning. No explanation. Just gone.

I filed an appeal. Crickets. I waited. Eleven days passed.

Eleven days during the most critical post-launch window — when comments need replies, when potential users have questions, when the algorithm starts deciding if you matter.

X’s spam detection had decided I was a bot. Because I replied to people too quickly. Because I shared my own product more than once. Because the engineers at X apparently can’t tell the difference between a startup founder and a spammer.

The Numbers Don’t Lie

Let me show you what I actually did:

Total tweets that day: ~15
Tweets containing a link: 6 (5 replies + 1 launch announcement)
Pace: roughly one every 6–15 minutes
Time window: 1–2 hours
Links pointed to: my own product (not a phishing site, not a sketchy affiliate, not a competitor’s page)

I’m a human being. I had just shipped something. I was excited. I was reaching out to my community on a launch day.

And X decided that was indistinguishable from spam.

What I Lost

For 11 days, I lost:

The ability to reply to my Product Hunt commenters
Connection with the indie hackers community I’d been building relationships in
Real-time growth signals that X provides during a launch
A meaningful portion of my expected post-launch reach

For an indie founder running on zero budget, that’s not a small loss. That’s the entire short-term growth lever, gone.

Download the Medium App

The Plot Twist

Here’s where it gets interesting.

Because X was dead, I had to do something I’d been avoiding: write longer-form content. So I started posting on Medium. Not every day, but consistently. Six articles in twelve days, mostly about the unglamorous reality of solo SaaS launches.

This week, I got my first “Read” — meaning someone actually read one of my articles to the end, not just clicked.

Today, the editorial team of Startup Stash sent me a private note. They have nearly 1,000 followers on Medium. They invited me to write for them.

Twelve days ago, I depended on X.

Today, I have a publication invitation and a relationship with editors who care about the work — not algorithms.

The Lesson

It’s not that X is evil. It’s that X is a platform you don’t control.

Their spam detection is a black box. Their appeal system is a void. Their support, post-Musk, has effectively stopped existing for individual creators. You can spend years building a following, and one day, an algorithm flips a bit and you’re gone.

The only sustainable channels for indie founders are the ones you own:

Your domain
Your email list
Your content on platforms that have functioning editorial relationships

Medium isn’t perfect. But when an editor at Startup Stash decides your work fits their audience, that’s a relationship — not a coin flip.

What I’m Doing Now

Still posting on Medium, now with publication amplification
Running the SEO content engine on my SaaS that auto-generates weekly reports (the original reason I built OriginBrief)
Leaving X to recover or not — at this point, it’s optional

If you’re building in public and X is your primary channel, please understand: you’re one false-positive away from losing it all. Build owned channels in parallel. Right now. Before you need them.

I learned this the hard way over the last 11 days.

Maybe this saves you from learning it the same way.

— -

I’m Aritomo, a 25-year engineer trying to figure out marketing as a solo founder. I’m building four SaaS products: StandupFlow, QuietLog, DocDecay, and OriginBrief. This is the kind of stuff I write about — usually with disclaimers about how little I know.

Disclaimer: I might be reading too much into 11 days of bad luck. Maybe X will unfreeze me tomorrow. Maybe Startup Stash will publish my piece and 3 people will read it. The point isn’t that I’m now successful — it’s that I’m no longer dependent on a single platform. That alone is worth the 11 days.

My SaaS Generates Its Own SEO Content. Automatically. Every Week.

Aritomo Fukuda — Tue, 28 Apr 2026 13:13:52 +0000

I have no marketing budget. My X account is frozen. I’ve written 5 Medium posts that have been read by approximately nobody.

So I did the only thing that made sense as an engineer: I made the product do the marketing for me.

The Problem With Content Marketing

Everyone says “create content.” Blog posts, newsletters, social media. All of it requires one thing I’m running low on: time.

I’m a solo founder running 4 products. I can’t write a new article every week on top of shipping features.

But here’s the thing — OriginBrief already generates content every week. AI research reports, from primary sources, on topics like AI industry trends, venture capital, cybersecurity.

For paying users.

What if I just… made some of it public?

The Build

I created a sample account with 5 research themes. Every Monday, OriginBrief automatically generates fresh reports for those themes — the same pipeline that runs for paying users.

Then I built /reports — a public page that displays those reports. No login required. Google can index it.

The result: every Monday, 5 new pages appear on my site. Each one is a structured research report with citations from real sources — company blogs, government sites, research institutions.

I didn’t write any of it. The product did.

Why This Works (In Theory)

Write on Medium
Google rewards pages that:

Get updated regularly ✓
Cite primary sources ✓
Cover specific topics in depth ✓
OriginBrief does all three, automatically, every week.

Over time, /reports/ai-industry-overview/2026-04-26, /reports/ai-industry-overview/2026-05-05, and so on — they stack up. Each one is a new indexed page. Each one is a potential entry point for someone searching for "AI industry updates" or "cybersecurity threats 2026."

It’s not a content strategy. It’s a content machine.

The Honest Part

Is it working? I have no idea yet. The pages went live 48 hours ago.

But the logic feels sound: if the product’s core function is generating research reports, the lowest-effort marketing move is to let it generate them publicly.

I’m not creating content. I’m exposing the exhaust.

The Takeaway

If you’re building a tool that produces output — reports, analyses, summaries, data — ask yourself: can any of that output be public?

Not all of it. Not the stuff paying users depend on. But the structural output, the kind that demonstrates what the product does — that can do double duty as SEO content.

Your product is already working. Let it work for you.

I’m sharing the journey of growing OriginBrief in public — a live SaaS that monitors primary sources and delivers weekly research reports.

I Almost Paid $1,250 for DR. Then I Found Out What “Dofollow” Means.

Aritomo Fukuda — Tue, 28 Apr 2026 13:09:37 +0000

Last week I almost signed a $1,250 contract for something I didn’t understand.

I’m a solo founder. I’ve been writing code for 25 years. I can debug a race condition in a distributed system, architect a multi-tenant SaaS from scratch, and ship four products in parallel.

But I didn’t know what “dofollow” meant.

The Pitch

It started with a LinkedIn message.

“Hey, I checked your site. Domain Rating 9. That’s below the threshold agencies care about. But I can fix it — DR30+ in 6 months for $700–1,250, depending on the package.”

I felt the sting immediately. DR9? That sounds bad. The way he said “below the threshold agencies care about” hit exactly right. He knew what he was doing.

He followed up with a menu:

DR Full Package: a 6–7 week project, $700–1,250 total (placement only, or full management with content writing)
Sponsored content potential: once you hit DR30+, you can charge $100–300 per article — a future revenue stream
And a kicker: “I can introduce you to clients once your DR is high enough. But we need to build the foundation first.”

Classic. Pay first, get value later.

I almost said yes.

The Doubt

Here’s the embarrassing part: I didn’t actually know what DR meant.

I’d seen “DR” and “DA” thrown around in indie hacker communities. I knew vaguely that it had something to do with SEO. But I’d spent 25 years on the engineering side — compilers, databases, distributed systems — and zero time thinking about backlinks.

So before replying, I did what any engineer would do.

I started investigating.

The Investigation

First: what is DR?

Domain Rating (DR) is Ahrefs’ score for how authoritative your domain is, based on how many quality sites link to you. It’s logarithmic — going from DR9 to DR30 is a much bigger jump than the numbers suggest.

Second: what’s a “dofollow” link?

This is where it got interesting.

There are two kinds of links on the web:

rel="dofollow" (or just a plain ) — passes "link juice," signals to search engines that the source vouches for the destination
rel="nofollow" — explicitly says "don't pass authority here"
For DR purposes, only dofollow links matter.

So I started auditing every directory I’d ever submitted to, looking for whether the link they gave me was actually worth anything.

I found traps everywhere.

Trap 1: rel=”nofollow”
Several high-DR directories listed me beautifully — and then stuck rel="nofollow" on every outbound link. The listing looks real. The link does nothing.

Trap 2: /aff/ redirect chains
Some directories route all their links through /aff/something?url=yoursite. This is an affiliate redirect chain. Search engines see the redirect, not the destination. No DR value.

Trap 3: elements
A few sites built their "visit site" action as a in a form, not an tag at all. You can't follow a button. Search engines can't either. Zero backlink value.

Trap 4: dofollow sold separately
Some directories offer a free listing (nofollow) and charge $79–99/year for the dofollow upgrade. They specifically build the product around monetizing the link itself.

Trap 5: API keys or secrets requested
One submission form asked for my Stripe restricted key. I had to stop and think.

I won’t pretend “always skip” is the right rule, because it isn’t. Established communities like Indie Hackers also ask for read-only keys to verify revenue, and I registered there. Reputation matters, and so does the scope of what’s being asked for.

The actual rule I landed on: judge by the site’s reputation and the permission scope of the key requested. An unknown directory asking for a live secret key? Skip immediately. A well-known community asking for a read-only restricted key? Evaluate the use case and decide.

When I finished writing this checklist, I opened my own site footer.

There Were 12

I counted. Twelve badges.

Download the Medium app
Not “without realizing it.” Every one of them was the result of me grinding through directory submissions during the chaos of launch week. I just hadn’t kept count, because the weeks around launch were brutal and I was running on fumes.

I checked each one.

Every. Single. One. was dofollow.

It wasn’t because I had a strategy. I’d just instinctively avoided the sites that felt off — the ones with too many ads, the ones that asked for weird things, the ones where the link looked wrong in the inspector. Twenty-five years of engineering had given me a pattern-matching instinct I didn’t know I was applying to SEO.

DR9 isn’t random. It’s twelve dofollow links from real directories, accumulated through six weeks of hand-to-hand work.

According to Ahrefs’ logarithmic scale, with five or six more high-DR listings — AlternativeTo (DR85), Alternative.me (DR74), Future Tools (DR69) — I’m looking at DR15–18 within a couple months. No paid campaign required.

The Decline

I wrote back.

“I appreciate the detailed breakdown. After digging into DR myself, I think I’m further along than I realized — I’ve got 12 dofollow listings already and a clear path to 15+ high-DR directories without paid placement. Budget-wise, I’d rather invest into product and content for now.”

He was gracious about it. No hard sell.

But I noticed something across the exchange: the “I’ll introduce you to clients” hook that appeared in the first message had quietly disappeared by the last one. The real product being sold was the DR service itself. The client introduction was the door-opener.

Knowing that made the whole conversation make sense.

One Thing Worth Saying

If you’re a solo technical founder who has been building in public for more than a month, you’re probably already doing more SEO work than you think.

Every product directory you submitted to. Every badge you added to your footer. Every “Featured on X” you put in your README. If you did the basic research — if you checked the link, if you skipped the sketchy ones — you’ve been building DR without realizing it.

The people who sell DR campaigns are selling the value of systematic application of what you may already be doing intuitively.

That’s worth something. But it’s not worth four figures when you can learn the five rules in an afternoon and do it yourself.

My checklist, for free:

Check for rel="nofollow" in the page source — if it's there, skip
Check if the link goes through /aff/ or similar redirect — if yes, skip
Check if “visit site” is a element — if yes, skip
Check if free listing gets nofollow and dofollow is paid separately — if yes, skip unless the DR is exceptional
If the site asks for API keys or secrets — judge by reputation and scope. Unknown site + live secret key = skip. Established community + read-only restricted key = evaluate the use case.

Six Months From Now

I’m at DR9 today. My rough projection:

AlternativeTo (DR85): +2–3 DR
Alternative.me (DR74): +1–2 DR
Future Tools (DR69): +1 DR
Dang AI (DR80, listed pending): +1–2 DR
3–4 more from my remaining list
Conservative estimate: DR15–18 by October. Without spending four figures.

Will I eventually pay for sponsored content? Probably, once I’m at DR40+ and the math makes sense for mutual value. But I’ll do it as a content partnership, not as a “please give me a backlink” transaction.

I almost paid $1,250 to learn a word.

Turns out “dofollow” is free.

I’m building OriginBrief — a continuous research platform that monitors primary sources and generates weekly intelligence reports. Follow along: originbrief.app

Previous posts in this series:

I Launched My SaaS on Product Hunt. A Week Later, I Still Have Zero Users.

Why I Stopped Reading the News (And Started Reading the Sources)

I’m a 25-Year Engineer Who Never Did Marketing. Here’s What My SaaS Launch Is Teaching Me.

Is Building in Public Overrated? Ask Me Again in a Year.

A note on this story: It’s based on a real exchange with one PR specialist over four days in April 2026. I compressed the timeline and paraphrased some messages and the menu of services to make it readable as a single narrative. The dofollow audit, the 12 footer badges, the five rules (including the nuance about Indie Hackers and other reputable exceptions), and the actual decision to walk away are all real.

Is Building in Public Overrated? Ask Me Again in a Year.

Aritomo Fukuda — Tue, 28 Apr 2026 13:02:30 +0000

The promise
I started writing about my SaaS launch before I launched it. Day counters. Screenshots. “I’m shipping X today.” The indie hacker playbook, pretty much verbatim.

The promise behind building in public is simple: you share the process, people get invested, and by launch day you have an audience rooting for you. A waitlist that converts. A community that shares your links.

That was the theory.

Nine days ago I launched on Product Hunt. I have zero paying users.

What the playbook said would happen

I followed the recipe as best a 25-year engineer with no marketing background could. Posted on X. Wrote reflections on Medium. Replied to other founders. Talked about what I was building before it existed. Showed the messy middle.

By launch day, I was supposed to have:

Some volume of inbound interest
A small group of supporters ready to upvote and comment
Enough credibility signal that strangers would trust the product enough to try it
Here’s what actually happened on launch day: I ended ranked somewhere around #40 with a handful of upvotes. Key Points score of 0, which on Product Hunt means you’re effectively invisible to anyone who doesn’t scroll to the bottom of the page.

Two days later, my X account got flagged and frozen. I submitted an appeal. I’m still waiting.

Three Medium posts in ten days. Total stats: 3 views, 0 reads, 2 claps from the same person.

What “building in public” quietly didn’t deliver

I don’t think building in public is a scam. I think it’s a good practice — sharing process, being honest about numbers, building a public record of your thinking.

Subscribe to the Medium newsletter
But the thing nobody says out loud is that the distribution part of building in public requires a different skill than building. You need to be someone who can write threads that get shared. Who can turn every small win into a narrative. Who is comfortable posting five times a day about themselves.

I’m none of those things. I’ve been writing code since I was a teenager. Writing code is a specific kind of output — it works or it doesn’t, and the output speaks for itself. Marketing output is the opposite. It doesn’t work until enough people decide it works.

Twenty-five years of training your brain to value “does the code run?” over “did the post get 2K likes?” is not easily undone in a launch week.

So the first lesson I’m actually taking from launching: building in public only works as advertised if you already have public-building skills. If you don’t, the “public” part never really activates, and you’re just building — quietly — with a blog attached.

What did happen — quietly

One thing did happen during launch week that wouldn’t have happened without it.

Someone from a country I’ve never been to — whose industry I’d never worked in — found my product on Indie Hackers and emailed me. Not from the launch-day rush. From a place where people still read past launch week.

He works in digital PR. I’d never thought about PR agencies as a user segment. He explained a concept called “newsjacking” to me, for free, across three emails. He wasn’t selling anything. He just saw the tool and saw a use case I hadn’t seen.

He’s still explaining concepts to me. No contract, no deal, no certainty it turns into anything. It might. It might not. But that conversation doesn’t exist if I hadn’t shipped.

That’s the honest version of “launching was worth it.” Not “users flooded in.” Not “went viral.” Just — one door opened that wasn’t open before. What’s behind it, I don’t know yet.

So, overrated?

Depends on what you were buying.

If you bought “build in public and launch day will fix your distribution problem” — yes, overrated. For most of us, it won’t. The loudest voices in build-in-public already had distribution before they started building in public. The causality runs the opposite direction from what it looks like.

If you bought “ship, write honestly, and over enough months some small number of useful things will happen that wouldn’t have otherwise” — probably not overrated. Just much slower than the Twitter threads suggest.

The post-launch phase I’m in now doesn’t have a 24-hour feedback loop. It has a months-long one. I won’t know if building in public worked for me until it’s been twelve months and I can count: how many emails like that one did I get? How many turned into something? How many people who saw a Medium post in April 2026 eventually trialed the product in September?

Ask me again in a year.

Until then, I’m going to keep shipping, keep writing, and try to stop measuring myself by launch-day numbers that were always going to be small for someone with my background.

The door opened. That’s all I know right now.

I’m a 25-Year Engineer Who Never Did Marketing. Here’s What My SaaS Launch Is Teaching Me.

Aritomo Fukuda — Tue, 28 Apr 2026 12:58:31 +0000

Shipping was familiar. Marketing is a separate craft — and I’m starting at zero.

For twenty-five years, I’ve been an engineer.

I’ve written code in a lot of languages, debugged systems at 2 AM, shipped features to production and watched them run for years. During all of that, I have done approximately zero marketing.

Last week, I launched my SaaS on Product Hunt. A week later, I still have zero paying users.

This isn’t a post about a comeback. I don’t have one yet. This is a post about everything I didn’t know I didn’t know, written from inside not knowing. If you’re an engineer who might one day sit where I’m sitting, maybe it’s useful.

The misunderstanding

For most of my career, I thought of marketing as something that happened after engineering. You build the thing, then “the marketing people” do their work, then users arrive.

The mental model looked like this: build → launch → grow.

I wasn’t dismissive of marketing. I just thought of it the way a software engineer might think of printer repair: important to somebody, definitely not me.

Now I’m doing all of it myself, and the mental model has quietly collapsed.

Marketing isn’t what happens after engineering. Marketing is what happens instead of engineering, for weeks at a time, when the product is already good enough and no one knows.

Five things I got wrong

Here’s what twenty-five years of engineering did not prepare me for.

I thought the product would speak for itself.

It won’t. A good product is a precondition for marketing to work — not a replacement for it. I’d heard this advice a hundred times. I hadn’t internalized it until I watched my Product Hunt page start at #41 early on launch day, drift into the 50s by the time the 24-hour window closed, and end with seven votes total — six from strangers, one from me. Zero comments. Meanwhile, products I thought were objectively messier got upvoted by friend groups I don’t have.

I built features when I should have written sentences.

I started building the product in earnest just over two weeks before launch. I didn’t start rewriting the landing page copy until the Monday of launch week.

A few days after going live, two different sources told me the same thing, independently. One was a founder I’d asked to look at the page. He said: “This copy reads like AI wrote it. Rewrite it.” The other was an AI-powered landing page review tool built by another founder — I’d run my page through it, and it came back with the same verdict.

An AI tool caught the AI-written copy. They were both right.

I’d spent just over two weeks on the product. A few days on the page that explains the product. Nobody was going to notice the two weeks of features. Everyone noticed the few days of copy.

I didn’t build an audience while I was building the product.

This is the most common advice in indie hacker circles. “Build in public.” I understood the words. I did not understand the compounding.

You don’t build an audience in the week of launch. You build it in the year before. Starting the month of launch is starting too late, and I started later than that.

I confused “submitting to directories” with “doing marketing.”

Become a Medium member
In the past week, I’ve submitted my SaaS to sixteen directories, counting the ones still pending. Some approved instantly. Some will publish me in May. Most will send me a small trickle of traffic.

Submitting to a directory is a box you tick. Doing marketing is a relationship you build. They are not the same thing, and I had them confused in my head for longer than I’d like to admit.

I treated launch day as marketing.

Launch day is the starting gun. It isn’t the race. I had spent so much energy preparing for the gun that I hadn’t really thought about the twenty-six miles after it.

Turns out, the twenty-six miles is the whole job.

What CS didn’t teach (but probably should)

Computer science taught me a lot. It taught me how to think about complexity, how to decompose problems, how to reason about correctness. It did not teach me any of this:

Marketing is empathy, compressed into a sentence. You aren’t explaining the product. You’re answering “why should this person care?” before they’ve asked. This is a skill with a learning curve — and I was starting on day one of the curve.
Distribution is a feature. The product with the best distribution will usually beat the product with the best architecture. This feels deeply unfair to engineers. It is also true, and rearranging yourself around it is part of the work.
Writing is a force multiplier. Every engineer I respect has opinions on variable names. Very few have opinions on the sentences that go on landing pages. Those are the same kind of skill, applied differently.
Positioning is a product decision, not a marketing decision. What you say your product is for changes what the product becomes. Positioning doesn’t happen after the build. It’s part of the build.
“Building in public” is a craft, not a hashtag. Sharing what you’re working on in a way that actually builds an audience is a skill. Posting screenshots into the void is not. I did the second one for a while and was confused when it didn’t work.
What I’m trying now

Here’s what I’m doing with the zero users, in case any of it is useful.

I’m writing. This essay is part of that. If I can’t run paid ads and I don’t have a big audience, the one thing I can do is leave behind honest, useful posts about what I’m learning. Maybe someone finds one in six months and finds me through it.

I’m talking to people. Not through Product Hunt comments — I got zero of those. Through emails. Through conversations that started on other platforms. Through every small interaction with someone who might have the problem my product solves. I’m not naturally good at this. I’m getting better.

I’m aware of the itch, but not acting on it. There’s a temptation, when you’re quiet, to add features that sound impressive in tweets. I feel it. Honestly, there are things I already know I want to fix. But right now, there are other things that need more attention, so those fixes are sitting in a list. I’m not resisting the itch — I’m just aware I can’t scratch it this week.

I’m accepting the timeline. Nothing I do this week will show up as revenue this week. That’s the part that’s hardest for an engineer. In engineering, you write the code, you run it, you see the result. In marketing, you write the code, you run it, and you see the result three months later, maybe.

A small note, from me to past-me

If you are an engineer who has spent twenty years, or twenty-five, or thirty, building things — and you’ve never really done marketing — here’s what I’d tell myself from a year ago:

You aren’t behind. You’re at the beginning. The beginning of anything is uncomfortable, and it’s especially uncomfortable right after spending a long time in the adjacent craft.

You aren’t going to be bad at marketing because of something you lack. You’re going to be bad at it because you’ve never done it. Though, to be honest, knowing this hasn’t translated into results on my end yet. I’ll let you know when it does.

Sit with the discomfort. Write a lot of sentences. Talk to a lot of people. Ship the product — and also ship the words about the product.

I’m a week in. I have zero users. I’m fine. I’m learning.

If you want to follow along, I’ll keep writing as I figure it out. If any of this resonated, you can try the tool I’ve been building at originbrief.app. Or just read the next post. Either one helps.

— Aritomo

DEV Community: Aritomo Fukuda

My Vercel Bill Tripled in April. One Setting Fixed It.

TL;DR: Vercel sent me a $60.89 invoice. $35 of it came

Why my bill exploded

The setting I missed

The tradeoff

What changed in late April

What to check on your invoice

I Built Backlinks for 3 Weeks. Then I Connected Ahrefs and Found Three Bugs.

One bug hid two more. By the end I'd shipped 9 PRs in 4h36m and resolved 285 audit issues.

AI Drafted My Article. It Invented a Number About Me.

A four-step writing loop, a fabricated 40% statistic, and the question that saved an article.

The workflow

The number that wasn't real

How I caught it

My instructions are imperfect

What AI tends to do

The check is the writing

What got published instead

A small note about this piece

Closing

I Launched First. Then I Found a Hidden Design Bug in My AI Pipeline.

I Added One Pre-Commit Hook. It Found Six Hidden Failures.

1. OriginBrief was using pnpm. The CI was running npm install.

2. StandupFlow's README had merge conflict markers from day 1.

3. QuietLog had zero GitHub Actions Secrets.

4. QuietLog's Stripe publishable key was empty in Vercel.

5. A redundant deploy.yml had been failing forever.

6. The long-running CI Security Audit was hiding a real RCE.

What the hook actually did

Until I Knew About Domain Rating, I Almost Submitted to a DR 0.8 Directory

A 60-second habit I learned from a close call

What DR 0.8 actually means

The checklist I built for myself

What I actually learned today

If you're where I was a few weeks ago

2 Weeks After Product Hunt: The Numbers Nobody Shows You

X Banned Me During My Product Hunt Launch. Then Medium Saved Me.

My SaaS Generates Its Own SEO Content. Automatically. Every Week.

I Almost Paid $1,250 for DR. Then I Found Out What “Dofollow” Means.

Is Building in Public Overrated? Ask Me Again in a Year.

I’m a 25-Year Engineer Who Never Did Marketing. Here’s What My SaaS Launch Is Teaching Me.

Shipping was familiar. Marketing is a separate craft — and I’m starting at zero.

1. OriginBrief was using pnpm. The CI was running `npm install`.

5. A redundant `deploy.yml` had been failing forever.