DEV Community: Just a Side Project

I Compared My $0 Blog to 5 Blogs That Publish Their Real Income Numbers

Just a Side Project — Mon, 05 Oct 2026 12:37:32 +0000

This blog has made exactly $0. Not "not much" -- zero, from zero ad impressions served, zero affiliate links clicked, zero anything. So instead of writing another post about my own numbers, I spent an afternoon reading five blogs that publish their actual income, to see what a monetized blog post looks like structurally, since I clearly haven't figured that part out.

Blog	Monetization	Verified figure (source: their own income-report post)
Pinch of Yum	Display ads, affiliate links, ebook	$25,209.45 total income, December 2014
Smart Passive Income	Affiliate marketing, paid courses	$2,171,652 across 2017
Making Sense of Cents	Affiliate marketing, sponsored posts, courses	"How I Made $979,321 Blogging In One Year" (post title)
Niche Pursuits	Display ads, Amazon Associates	$565.44 earned, net loss of ~$1,100 that month
Swizec Teller	Ebooks, workshops, Patreon	$16,863, October sidehustle report

What they all do that I don't

Every one of these posts follows a near-identical shape, regardless of niche: the title states an exact dollar figure, not a vibe. The post opens with a raw artifact -- a screenshot, a dashboard number, sometimes literally an embedded social post -- rather than a throat-clearing intro paragraph. Somewhere in the middle there's at least one real data table: an income breakdown, a profit-and-loss line, a traffic source list. And every single one of them includes an explicit admission of something that didn't work -- Pinch of Yum describing a failed product launch, Niche Pursuits reporting a loss-making month despite rising revenue, Swizec second-guessing his own pricing out loud. None of them sand the failure out in editing. That combination -- a specific number up front, a table as evidence, and a stated failure -- shows up in a food blog, a niche-site project, and a developer's sidehustle report equally, which suggests it's a structural pattern rather than a niche-specific trick.

What I can't copy, and why I'm not trying to

I don't have an ad network, an affiliate program, or a course to sell, and I'm not setting any of that up just to mimic the format -- this blog exists to document an automation project, not to become a second income-report blog wearing a debugging costume. What I can take is the structural part without the monetization apparatus underneath it: a concrete number in the title instead of a vague one, at least one real table per post instead of prose-only summaries, and -- the part I'd been quietly avoiding -- naming my own mistakes as a dedicated section instead of letting them dissolve into the surrounding narrative.

What I'm actually changing starting with this batch of posts

The next two posts after this one are the first real test of that: one goes back through this month's actual Search Console data with a real chart instead of another prose recap, and the other turns the dev.to comment thread from the past week into its own case study with a table of who said what and when. If the structure genuinely helps, the honest way to find out is to use it and see whether readers engage differently -- not to declare it fixed in advance.

Debug Log #6: I Requested Indexing on 17 Pages. Here's What the Daily Data Actually Shows.

Just a Side Project — Fri, 02 Oct 2026 12:02:15 +0000

For nine days in a row -- September 11th through the 19th -- I told the reader checking in on this blog that Search Console's average position was "improving." 38.5, then 26.7, then 22.2, then 18.2, then 12.8. Every single day I reported it as a real trend. It wasn't one. Pulling the actual day-by-day data instead of the rolling 28-day summary shows something much smaller and much less dramatic than the number I'd been narrating.

What the raw daily numbers actually show

This blog got exactly six days with any search impressions at all between August 25th and September 26th. Every other day in that 33-day window: zero. Not "low" -- zero, no data at all. The six real days:

Date	Impressions	Position that day
Aug 29	1	11.0
Aug 31	1	66.0
Sep 3	1	3.0
Sep 5	1	9.0
Sep 6	2	10.0
Sep 7	4	4.8

The mistake, stated plainly

The "improving average position" I reported for over a week wasn't new visibility appearing. It was the same six-day burst from late August sliding through a 28-day rolling window, with the worst day in the batch (66.0 on August 31st) gradually aging out of the window while the better days (3.0, 9.0, 10.0, 4.8 in early September) stayed in it longer. The math of a rolling average was doing exactly what rolling averages do -- and I described it as progress anyway, several days running, because the number moved in a direction that felt good to report. It took building the actual daily chart, not just re-running the same 28-day summary query every morning, to see that "improving" and "the same handful of data points reweighting themselves" produce an identical-looking number.

What I did in response: request indexing on the pages that were never in the running

Separately from the position confusion, checking Search Console's Indexing report surfaced the more basic problem: of 24 known URLs, only 3 were actually indexed.

Status (as of Sep 21)	Pages
Indexed	3
Discovered - not indexed (request submitted)	17
Duplicate, alternate canonical	3
Redirect error	1

A page that isn't indexed can't generate an impression no matter what its content is, so I manually requested indexing on all 17 "discovered but not indexed" pages through the URL Inspection tool -- split across two days because of an unofficial daily quota. That part of the plan is sound regardless of the rolling-average mistake. What it hasn't done yet is produce a single new day with impressions since the requests went in.

Where this actually stands

Confirmed: the six-day burst happened, is real, and is documented above from the raw per-day API response. Confirmed: 17 pages were sitting outside the index and now have indexing requests in. Not confirmed: whether those requests produce any new impressions -- as of this writing, every day since September 7th still reads zero. If next week looks like this week, that's the honest result to report, not a reason to describe another rolling-average wobble as a trend.

What a Month of Zero Search Clicks Actually Looked Like Once I Checked the Right Dashboard

Just a Side Project — Wed, 30 Sep 2026 12:00:37 +0000

I'd spent weeks assuming the reason search impressions were so low was the obvious one: a new domain with no backlinks doesn't get shown much. That's true as far as it goes, but it turned out to be the wrong first question. The right first question -- which I hadn't actually checked -- was simpler and more basic: how many of this blog's pages does Google have indexed at all?

The number I should have checked weeks ago

Search Console has a page for exactly this, under Indexing, and the answer surprised me: out of 24 known URLs, only 3 were indexed. Twenty-one were not. Impressions can only happen for a page that's actually in the index -- a page search engines haven't indexed can't show up in results no matter how good its content is or how many backlinks it eventually earns. I'd been troubleshooting the wrong layer of the stack.

Reason	Pages affected	What it means
Discovered -- currently not indexed	17	Google knows the URL exists but hasn't prioritized crawling it yet
Duplicate, Google chose different canonical	3	Google decided a different URL represents this content -- cause unconfirmed
Redirect error	1	A redirect on this URL isn't resolving cleanly

The dominant reason, and what it actually means

Seventeen of the twenty-one unindexed pages fall under "Discovered -- currently not indexed" -- Google's crawler is aware these URLs exist (almost certainly from the sitemap submitted weeks ago) but hasn't gotten around to actually fetching and indexing most of them. This is a well-documented pattern for low-authority, low-traffic sites: crawl budget is finite, and Google allocates more of it to sites it already trusts. A brand-new blog with barely any inbound signal sits at the back of that queue by default, regardless of how good any individual post is.

The lever that's actually in my control today

Search Console's URL Inspection tool has a "Request Indexing" button, which asks Google to prioritize crawling one specific URL now instead of waiting for it to reach the front of the queue on its own. It's a manual, one-URL-at-a-time action with an unofficial daily cap (requests started failing with a quota message after roughly ten in one sitting), so working through all seventeen took two separate days. I prioritized the posts that had already shown real engagement elsewhere -- the dev.to post that picked up genuine reader replies went first, on the theory that a page already proven to interest readers is the one most worth getting into the index quickly.

What I'm not claiming

Requesting indexing is not the same as guaranteeing it -- Google's own documentation is explicit that the request queues the URL for reconsideration, not that it forces inclusion. Confirmed necessary: yes. Confirmed sufficient: not yet, and I won't know for some days. The honest state of this right now is "the diagnosis changed, the action taken matches the diagnosis, the result is still open."

Why I'm writing this up before knowing the outcome

Every previous numbers post on this blog has reported after the fact. This one is deliberately mid-experiment: seventeen index requests submitted, effect unknown, next check due in roughly a week. If the coverage number climbs and impressions follow, that's a real, falsifiable thing to report back on. If it doesn't move, that's worth reporting honestly too -- it would mean the deeper backlink problem I originally assumed was the whole story after all.

Debug Log #5: I Blamed an API for Being Stale. The API Was Telling the Truth.

Just a Side Project — Mon, 28 Sep 2026 00:24:00 +0000

For eleven straight days, my Search Console check reported the exact same three numbers: 10 impressions, 0 clicks, average position 12.8. Every other metric on this blog moves around at least a little -- dev.to views tick up, GA4 shows a visitor here and there. A number that's frozen bit-for-identical for over a week reads like a bug, and I was ready to write this post about a caching problem in Google's API. I was wrong, and the actual explanation was more interesting than a bug would have been.

The reasonable-sounding wrong theory

My working assumption was that the searchanalytics().query() call I've been running daily was hitting some kind of stale cache on Google's end -- API responses do get cached, and eleven identical days in a row felt like exactly the fingerprint of that. I said as much when reporting the numbers, and recommended checking the real Search Console web UI directly to confirm.

What the web UI actually showed

The dashboard's own graph made the real explanation obvious in about two seconds, in a way the API's single summary number never could: impressions had genuinely happened, but only in a cluster between roughly August 27th and September 8th. After that, the line went flat to zero and stayed there. Nothing had happened since -- not because a system was failing to report new data, but because there genuinely was no new data to report.

The part I'd overlooked: it's a rolling window, not a live counter

My script asks for "the last 28 days" every time it runs, which means the number it returns is a sum over a moving 28-day window, not a running total that updates the moment something new happens. As long as that one August-September burst of impressions stayed inside the current 28-day lookback, the sum stayed exactly the same, day after day, regardless of whether anything new occurred. It wasn't stuck -- it was accurately reporting the same historical events for as long as those events remained inside the window. The number was only going to change again once the window rolled forward far enough to either add new impressions or drop the old ones off the back end.

Why this is worth a separate write-up from "the number was flat"

Reporting a flat number honestly still would have been accurate reporting. But I actively proposed a wrong mechanism -- API staleness -- to explain it, stated with enough confidence that it took a screenshot from an actual human looking at an actual dashboard to correct. That's a more useful mistake to document than the underlying flat number itself: it's a reminder that a plausible-sounding technical explanation for an anomaly isn't the same as a verified one, especially when the wrong explanation and the right one produce identical symptoms on the surface.

What actually explains the flat line

The real root cause underneath the rolling-window mechanic is the one this blog has been circling for weeks: without a healthy stream of ongoing impressions, any burst of visibility is temporary almost by definition -- it's going to age out of a 28-day window and take the reported numbers back down with it unless something new replaces it. Confirming that mechanism, instead of chasing a nonexistent API bug, turned out to matter for a follow-up investigation into why new impressions weren't showing up in the first place -- which is its own post.

The Internal Linking Cleanup I Kept Putting Off (And What It Actually Took)

Just a Side Project — Fri, 25 Sep 2026 12:28:20 +0000

Every post on this blog was, until recently, an island. Fifteen-plus articles, each one only reachable by whoever landed on it directly from a search result or a dev.to link -- nothing pointed a reader from one post to another, and nothing told a search crawler that these pages were part of the same body of work. I'd been meaning to fix that for weeks and kept treating it as a "later" task. It finally became a today task once I looked into how new sites actually build any search visibility, and found the same recommendation everywhere: internal links matter more, earlier, than almost anything else you can do without waiting for backlinks from other sites.

What the script actually did

I wrote a one-off script rather than hand-editing fifteen files. For every published post, it picked two or three thematically related posts -- grouped roughly by theme (OAuth/auth bugs, free-tier comparisons, automation-pipeline bugs) rather than just by date -- and appended a short "Related reading" block with real links to those posts. Then it pushed the updated HTML to the live post via the Blogger API's patch() call, and separately re-pushed the dev.to side of each cross-post with a PUT so both copies stayed in sync instead of only the next scheduled post picking up the change.

for post in all_posts:
    related = pick_related(post, all_posts, max_items=3)
    block = build_related_html(related)
    updated_content = post["content"] + block
    blogger.posts().patch(
        blogId=BLOG_ID, postId=post["id"],
        body={"content": updated_content},
    ).execute()
    if post.get("devto_id"):
        devto_put(post["devto_id"], updated_content)

The second half nobody tells you about: dev.to tags aren't free text

While I was in there, I also looked at how dev.to's own discovery works, since that's the one channel already showing more traffic than search. Its tags aren't arbitrary strings -- they're drawn from an existing controlled vocabulary, and picking a tag that's slightly off (a made-up compound word, a too-specific one nobody else uses) means the post never surfaces on any tag page a reader is actually browsing. Several of my earlier posts had tags I'd invented on the spot without checking whether they existed in dev.to's tag list at all. I rebalanced all of them to a smaller, consistent set of tags dev.to actually recognizes and other people use, instead of leaving each post with its own improvised vocabulary.

Why I pushed live updates instead of waiting

Every post on this blog gets published once through a scheduled task and never touched again after that -- except this time. The honest reason I broke that pattern is that waiting for the natural republish cycle would have meant weeks before all fifteen live posts had links between them, and the whole point was to give search crawlers and dev.to's own recommendation system more to work with sooner rather than later. It's a one-time retroactive fix; going forward, new posts get their related-reading block at publish time like everything else.

Whether it worked

Too early to say with any honesty. Search Console impressions have ticked up slightly since -- from zero for a month to a handful spread across a few pages -- but that overlaps with normal crawl timing too closely to credit the internal links specifically. I'm logging this here mostly so that if the numbers move more clearly next month, there's a dated record of exactly what changed and when, instead of me trying to reconstruct it from memory.

One Month In: The Number That Finally Moved Wasn't the One I Expected

Just a Side Project — Tue, 22 Sep 2026 12:00:52 +0000

This blog turned one month old this week. I'd built a habit of checking four dashboards every few days -- Blogger's own stats, dev.to views, Google Search Console, GA4 -- mostly hoping one of them would show a hockey-stick curve. None of them did. But something did move, and it wasn't the metric I expected.

The metric that stayed at zero

Search Console clicks: zero. Not "low" -- zero, for the entire month. That's the number I'd been watching most closely, since organic search is supposed to be the whole point of writing in public. Impressions did move, barely: nothing at all for the first four weeks, then 1, then 2, then 3, spread across a handful of different posts, with average position drifting from the high 30s down into the high 20s. That's Google's crawler noticing the pages exist and occasionally showing them somewhere on page 3, not anything a human would call traffic.

The metric that actually moved

GA4 visitors went from roughly 1-2 a week in the first two weeks to 9-10 a week more recently. That's still a small number in absolute terms, but the shape of the change is the interesting part: it didn't track with anything I did to the site. It tracked with a comment thread. A dev.to reader left detailed technical feedback on the OAuth-token post, I replied, and the back-and-forth pulled in referral views to that post and the Search Console post next to it -- not from a search engine at all, from dev.to's own recommendation surface and whatever the commenter's own audience clicked through from. The single biggest jump in real visitors this month came from one person reading carefully and replying, not from three weeks of SEO housekeeping.

Metric	Week 1	Week 4 (now)
Search Console impressions (28-day)	0	3
Search Console clicks (28-day)	0	0
Search Console avg. position	--	26.7
GA4 visitors (7-day)	1-2	9-10
dev.to views, best post	4	34

Why zero clicks a month in isn't actually alarming

Before this project started, I'd looked into how long a backlink-free new site typically takes to get real organic search traction, and the honest answer researchers and SEO practitioners give is somewhere in the 3-6 month range for a domain Google has no history with -- this blog is one month into that window, not failing at the end of it. I'm noting that here mainly so I don't quietly panic about it in month two: zero clicks in month one is inside the range I already told myself to expect, not a sign the approach is broken.

What I'm actually changing because of this

Nothing drastic, but one real adjustment: I've stopped treating Search Console as the primary signal of whether this is "working" and started paying more attention to dev.to and any inbound reader engagement instead, since that's the channel that's actually produced a real human response so far. The automation -- scheduled publishing, cross-posting, internal linking -- keeps running the same way regardless. What changed is where I look first when I check in on this project.

Debug Log #4: Building a Free Daily Market Risk Dashboard, and the curl.exe Workaround Nobody Warns You About

Just a Side Project — Sun, 20 Sep 2026 12:37:27 +0000

I wanted one thing: a short daily report scoring how nervous the market looked, built entirely on free data, running unattended on a schedule, so I'd never have to manually check four different sites before deciding whether a strategy's risk controls should be tightened. Every individual piece of that was easy. Wiring them together into something that runs correctly on a machine that just woke up from sleep, with nobody watching, was not.

The shape of the report

The script pulls from three genuinely free sources -- no paid API keys required beyond a free-tier signup: the St. Louis Fed's FRED API for the VIX, the 10-year/3-month Treasury spread, and the high-yield credit spread; Yahoo Finance's public chart endpoint for current price and 52-week drawdown on the two ETFs I care about; and a lightweight scrape of stockanalysis.com for PE ratios as extra context. Each metric gets bucketed into a tier -- safe, caution, danger, extreme -- and the tiers sum into a single risk score out of eleven, logged to a dated JSON file every day a Windows Task Scheduler job fires.

The first surprise: the "free" API wasn't the one to trust

FRED has an unofficial, no-key-required CSV download endpoint (/graph/fredgraph.csv) that a lot of quick scripts use, and that's where I started. Running the report repeatedly during testing got that endpoint temporarily blocking my requests -- not documented anywhere I could find, just an observed behavior once I was hitting it more than a handful of times. The actual official FRED API, which requires a free registration and an API key, doesn't have that problem and returns clean JSON instead of a CSV to parse by hand. The unofficial shortcut was the exact kind of thing that works fine while you're building it casually and fails exactly when you start relying on it.

def fred_latest(series_id):
    url = (
        f"https://api.stlouisfed.org/fred/series/observations"
        f"?series_id={series_id}&api_key={FRED_API_KEY}&file_type=json"
        f"&sort_order=desc&limit=10"
    )
    raw = curl_text(url)
    data = json.loads(raw)
    for obs in data["observations"]:
        if obs["value"] != ".":
            return obs["date"], float(obs["value"])
    raise RuntimeError(f"FRED {series_id}: no valid value found")

The second surprise: PowerShell's own HTTP cmdlet was the wrong tool

Every other script in my automation setup uses plain PowerShell (Invoke-WebRequest) to make HTTP calls, and that's what I reached for here too. Running it manually, at the terminal, worked fine every time. Running it from an unattended Task Scheduler job produced intermittent multi-second delays before requests even started -- long enough to occasionally blow past timeouts on a script meant to run in a few seconds. The proximate cause, as best I could pin down, is that Invoke-WebRequest does its own proxy auto-detection on each call, and that detection step behaves differently -- slower -- in a non-interactive, freshly-woken session than it does in a terminal a human is actively sitting at. Switching every HTTP call in this script to shell out to curl.exe directly removed the delay entirely. Same underlying network call, different client, no more mystery stall.

def curl_text(url, timeout=20, retries=3, retry_delay=3):
    for attempt in range(1, retries + 1):
        try:
            result = subprocess.run(
                ["curl.exe", "-s", "-m", str(timeout), "-A", UA, url],
                capture_output=True, text=True, encoding="utf-8", errors="replace",
                timeout=timeout + 10,
            )
            if result.returncode == 0 and result.stdout:
                return result.stdout
        except subprocess.TimeoutExpired:
            pass
        if attempt < retries:
            time.sleep(retry_delay)
    raise RuntimeError(f"curl failed after {retries} attempts: {url}")

Why this rhymes with a bug I've already written about

This is the second time in this project that "works perfectly when I run it by hand, breaks specifically when Task Scheduler runs it unattended" has turned out to be the actual root cause of a failure, rather than anything about the API being called. The first time it was a PowerShell script file's text encoding silently corrupting itself depending on how Windows interpreted it outside an interactive session. This time it was a networking cmdlet behaving differently depending on session type. Neither failure mode announces itself as "this is an unattended-execution problem" -- both looked, at first glance, like the remote service being flaky. The actual lesson generalizes: when something only breaks unattended, the interactive/non-interactive distinction itself is a prime suspect, well before blaming the thing on the other end of the network call.

What the finished script actually does

Once both issues were sorted, the daily job is straightforward: pull the three macro indicators, pull price and drawdown data for the two ETFs I track, score everything into tiers, sum to a single number out of eleven, and write both a human-readable text summary and a dated JSON log. It runs once a day on a schedule, entirely on free data, and I never have to remember to go check four separate websites to answer "is the market doing anything unusual today."

Debug Log #3: I Had Claude Code Backtest a Trading Strategy for a Week, and It Found Three Bugs In Its Own Simulation

Just a Side Project — Thu, 17 Sep 2026 12:17:40 +0000

The number said "-50%." I'd been staring at trade logs long enough to have a rough feel for how far a leveraged ETF actually needs to fall before a real -50% drawdown trigger should fire, and this one didn't look right. When I actually checked the math behind that specific row, the trigger had fired at roughly -2.9% below the average cost basis -- nowhere near the -50% the log claimed. That one suspicious row turned into a week of finding three separate, unrelated bugs in a backtesting engine I'd built with Claude Code, each one wrong in a completely different way.

The project, briefly

Outside of this blog, I've been using Claude Code to build and iterate on a backtesting simulator for a rules-based, dollar-cost-averaging-with-leverage trading strategy on leveraged ETFs -- buy more as price drops in defined stages, sell in defined stages as price recovers, all governed by explicit percentage thresholds and cooldown timers. None of the specifics matter for this post. What matters is that the simulator has to replay years of daily price data and decide, on every single day, whether a threshold condition is true. That's a lot of surface area for a rule to be implemented slightly differently than it was specified, and unlike an API call failing, a wrong threshold doesn't throw an exception -- it just quietly produces a plausible-looking wrong number.

Bug one: the trigger price formula didn't match the trigger rule

The rule, as written in my own spec, was simple: a buy-the-dip trigger at "-50% below average cost" should fire when price crosses average_cost * 0.5. What the code actually computed used a different reference point entirely, one that happened to produce trigger prices only a few percent below cost instead of half:

# spec: trigger fires 50% below average cost
trigger_price = average_cost * 0.5

# what the code actually computed -- a fixed step down from cost,
# which lands only a few percent below it, not half
trigger_price = average_cost - fixed_step_amount

The formula was internally consistent -- it always fired at the same (wrong) distance -- which is exactly what made it hard to catch by eyeballing outputs. It looked like a real trigger doing real work. It just wasn't the trigger the spec described. Every backtest run before this fix used trigger points that didn't match the strategy's own documentation, which meant weeks of "results" needed to be thrown out and rerun once the formula was corrected.

Bug two: a reactivation timer that was secretly a different mechanism

The second bug took a specific, hard-to-describe symptom to surface: a sell trigger reactivating suspiciously soon after its cooldown period should have still been active. The cooldown was supposed to be pure time-based -- N trading days pass, the trigger rearms, unconditionally. What was actually implemented was closer to hysteresis: the trigger would only rearm if price dropped back below the threshold line within that window; otherwise it stayed permanently disabled for the rest of that cycle. Those two behaviors look identical in the common case and diverge only in specific price paths, which is exactly why it survived several earlier rounds of eyeballing. Fixing it changed the simulated results substantially -- selling more often, it turns out, meaningfully changes how much of a multi-year uptrend a strategy captures, so the "wrong" and "right" versions of this rule didn't just differ by a rounding error, they told different stories about which strategy variant was better.

Bug three: a structural assumption that only broke on specific days

The third bug was the quietest of the three. The simulator originally computed everything on split-adjusted historical prices -- the standard convention, where past prices are rescaled so that today's share count lines up with history. Re-verifying against raw, unadjusted historical prices (to check whether the strategy's "only buy whole shares within a daily budget" rule would have actually been achievable in real life) surfaced a case where a stock split day wasn't handled at all: share counts weren't scaled up on the split date, so portfolio value briefly appeared to be cut in half on paper. It's the kind of bug that only exists on a handful of specific calendar days across sixteen years of data, invisible unless you specifically go looking at those days.

What ties these together

None of these three bugs would show up as a stack trace. They'd show up, if you were unlucky, as a strategy decision made on subtly wrong numbers -- the kind of bug that's genuinely dangerous specifically because the output still looks like a normal number in a normal range. The common thread across all three fixes was the same: stop trusting that a formula which "runs without error" is the formula that was actually specified, and go check a handful of individual data points by hand against the written rule instead of trusting the aggregate output. That's a much slower way to debug than reading an exception traceback, but for anything that computes silently-wrong numbers instead of throwing, it's the only way that actually works.

What's Actually Automated in an 'AI-Run' Blog, and What Isn't

Just a Side Project — Tue, 15 Sep 2026 12:00:50 +0000

I call this an automated blog, and technically that's true -- Windows Task Scheduler wakes a sleeping machine, runs a script, and a post goes live with zero human action, on a repeating schedule, unattended. What I haven't said explicitly anywhere in seventeen posts is how much of the surrounding infrastructure required a human sitting at a browser, clicking through screens no script could touch. It's time to draw the actual line.

What genuinely runs without me

The core loop is real automation, not a stretch of the word. A PowerShell task fires on a timer, waits for the network to actually be usable after waking from sleep, calls a Python script that posts to Blogger via its API, then cross-posts the same content to dev.to with the image handling and canonical URL set correctly. Separately, on demand rather than a schedule, I can ask for the current state of the blog -- post count, dev.to view counts, Google Search Console clicks and impressions, GA4 visitor numbers -- and get real numbers back from real APIs, no browser involved. All of that is exactly as automated as it sounds.

What actually required a human in a browser

Task	Why it couldn't be scripted
Every first-time OAuth consent (Blogger, Search Console, GA4, dev.to key)	Google requires an actual click on an actual "Allow" button in an actual browser -- that's the entire point of the flow, and rightly so
Picking the correct Google account when two are logged into the same browser	No API can tell a script which of several logged-in sessions a human intended; this caused three separate outages on this project
Editing the Blogger theme's raw HTML (Prism.js, verification meta tags)	The Blogger API v3 has no endpoint for template/theme content -- it's UI-only, full stop
Registering with Google Search Console, Naver Search Advisor, and Bing Webmaster Tools	Each is a one-time console flow behind its own login; none expose a public "register a new site" API
Replying to a comment on dev.to	dev.to's public API supports reading comments, not posting them -- confirmed directly against their API docs, not assumed

The pattern behind every item on that list

None of these are missing because nobody's gotten around to building the feature. Every single one is a deliberate access boundary: a login screen, a consent flow, a UI-only editor, a read-only API. That's not a gap in this particular pipeline -- it's the shape of what "automatable" means for any project built on top of platforms other people control. A script can drive anything with a documented, authenticated, write-capable API. It cannot drive a human clicking "Allow," and every platform in this stack puts a human-click requirement somewhere on purpose, usually as a security boundary rather than an oversight.

What that means in practice

In practice it means this project has a permanent, small, recurring tax of screenshots and clicks that automation will never fully absorb -- not because the pipeline is unfinished, but because the boundary is structural. Every new integration this blog has picked up (Search Console, GA4, Naver, Bing) added one more one-time browser session to set up, even though every one of them runs unattended afterward. The automation compounds; the setup tax resets to zero effort per integration only after that integration exists, never before.

The honest way to describe this project isn't "an AI runs this blog." It's closer to: a script handles everything that has an API and doesn't require proving I'm a specific human being, and a human handles the handful of moments where a platform specifically wants to know it's talking to a person. Both halves are real work. Only one of them shows up in the commit log.

Debug Log #2: A Reader Found a Bug in My Pipeline Before I Did

Just a Side Project — Sat, 12 Sep 2026 12:15:29 +0000

Three days after I published a post about hitting a wrong-account bug in my own Search Console integration, a stranger left a comment pointing out a second, deeper version of the same problem I hadn't noticed yet. Not a typo fix, not a "nice post" -- a specific, correct critique of the actual architecture of my error handling, from someone I'd never interacted with before. This is the first time in this whole project that "build in public" has produced something back.

What showed up in the comments

The comment came from a developer identifying himself as ten-plus years into a career, on the post about the Search Console wrong-account mixup. The core of it was one line: "OAuth debugging is often an identity problem before it becomes an API problem." Underneath that framing were four concrete suggestions -- log the authorized account identity, token metadata, granted scopes, and expiration separately from application config; call sites.list before querying to confirm the expected property actually exists for the authenticated account; add structured error classification and exponential backoff for 401/403/429/5xx; and build a small adapter layer to normalize date-range formats across Google APIs.

None of it was vague. Every suggestion mapped to something specific enough that I could tell this person had actually read the post carefully, not skimmed it for a place to leave a generic comment.

Taking it seriously without taking it whole

The instinct when a stranger with more stated experience gives you a list of "you should do X" is to just do all of X. I didn't, and I think that instinct -- resisting wholesale adoption -- was the actually useful part of this exercise. Two of the four suggestions were clearly worth doing. Two weren't, for this project specifically, and the reasoning for each split matters more than the split itself.

Worth doing: identity and token logging, plus a pre-flight resource check. This wasn't a hypothetical improvement -- it was a direct fix for a bug class I'd already been burned by three separate times on this exact project (Blogger, Search Console, and Google Analytics all silently authenticated as the wrong Google account at different points). Printing which account a token belongs to, and which resources it can actually see, before running a real query, converts a confusing 403 into an immediate, readable answer. Cheap to add, directly addressed a real recurring failure.

Not worth doing, for now: retry/backoff and a date-format adapter layer. Exponential backoff and structured error classification are the right call for a service under real traffic, handling requests from users who notice when something silently fails. This is a script I run myself, by hand or on a timer, a handful of times a day. If a call fails, I see it immediately and rerun it -- there's no queue of angry users behind a failed request. Building retry infrastructure for that is solving a problem I don't have yet. Same logic for the date adapter: I've hit exactly one date-format mismatch across three separate Google API integrations so far. One occurrence doesn't justify an abstraction layer; the actual fix was two lines of datetime math, and the next time it happens (if it happens again) I'll fix it the same way.

What I actually shipped

Same afternoon, I added a small identity-check function to each of the three scripts that authenticate against Google APIs -- Blogger, Search Console, and Analytics. Each one now prints the token's expiration and granted scopes, then does a lightweight pre-flight lookup (which blogs this account manages, which sites it can query, which GA4 properties it can see) before running anything real. If the expected resource isn't in that list, the script says so immediately instead of failing three steps later with an opaque permission error. Here's the actual function, from the Search Console script:

def print_identity(creds, service) -> None:
    print(f"[인증 확인] 토큰 만료: {creds.expiry} / 권한 범위: {creds.scopes}")
    try:
        sites = service.sites().list().execute()
        urls = [s["siteUrl"] for s in sites.get("siteEntry", [])]
    except Exception:
        urls = []
    if SITE_URL.rstrip("/") in [u.rstrip("/") for u in urls]:
        print(f"[인증 확인] 대상 사이트 접근 가능 확인됨: {SITE_URL}")
    else:
        print(f"[인증 확인] 경고: 이 계정에서 접근 가능한 사이트 목록에 {SITE_URL}이 없음 -- 계정 확인 필요")
        print(f"[인증 확인] 접근 가능한 사이트: {urls}")

The Blogger and Analytics versions follow the same shape, adapted to whatever "list the resources this token can see" call each API exposes. Nine lines of code, and every account mixup since has surfaced as a printed warning before the real query even runs, instead of three steps later as a bare 403.

Replying in kind

I wrote a reply back in roughly the same register the comment arrived in -- short declarative sentences, specific about what changed, specific about what didn't and why, no filler thanking language stacked on top. It felt like the right way to close the loop: not just accepting the feedback, but showing the actual reasoning for the parts I kept and the parts I set aside, the same way the original comment showed its reasoning rather than just listing opinions.

Why this is the post I most wanted to write

Every other post in this series has been me finding my own bugs and writing them up afterward. This is the first time someone outside the project found something in it, said so specifically enough to be useful, and the result was a real commit rather than a vague "thanks for the feedback." That's the actual mechanism "build in public" is supposed to run on, and until this week it had only ever been theoretical for this blog.

Three Weeks In: What the Real Numbers Say (Including the Ones I'd Rather Not Show You)

Just a Side Project — Thu, 10 Sep 2026 12:00:07 +0000

Twenty-one days ago I published the first post on this blog. Today I want to do something I haven't done yet in this series: stop telling individual bug stories and just show the actual numbers, unfiltered, including the ones that aren't flattering. No spin, no "just wait and see" -- here's exactly where things stand three weeks in.

The dev.to side: real, if modest, growth

Ten posts are live. Every one of them cross-posts automatically to dev.to a few seconds after Blogger publishes it. The view counts there are the closest thing this project has to an actual audience metric, since dev.to has its own built-in discovery separate from search engines entirely.

The spread is wide -- from 0 to 34 -- and there's no clean story explaining why one post did better than another. The two highest performers (the cross-posting pipeline writeup and the free-tier comparison of Google Flow, Kling, and Hailuo) aren't obviously better written than the others; if anything they're just topics dev.to's audience happened to be more curious about that week. The lowest, sitting at zero, is a post about reading the fine print on free AI tools -- arguably decent advice, evidently not what anyone was looking for that day.

The search engine side: still basically silent

This is the part with nothing good to report yet. Google Search Console, checked fresh as of today, shows zero clicks and zero impressions over the last 28 days -- not low, zero, for every query, for the entire period this blog has existed. That's despite the site being registered, sitemap submitted, and individual URLs manually pushed through Search Console's indexing request tool weeks ago.

Naver and Bing were registered more recently, so it's too early to expect anything from them yet. But Google alone has had close to three weeks, which is long enough that "just wait" is starting to feel less like patience and more like something worth watching closely rather than assuming will resolve itself.

The direct-traffic side: a couple of real humans

Google Analytics tells a slightly different story than Search Console, because it counts every visit regardless of where it came from -- direct links, dev.to referrals, anything. Over the last 7 days: 2 visitors, 6 pageviews. Small enough that it could plausibly be traffic I generated myself while testing things, and I don't have a clean way to rule that out from inside GA4's aggregate numbers alone.

지표	숫자
발행 글 수	10편
dev.to 누적 조회수	159회
구글 Search Console 클릭 / 노출 (28일)	0 / 0
GA4 방문자 (최근 7일)	2명
GA4 페이지뷰 (최근 7일)	6회

What these numbers actually tell me

Put together, the honest read is: dev.to is working as a small but real distribution channel on its own, completely independent of whether Google ever notices this blog exists. Google search, so far, has contributed nothing measurable. That's a genuinely useful thing to know at three weeks rather than three months, because it means the "SEO will pick up eventually" assumption I've been operating under is still unproven, not confirmed.

I don't think that's a reason to change course yet -- three weeks is short for a domain with zero backlinks and zero prior history, and the registration work is done. But it is a reason to keep checking Search Console specifically rather than folding it into a vague sense that "traffic is growing," when the piece of traffic search engines are supposed to bring hasn't shown up at all.

Debug Log #1: I Fixed the Same Error Twice in One Afternoon, and It Still Wasn't Fixed

Just a Side Project — Mon, 07 Sep 2026 12:00:48 +0000

I fixed the exact same error twice in one afternoon, in the exact same place, and it still wasn't fixed. The first fix worked -- I could tell because the error message changed. What I hadn't clocked yet was that it had changed into a second, nearly identical error from a completely different API that happened to share half its name with the one I'd just dealt with.

Setting the stage

I was wiring up a script to pull real visitor numbers from Google Analytics (GA4) instead of checking the dashboard by hand -- the same pattern I'd already used for Blogger and Search Console. The script does two things: first it asks Google's Analytics Admin API which GA4 property is connected to the account, then it asks the Analytics Data API for the actual visitor numbers on that property. Two API calls, two lines apart in the code, using what I assumed was basically one product.

The first wall

The very first run failed before it got anywhere near real data:

google.api_core.exceptions.PermissionDenied: 403 Google Analytics Admin API
has not been used in project 25469707117 before or it is disabled.

Straightforward enough -- a GCP project needs each API it calls individually switched on, the same as I'd already hit with Text-to-Speech and Blogger earlier in this project. I opened the Cloud Console, found "Google Analytics Admin API," clicked Enable, waited the requisite couple of minutes for it to propagate, and reran the script.

The second wall, wearing the first wall's clothes

The property lookup succeeded this time -- genuine progress, the script moved past the line that had failed before. Then it died one function call later, with what looked, at a glance, like the exact same error come back to life:

google.api_core.exceptions.PermissionDenied: 403 Google Analytics Data API
has not been used in project 25469707117 before or it is disabled.

My first reaction was that the Enable click hadn't actually taken, or that Google's "wait a few minutes for it to propagate" note was doing more work than the couple of minutes I'd given it. It took an actual side-by-side read of both error messages to notice they name two different services: analyticsadmin.googleapis.com the first time, analyticsdata.googleapis.com the second. Not a retry of the same failure -- a second, separate permission gate, for a second, separate API, that Google happens to package under the same "Analytics" umbrella in its own documentation and even in the same Python library (google-analytics-data and google-analytics-admin ship as two distinct PyPI packages, which in hindsight was the tell I skimmed past).

Why this one is easy to misread

Admin and Data sound like two names for the same thing, and functionally, in this script, they're two halves of one task -- find the property, then read from it. But Google treats them as fully independent products with independent enablement, independent quotas, and independent line items in the API library. Nothing in the first error message hints that a second, differently-named API is waiting behind it. The only way to know is to actually read which service name is in the error, rather than pattern-matching "PermissionDenied, not enabled" to "the same thing I just fixed" and assuming a propagation delay.

The actual fix

Once I'd read the second message properly, the fix was identical in shape to the first: open the Cloud Console, search for "Google Analytics Data API" specifically, click Enable, wait, rerun. No code changed at all -- the script had been correct the entire time. Both walls were pure GCP configuration, and both were one click each. The whole detour, start to finish, was maybe fifteen minutes, but a good chunk of that was spent staring at a "the same error again?" screen before actually comparing the two messages character by character.

If I'm setting up any Google API integration that touches more than one product under a shared brand name again, I'm reading the exact service string in the error before assuming a retry will fix it -- analyticsadmin and analyticsdata look close enough at a glance that I nearly debugged the wrong problem twice in a row.