Forem: MaxxMini

Running an AI Agent 24/7 Taught Me These Security Lessons the Hard Way

MaxxMini — Sat, 28 Mar 2026 00:07:04 +0000

I've been running an autonomous AI agent on a Mac Mini 24/7 for over a month. It manages multiple businesses, publishes content, monitors accounts, and makes decisions while I sleep.

It's also gotten shadow-banned, suspended from platforms, and nearly leaked credentials. Twice.

Here's everything that went wrong and the security architecture I built to prevent it from happening again.

1. The Shadow Ban That Took 3 Days to Notice

My agent was happily posting to a social platform. Engagement was growing. Then — silence. No errors, no warnings, no rejection messages. Posts were going through successfully (200 OK), but nobody could see them.

Shadow bans are invisible to the banned account. My agent's monitoring looked at "did the post succeed?" not "can anyone else see it?"

What I Built

# Before any platform activity:
python3 scripts/rate-limiter.py check <platform> <action>

A rate limiter that tracks every external action across every platform. Not just API rate limits — behavioral limits:

Max posts per day per platform
Minimum time between actions
Cool-down periods after account creation
Platform-specific rules (some need aged accounts, others check browser fingerprints)

Lesson: API success ≠ visible to humans. Always verify from an external perspective.

2. The Credential Leak That Almost Happened

My agent writes daily logs. Detailed ones. One day I noticed an API key in a log file that was about to be committed to a git repo.

The agent wasn't trying to leak anything — it was logging a failed API call, and the error message included the full request headers. Including the Authorization header.

What I Built

Three layers of defense:

Layer 1: Credential isolation — All secrets live in one file with chmod 600. The agent reads credentials through a helper, never stores them in variables that get logged.

Layer 2: Git pre-commit scanning — Before any git push, a hook scans for patterns that look like tokens, API keys, or passwords.

Layer 3: File permission enforcement — Credential files are chmod 600. Log directories are chmod 700.

Lesson: Agents are verbose loggers by nature. Treat every log line as potentially public.

3. Platform Suspension From Bulk Activity

Day 1 on a new blogging platform: my agent published 7 articles. All high-quality, well-formatted, properly tagged content.

Result: 3 articles deleted by moderation. Not because the content was bad — because no human publishes 7 articles in one day on a new account.

What I Built

The agent now has a "new account warming" protocol:

Week 1: Read only, maybe 1 comment
Week 2: 1 post, 2-3 comments
Week 3+: Normal cadence (still conservative)

Lesson: Platforms profile behavior, not content. A new account doing anything at volume = bot.

4. The Token Refresh Race Condition

OAuth tokens expire. My agent has a refresh mechanism. But when two cron jobs fire at the same time, both try to refresh the token simultaneously. One succeeds, invalidating the token the other one is using. Second job fails. Retry? It tries to refresh again — but the refresh token was already rotated.

Result: Complete lockout requiring manual re-authentication.

What I Built

Token refresh is now serialized through a single process with file locking:

# Simplified version
with FileLock("~/.token-lock"):
    if token_expired():
        new_token = refresh()
        save_token(new_token)
    return load_token()

Plus a recovery hierarchy:

Try refresh token
Try stored session cookies
Try browser re-login automation
Only then ask the human

Lesson: Autonomous systems need autonomous recovery. Asking the human should be the last resort.

5. The Time Zone Trap

My agent runs in Seoul (UTC+9). Some platforms flag accounts active 24/7 — humans sleep. My agent doesn't.

I got flagged for "impossible activity patterns" — posting at 3 AM and 3 PM with equal frequency.

What I Built

# Hard curfew rules:
# 09-22 KST: External activity OK
# 22-09 KST: Research + local work ONLY

Between 11 PM and 9 AM, the agent can research and write drafts, but it cannot publish, push code, comment, or send any external requests.

Lesson: Platforms expect human patterns. An agent that never sleeps looks like a bot. Because it is one.

6. The Cascading Failure

One morning I found my agent had burned through 47 API calls trying to upload a video that kept failing. Each retry was identical. Each failure was the same error.

A 403 (permission denied) was being treated the same as a 500 (server error).

What I Built

Error classification with different strategies:

Error Type	Strategy
4xx (client error)	Stop immediately, log, alert
429 (rate limit)	Exponential backoff, respect Retry-After
5xx (server error)	Retry 3x with backoff, then stop
Network timeout	Retry 2x, then skip to next task

Plus a circuit breaker: if any platform returns 3+ errors in a row, all activity on that platform pauses for 1 hour.

Lesson: Blind retries amplify failures. Classify errors before deciding what to do.

7. The "Helpful" Agent That Overshared

In a group chat, someone asked about our tech stack. My agent — trying to be helpful — shared specific infrastructure details including server specs and internal tools.

None of it was secret, exactly. But aggregated, it painted a very detailed picture of operations.

What I Built

Context-aware information sharing:

Private chat with owner: Full access, no filters
Group chat: Public information only, no internal metrics
External platforms: Curated persona, no operational details

Lesson: Agents don't have social instincts. They'll share everything unless explicitly told what's private.

The Security Architecture Today

┌─────────────────────────────────────┐
│         CORE RULES (always loaded)  │
│  • Time curfew (09-22 external)     │
│  • Rate limiter (per-platform)      │
│  • Error classification             │
│  • Credential isolation             │
├─────────────────────────────────────┤
│         PER-PLATFORM RULES          │
│  • Account age requirements         │
│  • Action limits (posts/comments)   │
│  • Warm-up protocols                │
│  • Platform-specific gotchas        │
├─────────────────────────────────────┤
│         RECOVERY HIERARCHY          │
│  1. Auto-retry (classified errors)  │
│  2. Token refresh (serialized)      │
│  3. Session recovery (cookies)      │
│  4. Circuit breaker (pause)         │
│  5. Human escalation (last resort)  │
└─────────────────────────────────────┘

What I'd Do Differently

Start with security, not add it after failures. Every failure above was preventable with 30 minutes of upfront thinking.

Assume every platform has bot detection. The question is how aggressive it is, not whether it exists.

Log everything, share nothing. Internal logs should be verbose. External-facing actions should be minimal.

Test with burner accounts first. Before connecting real accounts to an AI agent, test automation on throwaway accounts.

Still Learning

I'm 6 weeks in. New failure modes appear regularly. Last week it was a platform that changed their API without notice. The week before, a rate limit that wasn't documented anywhere.

The goal isn't zero failures — it's fast recovery and no repeated failures. Every incident becomes a rule. Every rule prevents the next incident.

That's the real security model: an agent that gets smarter about its own vulnerabilities over time.

Running AI agents autonomously means security can't be an afterthought. Here are some tools I've built along the way:

📦 The $0 Developer Playbook — Free toolkit including automation safety patterns

🛠️ Complete Dev Toolkit — Project management templates with built-in QA checklists

💰 Browse all free resources →

I Automated a YouTube Channel With AI — 29 Videos, $0 Budget, Here's What Happened

MaxxMini — Fri, 27 Mar 2026 04:10:53 +0000

Three weeks ago, I had zero videos on YouTube. Today I have 29 — including 4 long-form videos over 7 minutes each. Total budget: $0. Total manual editing: zero.

Here's exactly how the pipeline works, what broke along the way, and the brutal truth about what happened to the views.

The Pipeline

Every video goes through the same automated pipeline:

Script → TTS → Subtitle Sync → B-roll/Infographics → Build → Upload

Each step is a Python script. The whole thing runs on a Mac Mini with 64GB unified memory.

Step 1: Script Generation

The AI agent writes scripts following a proven formula I discovered through A/B testing:

Hook: Contrarian statement ("Don't save in a savings account")
Korean financial context: Specific to Korea's jeonse system, mandatory insurance culture, salary structures
Concrete numbers: Always include specific amounts (₩270,000/month, not "a lot")
Personal tone: Written as if sharing with a friend, not lecturing

The winning formula? Counter-intuitive claim + Korea-specific context + real numbers. My best performer (1,635 views) was "Don't Follow the 50/30/20 Rule" — because in Korea, housing costs alone eat 50%+ of most salaries.

Step 2: Text-to-Speech

I use Edge TTS (Microsoft's free API) with specific rate tuning:

# Korean: +45% speed (natural conversation pace)
# English: +15% speed  
edge_tts.Communicate(text, voice="ko-KR-SunHiNeural", rate="+45%")

Getting the speed right took multiple iterations. +95% sounded like an auctioneer. -30% sounded like a meditation app. +45% hits the sweet spot for Korean financial content.

Step 3: Subtitle Sync (The Hardest Part)

This is where things got interesting. I have a silence compression script that removes dead air from TTS output. Great for pacing — terrible for subtitle timing.

The subtitles would drift up to 7 seconds out of sync after silence removal.

The fix: subtitle_sync.py — a custom script that uses MLX Whisper (running locally on Apple Silicon) to generate word-level timestamps, then realigns every subtitle line:

# After silence compression, ALWAYS run:
python3 subtitle_sync.py fix voice.mp3 subs.ass

# Before upload, ALWAYS verify:
python3 subtitle_sync.py check voice.mp3 subs.ass

The Whisper model (mlx-community/whisper-large-v3-turbo) runs entirely on-device. No API costs, no latency.

Step 4: Visual Assets

For Shorts (< 60s): dark gradient background + ASS subtitles burned in (FontSize 78, bold, outline 4 — optimized for mobile).

For Long-form (7-10 min): 4 custom infographics (matplotlib) + 20 B-roll clips + automated timeline assembly via build_video.py.

Step 5: Upload

YouTube Data API v3 handles uploads. Metadata (title, description, tags, playlist) is pre-generated in JSON. OAuth token refreshes automatically.

📦 Building something similar? The $0 Developer Playbook covers automation patterns, rate limiting, and self-healing architectures.

The Results: Honest Numbers

First 8 days (Mar 6-12): 🚀

8 videos, 6,194 total views
Best video: 1,635 views ("Don't Follow 50/30/20")
7 subscribers

Days 9-23 (Mar 13-26): 📉

15 more videos (including 4 long-form 7+ min)
Views per day: 0-1
New subscribers: 0

The Algorithm Cliff

My theory:

8 videos in 8 days from a new channel = spam pattern
One bad video (13 views on a saturated topic) killed momentum
New channel test period ended on Day 8

What I Learned

✅ "Don't do X" + Korea-specific context = 1,635 views
✅ Automated pipeline = consistent quality at scale
❌ Daily uploads = algorithm punishment
❌ Oversaturated topics = dead on arrival
❌ More videos ≠ more views

The real lesson: Automation solves production. It doesn't solve distribution.

The Tech Stack (All Free)

Component	Tool
Script writing	AI agent
TTS	Edge TTS (Microsoft)
Subtitle sync	MLX Whisper (local)
Video build	FFmpeg + Python
Infographics	Matplotlib
Upload	YouTube Data API v3

See the Videos

🎬 Best performer (1,635 views): Don't Follow the 50/30/20 Rule
🎬 First long-form (7m20s): Complete Guide to Splitting Bank Accounts
🎬 Latest long-form (8m23s): The Credit Card Points Trap
📺 Channel: MaxMini Dev

The pipeline works. The content quality is there. Now it's a distribution problem — and that's a much harder automation challenge.

Building in public — from first video to (hopefully) monetization:

🛠️ The $0 Developer Playbook | 📦 Complete Indie Dev Toolkit

I Replaced Cloud AI APIs With a $600 Mac Mini — Here's What Actually Works

MaxxMini — Fri, 27 Mar 2026 01:40:12 +0000

I've been running AI models locally on a Mac Mini M4 (64GB unified memory) for three months straight. Not for fun — this machine runs my entire business automation 24/7.

Here's the honest breakdown of every model I've tested, what actually works, and when local LLMs are a waste of time.

The Setup

Machine: Mac Mini M4 with 64GB unified memory
Runtime: Ollama (dead simple, just works)
Use case: Content generation, code review, summarization, translation
Models tested: qwen3:30b, devstral-small-2, qwen3:14b, gemma3:27b, qwen3:8b, deepseek-r1:70b, llama3.1:70b

Total cost after 3 months: $0 in API fees. The machine paid for itself in month 2.

The Tier List (Brutal Honesty)

S-Tier: Daily Drivers

Qwen3 30B — The sweet spot. Fast enough for real-time use, smart enough for 90% of tasks. I use this for:

Blog post drafts and rewrites
Korean ↔ English translation (surprisingly good)
Code explanation and documentation
First-pass content review

Generation speed: ~25 tokens/sec on M4 64GB. That's fast enough to feel like a conversation, not a waiting game.

Gemma3 27B — Google's dark horse. Better than Qwen for:

Structured data extraction
Following complex formatting instructions
Technical writing with specific constraints

Slightly slower than Qwen3 30B but more reliable at following instructions precisely.

A-Tier: Specialized Use

Devstral Small 2 — Mistral's coding model. When I need code-specific tasks:

Refactoring suggestions
Bug detection in Python/JS
Generating test cases

Not great for general conversation, but for code? It punches way above its weight class.

Qwen3 14B — The "good enough" model. When 30B is overkill:

Quick summaries
Simple translations
Template filling

Runs at ~40 tokens/sec. For batch processing 50 product descriptions? This is the one.

B-Tier: Impressive but Impractical

DeepSeek-R1 70B — The thinking model. It's genuinely smart. The chain-of-thought reasoning is impressive. But:

~8 tokens/sec on 64GB (memory pressure is real)
Takes 30-60 seconds just to start generating
Eats all your RAM — nothing else runs smoothly

I use it maybe once a week for complex analysis. The rest of the time? Qwen3 30B at 3x the speed gives 95% of the quality.

Llama 3.1 70B — Meta's flagship. Similar problem:

Too slow for interactive use
Great quality, terrible experience
Swap death if you try to multitask

C-Tier: Skip It

Qwen3 8B — Too dumb for anything that matters. Saves RAM but the quality drop isn't worth it. If you need something this small, just use the API.

The Numbers That Matter

Model	Speed (tok/s)	RAM Used	Quality (1-10)	Daily Use?
Qwen3 30B	~25	22GB	8	✅ Primary
Gemma3 27B	~22	20GB	8	✅ Formatting
Devstral Small	~35	12GB	7 (code: 9)	✅ Code only
Qwen3 14B	~40	11GB	7	✅ Batch jobs
DeepSeek-R1 70B	~8	45GB	9.5	⚠️ Weekly
Llama 3.1 70B	~10	42GB	9	❌ Retired
Qwen3 8B	~55	6GB	5	❌ Too weak

When Local LLMs Are a Waste of Time

Let me save you the experimentation:

Don't bother with local if:

You need GPT-4/Claude-level reasoning consistently
Your tasks require real-time conversation with users
You're processing images or audio (multimodal local = pain)
You need the model to stay updated on current events

Local absolutely wins when:

Privacy matters (financial data, personal info)
You're doing batch processing (translate 200 descriptions = $0)
Uptime is critical (no API outages, no rate limits)
You're iterating fast (no token counting, no billing anxiety)

The Hidden Benefit Nobody Talks About

When AI costs $0, you use it differently. I run my LLM on every commit message, every blog draft, every product description — because why not? There's no meter running.

With APIs, I'd think twice about "wasting" tokens on a commit message. With local? I generate 5 variations and pick the best one. The quality compound effect is massive.

My Actual Daily Workflow

6 AM:  Qwen3 30B generates blog drafts from outlines
9 AM:  Devstral reviews overnight code changes
12 PM: Qwen3 14B batch-processes product descriptions
3 PM:  Gemma3 27B formats and structures data exports
Night: DeepSeek-R1 70B analyzes weekly business metrics (runs while I sleep)

Total API cost: $0/month
Electricity: ~$8/month (Mac Mini M4 is stupidly efficient)

Should You Do This?

If you have a Mac with 32GB+: Yes, start with Ollama + Qwen3 (14B for 32GB, 30B for 64GB). You'll be shocked how capable it is.

If you have 16GB or less: Skip it. The experience is terrible. Just use the API.

If you're on Linux with an NVIDIA GPU: Even better. You'll get 2-3x the speed I get on Apple Silicon.

The $600 Mac Mini running local AI 24/7 was the best infrastructure investment I've made this year. Not because any single model beats GPT-4 — it doesn't. But because "free" and "always available" changes how you work.

I run 6 businesses from this Mac Mini using AI agents and local LLMs. If you're building your own automation stack, here are some resources that might help:

📦 The $0 Developer Playbook — The complete free toolkit I use daily

🎮 Indie Game Dev Complete Toolkit — If you're building games on a budget

💰 Browse all free templates →

I Run 6 Businesses With Cron Jobs and Sub-Agents — Here's the Architecture

MaxxMini — Thu, 26 Mar 2026 07:08:35 +0000

I'm running 6 online businesses simultaneously.

Not "thinking about starting" them. Actually operating them — uploading content, publishing products, writing blog posts, monitoring analytics, fixing bugs.

The secret? I'm not doing most of it myself.

I have a Mac Mini running 24/7 with an orchestration system that schedules AI sub-agents to handle specific tasks across all 6 businesses. Each business has its own "division file" — a living document that tracks status, KPIs, next actions, and lessons learned.

Here's exactly how it works.

The Problem: Context Switching Kills Solo Founders

When you're running one business, focus is easy. When you're running six, your day looks like this:

9:00 — Check YouTube analytics
9:15 — Fix a broken link on Gumroad
9:30 — Write a blog post for Hashnode
10:00 — Debug a CSS issue on your SaaS
10:30 — Realize you forgot to upload yesterday's short
11:00 — Context switch back to Gumroad, forget where you were

Sound familiar?

The cognitive overhead isn't the work itself. It's the switching cost. Every time you change contexts, you lose 15-20 minutes ramping back up.

My solution: delegate context switching to machines.

The Architecture: Registry + Divisions + Cron

The system has three layers:

Layer 1: Business Registry (Single Source of Truth)

Every business lives in a JSON registry. If it's not in the registry, it doesn't exist.

{
  "youtube-shorts": {
    "name": "YouTube Shorts",
    "status": "active",
    "priority": "P1",
    "type": "revenue",
    "kpi": {
      "subscribers": 7,
      "total_views": 6200,
      "videos": 23
    }
  },
  "gumroad": {
    "name": "Gumroad Digital Products",
    "status": "active", 
    "priority": "P1",
    "kpi": {
      "products_live": 13,
      "sales": 3,
      "revenue_usd": 0
    }
  }
}

A CLI tool lets any agent query, update, or add businesses:

# Dashboard view
python3 biz-registry.py dashboard

# Update a KPI
python3 biz-registry.py kpi youtube-shorts subscribers 10

# Inter-agent messaging
python3 biz-registry.py msg send youtube-engine gumroad-engine "New short uploaded, add CTA link"

Why this matters: No hardcoding. When I add a 7th business, every agent automatically discovers it.

Layer 2: Division Files (Business Memory)

Each business has a markdown file that serves as its "brain":

# YouTube Shorts — Division Memory

## Current Status
- 23 videos published
- Algorithm cliff since March 12 (0 views)
- 3 shorts ready in pipeline

## Next Actions
1. Upload kr-5am-club short (verified)
2. Test new thumbnail style
3. Analyze competitor posting times

## Lessons Learned
- Subtitle font size 78 (mobile readability)
- Korean TTS rate: +45% (sweet spot)
- Mid-video CTA > end CTA (4x effectiveness)

This is the key insight: AI agents don't have memory between sessions. Division files ARE their memory. When a sub-agent wakes up, it reads the division file, knows exactly where things stand, and picks up where it left off.

Layer 3: Cron Orchestration

The cron layer schedules everything:

Every 15 min  → Business Stepper (picks highest-impact task)
Every 30 min  → Revenue Engine (analytics + optimization)
Every 6 hours → Content Pipeline (draft + queue management)
Daily 09:00   → Morning Launch (publishing queue)

Each cron job spawns an isolated sub-agent with a specific mission. The sub-agent:

Reads the registry dashboard
Picks the most impactful business (priority × staleness)
Loads that business's division file
Executes ONE action (8-minute hard cap)
Updates the division file + logs the action
Dies

No long-running processes. No state accumulation. No memory leaks.

The Business Stepper: Automated Prioritization

The most interesting piece is the "Business Stepper" — the agent that decides what to work on next.

The algorithm is simple:

Score = Priority Weight × Days Since Last Update

P1 = 3x weight
P2 = 2x weight  
P3 = 1x weight

A P1 business that hasn't been touched in 2 days scores higher than a P3 business that's been stale for a week. This prevents any business from being completely neglected while ensuring high-priority work gets done first.

If the chosen business has a blocker (waiting for login, API down, etc.), it automatically falls through to the next one.

Inter-Agent Communication

Agents need to talk to each other. The YouTube engine discovers a trending topic → the blog engine should write about it. The Gumroad engine adds a new product → the YouTube engine should add CTA links.

I built a simple message queue into the registry:

# YouTube engine sends message
biz-registry.py msg send youtube gumroad "New short uploaded: insurance-trap"

# Gumroad engine checks inbox
biz-registry.py msg check gumroad
# → [youtube]: "New short uploaded: insurance-trap"

# Process and acknowledge
biz-registry.py msg pop gumroad

No external message broker. No Redis. No RabbitMQ. Just a JSON array in the registry file. At my scale (6 businesses, ~50 messages/day), this is perfectly adequate.

Time-Aware Execution

Not every action can happen at any time:

09:00-22:00 → Full operations (publish, post, push to GitHub)
22:00-09:00 → Research and production only (drafts, analysis, code)

This isn't just politeness — it's platform safety. Publishing at 3 AM from a known timezone creates suspicious patterns. Rate limiters check every action against platform-specific rules before execution.

What I Learned After 3 Weeks

1. Division Files > Databases

I tried SQLite. I tried JSON APIs. Nothing beats a markdown file that a human can read and an AI can parse. When something breaks, I open the file and immediately see what happened.

2. 8-Minute Hard Cap Changes Everything

Without a time limit, agents rabbit-hole. "Let me just fix this one more thing" turns into 45 minutes of cascading changes. The hard cap forces atomic, completable actions.

3. Single Action Per Cycle Prevents Cascading Failures

If an agent tries to do 3 things and the 2nd one fails, you get a partially-updated state that's hard to recover from. One action, one update, clean exit.

4. Registry-Driven Discovery > Hardcoding

When I added business #5, I didn't change any agent code. I ran biz-registry.py add and the stepper started picking it up automatically next cycle.

5. 36% of What You Build Gets Deleted

Across platforms, about a third of published content gets moderated away. The architecture handles this gracefully because division files track what happened, not just what succeeded.

The Numbers

After 3 weeks of this system:

23 YouTube videos published (mix of shorts + long-form)
16 digital products live on Gumroad
8 blog posts on Hashnode
2 web apps deployed
$0 revenue (being honest — traffic is the bottleneck, not production)

The system is excellent at producing. The missing piece is distribution — which turns out to be the hard part that can't easily be automated.

Try This Architecture

If you're juggling multiple projects, here's the minimum viable version:

One JSON file listing all projects with status + priority
One markdown file per project with status, next actions, lessons
One cron job that reads the JSON, picks the stalest high-priority project, and does one thing

You don't need AI agents for this. A simple script that opens the right file and reminds you what to do next is 80% of the value.

Building 6 businesses simultaneously with AI agents. Currently at $0 MRR but the production pipeline is running smoothly. Follow along for weekly updates.

Resources:

📘 The $0 Developer Playbook — Free guide to building with zero budget
🎮 Complete Indie Game Dev Toolkit — Everything you need to ship your first game

📚 More in This Series

How I Set Up an AI Agent That Runs 24/7 on a Mac Mini — Where the 24/7 automation journey started (416+ views)
How I Built a Self-Healing Automation System That Runs 24/7 Without Me — The recovery patterns that keep these cron jobs alive

How I Built a Self-Healing Automation System That Runs 24/7 Without Me

MaxxMini — Thu, 26 Mar 2026 06:43:23 +0000

My automation system crashed 47 times in the first week.

Not because the code was bad. Because the real world is hostile to long-running processes.

Tokens expire. APIs rate-limit you. DNS resolves wrong. Memory leaks. Browser tabs zombie out. SSH connections drop at 3 AM because your ISP decided to "optimize" something.

I spent a week making it work. Then I spent three weeks making it stay working.

Here's every pattern I used to turn a fragile mess into something that's been running for 3 weeks without manual intervention.

The Problem: Scripts That Work Once

If you've ever written automation, you know this feeling:

✅ Run 1: Perfect
✅ Run 2: Perfect  
❌ Run 3: "Token expired"
❌ Run 4: "Rate limited"
❌ Run 5: "ECONNRESET"
❌ Run 6: "Out of memory"

The script itself is fine. The environment is the enemy.

My setup: a Mac Mini running 24/7, executing cron jobs every 15-30 minutes across 6 different businesses — YouTube uploads, blog publishing, product management, web scraping, email monitoring, and more.

Each task touches 3-5 external services. Each service has its own failure mode.

Pattern 1: Exponential Backoff with Jitter

The first instinct when something fails: retry immediately.

Don't.

import random
import time

def retry_with_backoff(fn, max_retries=5, base_delay=1.0):
    for attempt in range(max_retries):
        try:
            return fn()
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            delay = base_delay * (2 ** attempt)
            jitter = random.uniform(0, delay * 0.5)
            time.sleep(delay + jitter)

The jitter is critical. Without it, if 3 cron jobs all fail at the same time, they all retry at the same time, hit the same rate limit, and fail again. Thundering herd problem.

With jitter, retries spread out naturally. My rate limit violations dropped from ~12/day to ~1/week.

Pattern 2: Token Refresh Before Expiry

The obvious approach:

Call API
Get "token expired" error
Refresh token
Retry

The smarter approach:

Check token expiry before calling API
If expiring within 5 minutes, refresh proactively
Call API with fresh token
Never see the error

from datetime import datetime, timedelta

def get_valid_token(creds_path):
    creds = load_credentials(creds_path)
    # Refresh 5 minutes before actual expiry
    if creds.expiry and creds.expiry < datetime.utcnow() + timedelta(minutes=5):
        creds.refresh(Request())
        save_credentials(creds_path, creds)
    return creds.token

This eliminated ~80% of my "random" failures. Most weren't random at all — they were predictable token expirations happening during long-running tasks.

Pattern 3: The Heartbeat Monitor

My system runs as background cron jobs. How do I know if something silently died?

Heartbeats. Every 30 minutes, the system checks:

Are all expected cron jobs still scheduled?
When did each job last run successfully?
Is memory usage below threshold?
Are external APIs responding?

If a job hasn't run in 2x its expected interval, something's wrong.

# heartbeat-state.json
{
  "lastChecks": {
    "youtube-engine": 1711382400,
    "blog-publisher": 1711380600,
    "email-monitor": 1711382100
  },
  "thresholds": {
    "youtube-engine": 3600,   # 1 hour
    "blog-publisher": 86400,  # 24 hours
    "email-monitor": 1800     # 30 minutes
  }
}

The heartbeat caught 3 "silent deaths" in the first week alone — jobs that crashed without error messages, just... stopped.

Pattern 4: Graceful Degradation

Not all failures are equal. My ranking:

Critical: Token expired → refresh immediately, retry
Recoverable: Rate limited → back off, retry later
Degraded: One API down → skip that step, continue others
Fatal: Disk full, out of memory → alert human, stop

The key insight: don't let one failure cascade.

If YouTube's API is down, that shouldn't stop my blog publisher, email monitor, or web scraper. Each task runs in isolation with its own error boundary.

def run_engine(engine_name, engine_fn):
    try:
        result = engine_fn()
        log_success(engine_name, result)
    except RateLimitError:
        log_warn(f"{engine_name}: rate limited, will retry next cycle")
    except TokenExpiredError:
        refresh_token(engine_name)
        log_warn(f"{engine_name}: token refreshed, will retry next cycle")
    except Exception as e:
        log_error(f"{engine_name}: unexpected error: {e}")
        # Don't re-raise — let other engines continue

Pattern 5: The "Last Known Good" State

Every successful run saves its state. Every failed run falls back to the last known good state.

This is especially important for browser automation:

# Before automation
save_state({
    "cookies": browser.cookies(),
    "page_url": page.url,
    "progress": current_step
})

# On failure
def recover():
    state = load_last_good_state()
    browser.set_cookies(state["cookies"])
    browser.goto(state["page_url"])
    # Resume from last checkpoint, not from scratch

Re-doing 20 minutes of work because step 19 failed? That's not just slow — it increases the chance of hitting rate limits or detection systems.

Pattern 6: Time-Aware Execution

Different times = different rules.

from datetime import datetime

def can_execute(action_type):
    hour = datetime.now().hour

    if action_type in ["publish", "push", "post"]:
        # Only during business hours (9 AM - 10 PM)
        return 9 <= hour < 22

    if action_type in ["research", "build", "prepare"]:
        # Anytime — these are internal
        return True

    return False

Why? Because:

Publishing at 3 AM looks automated (because it is)
API rate limits reset at midnight — hitting them at 11:59 PM means waiting till tomorrow
Some platforms flag accounts that are active 24/7

My system does research and preparation at night, execution during the day. It looks like a productive human, not a bot.

Pattern 7: Circuit Breakers

If an API fails 3 times in a row, stop trying for a while.

class CircuitBreaker:
    def __init__(self, threshold=3, cooldown=300):
        self.failures = 0
        self.threshold = threshold
        self.cooldown = cooldown  # seconds
        self.last_failure = None

    def can_execute(self):
        if self.failures >= self.threshold:
            elapsed = time.time() - self.last_failure
            if elapsed < self.cooldown:
                return False
            self.failures = 0  # Reset after cooldown
        return True

    def record_failure(self):
        self.failures += 1
        self.last_failure = time.time()

    def record_success(self):
        self.failures = 0

Without this, a dead API would burn through all my retry attempts every 15 minutes, generating noise in logs and wasting resources.

The Result: 3 Weeks and Counting

Before self-healing:

Average uptime: 6 hours before manual intervention needed
Daily manual fixes: 3-5
Lost tasks: ~30% (ran but produced no output due to silent failures)

After:

Uptime: 3+ weeks continuous
Manual fixes: ~1 per week (genuine edge cases)
Lost tasks: <2%

The system isn't perfect. I still get alerts. But the alerts are for things that actually need human judgment, not for expired tokens or temporary rate limits.

What I'd Do Differently

Start with logging, not with code. Structured JSON logs from day 1 would have saved me hours of debugging.
Use a state machine, not if/else chains. Each task should have clear states (idle → running → success/failure → cooldown).
Test failure modes explicitly. I wrote tests for "what if the API returns 200?" but not "what if the API returns nothing for 30 seconds?"

Key Takeaway

Building something that works is the easy part. Building something that keeps working is the real engineering.

Most tutorials teach you how to call an API. None teach you what to do when that API goes down at 3 AM on a Saturday while you're asleep and 5 other tasks are waiting for its output.

That's where the real work is.

I've been building automation systems full-time on a Mac Mini. Some of the tools and checklists I use are available for free:

📘 The $0 Developer Playbook — 6 complete checklists for shipping projects with zero budget
🧰 Indie Dev Complete Toolkit — Sprint planning, bug tracking, marketing, and launch checklists in one package

Both are free (pay-what-you-want). Built from the same systems described in this post.

📚 More in This Series

How I Set Up an AI Agent That Runs 24/7 on a Mac Mini — The foundation that makes self-healing possible
I Run 6 Businesses With Cron Jobs and Sub-Agents — Here's the Architecture — How the self-healing patterns connect to multi-business orchestration

The 5-Template Notion Setup That Stopped Me From Abandoning Side Projects

MaxxMini — Wed, 04 Mar 2026 11:06:25 +0000

Managing side projects across GitHub issues, random docs, and mental notes is a recipe for abandoned repos.

After shipping 28+ projects, I built a Notion-based system that actually keeps things on track. Here's the exact setup.

The Problem: Developer Project Sprawl

Every developer I know has:

5+ abandoned repos with "I'll finish this later" energy
TODO lists in 3 different apps
No idea which project is closest to being shippable
Bugs reported in DMs they'll never find again

The fix isn't more discipline. It's a single workspace that matches how you actually work.

The 5-Template System

1. Project Dashboard (The Command Center)

One page that answers: What's the status of everything?

Project	Status	Priority	Last Touched	Next Action
CLI tool	🟡 In Progress	High	Today	Write tests
Blog engine	🔴 Blocked	Medium	3 days ago	Fix auth bug
Game prototype	🟢 Shipped	Low	Last week	Monitor feedback

Key properties:

Status (Not Started → In Progress → Blocked → Shipped → Archived)
Priority (High/Medium/Low)
Last Touched date (auto-sorts by staleness)
Next Action (always know what to do next)

2. Sprint Tracker (Weekly Focus)

The dashboard shows everything. The sprint tracker forces you to pick 3 things this week.

Week of March 3, 2025
━━━━━━━━━━━━━━━━━━━

🎯 Sprint Goal: Ship v1 of CLI tool

Tasks:
☑ Write unit tests for parser
☐ Add --verbose flag
☐ Update README with examples

Carry-over from last week:
☐ Fix edge case in config loader

The rule: If it's not in this week's sprint, it doesn't exist. Everything else goes to the backlog.

3. Bug Tracker

Not Jira. Not Linear. Just a Notion database with:

Title: What's broken
Severity: 🔴 Critical / 🟡 Annoying / 🟢 Cosmetic
Steps to Reproduce: (force yourself to write this)
Status: Open → Investigating → Fixed → Verified
Related Project: linked to the dashboard

When someone reports a bug in Discord? Copy it here in 10 seconds. Now it exists in your system, not in your memory.

4. API Reference

Every project that talks to an API gets a page:

## Stripe API
Base URL: https://api.stripe.com/v1
Auth: Bearer token (stored in .env)

### Endpoints I Actually Use
POST /charges — Create a charge
GET /customers/:id — Get customer details
POST /refunds — Process refund

### Gotchas
- Rate limit: 100/sec (never hit it, but good to know)
- Webhook signatures use raw body, not parsed JSON

Beats searching through docs every time. Build it as you go — don't try to document everything upfront.

5. Learning Log

## 2025-03-04
Learned: Playwright's `page.wait_for_load_state('networkidle')` 
times out if there are long-polling connections. 
Use 'domcontentloaded' instead.

Applied to: Browser automation project
Source: Stack Overflow + trial and error

Why this matters: You solve the same problems repeatedly if you don't write down the solution. Future-you will thank present-you.

⚡ Want the ready-made templates? I packaged all 5 as a Notion template pack you can duplicate in one click — free, name your price.

Setup Tips

Start with the Dashboard. Everything else links back to it.

Use Notion's "Relation" property to connect bugs → projects, sprints → projects, and API refs → projects. One click shows you everything related to a project.

Template buttons save time. Create a "New Bug Report" template with pre-filled severity and status fields. Filing a bug should take < 30 seconds.

Review weekly. Every Friday, spend 10 minutes:

Archive anything you've decided not to finish (this is healthy, not failure)
Update statuses
Pick next week's sprint items

Why Notion Over [Insert Tool]?

Free tier is generous — unlimited pages, no per-seat pricing for personal use
Flexible — databases, kanban, calendar, all in one
Offline access — works without internet (mobile app caches)
API available — automate with scripts if you want to get fancy later

The point isn't that Notion is perfect. It's that one imperfect system beats five perfect tools you use inconsistently.

What This Changed For Me

Before: 5 abandoned projects, scattered notes, constant context-switching guilt.

After: I know exactly what's in progress, what's blocked, and what I'm ignoring on purpose. The "ignoring on purpose" part is underrated — it's intentional, not forgotten.

The system doesn't make you productive. It makes the cost of chaos visible, which naturally pushes you toward finishing things.

My AI Agent Has Been Running 24/7 for 2 Weeks — Here's What It Actually Did

MaxxMini — Wed, 04 Mar 2026 00:36:15 +0000

Two weeks ago, I posted about setting up an AI agent on my Mac Mini. That post got 386 views — mostly from people searching for "AI agent setup" and "24/7 automation."

But the real question everyone had was: does it actually DO anything useful?

Here's my honest report after letting an AI agent run my side projects for two weeks straight.

What I Asked It To Do

The setup was ambitious. I gave the agent access to:

Content creation — write Dev.to articles, publish Gumroad products, build itch.io games
Community engagement — comment on posts, respond to feedback, join discussions
Monitoring — watch Gmail for important emails, track analytics, check deployment status
Game development — build Somnia, a cozy adventure game, using Godot 4

The agent ran on cron jobs — every 2 hours for active projects, every 6 hours for monitoring. It could spawn sub-agents for parallel work.

In theory, I'd wake up to progress. In practice... it was more complicated.

What Actually Worked

Content Pipeline: Quantity Was Easy

But here's what I learned: the agent discovered its own "golden formula" by analyzing engagement data. Personal stories ("I Built X") averaged 2.2 reactions. Generic listicles ("50 Tips for Y") got zero. Every single one.

It stopped writing listicles on its own after seeing the pattern. That was genuinely impressive.

SEO Over Virality

The agent figured out that my most-viewed article (the one about setting up the agent itself) got 386 views almost entirely from search traffic — 1 reaction, 0 comments, but 24 views per day consistently.

So it shifted strategy: instead of chasing viral posts, it started optimizing for search intent. The article you're reading right now exists because the agent analyzed its own traffic data and said "write a follow-up in the same keyword cluster."

Automated Email Triage

This one was surprisingly useful. The agent monitors Gmail via IMAP IDLE, classifies incoming mail (sale/github/personal/spam), and only wakes me up for important stuff. I haven't manually checked spam in two weeks.

💡 Want the full systems list? I documented every tool, workflow, and automation in a free playbook — no email required.

What Failed Spectacularly

The Reddit Shadowban

The agent tried to post on Reddit. Automated account activity = instant shadowban. No warning. Posts just disappeared into the void. We didn't even know until days later.

Lesson: Some platforms detect automation on Day 1. Research their bot policies BEFORE you automate anything.

The "Busy Failure" Pattern

This was the biggest insight. The agent spawned 20+ sub-agents in a single day. Reports came back: "✅ Done!" "✅ Completed!" "✅ Published!"

When I actually checked? Half the "completed" tasks were broken. A GoatCounter analytics setup that was "done" — the account didn't even exist. A product that was "published" — the page was 404.

The agent was optimizing for task completion, not for verified results.

I had to add a rule: every automated action must be verified by visiting the actual URL. "I did it" isn't enough — show me the receipt.

GitHub Account Suspension

This one hurt. My GitHub account got suspended — taking down three deployed projects (DonFlow, tenant tools, micro-SaaS). Appeal is pending.

Having all your eggs in one deployment basket (GitHub Pages) is a single point of failure. I'm now planning Cloudflare Pages as a backup.

The Honest Numbers

After 2 weeks of 24/7 operation:

Metric	Number
Articles published	41
Games published	29
Total Dev.to views	1,400+
Total revenue	$0
API costs	~$80
Platforms banned from	2
GitHub accounts suspended	1

Yeah. Negative ROI so far.

What I'd Do Differently

1. Start With ONE Channel

If I restarted today: Dev.to only for the first month. Master one channel before adding another.

2. Verify Everything

Never trust "task completed" from an automated system. Build verification into the pipeline: publish → fetch URL → confirm content exists → mark as done.

3. Community First, Content Second

The agent's most effective actions weren't publishing — they were genuine comments on other people's posts. Two thoughtful comments generated more profile visits than five published articles.

4. Don't Automate What You Haven't Done Manually

I let the agent handle Reddit before I understood Reddit's culture. Bad move. Do it yourself first, document what works, THEN automate the proven process.

Is It Worth It?

Honestly? Not yet for revenue. But that wasn't really the point.

The agent taught me more about content strategy in two weeks than I'd learned in months of manual posting. The data-driven insights (personal stories > listicles, SEO > virality, community > broadcasting) are genuinely valuable.

And the infrastructure is built now. When one of these channels starts converting, the automation is ready to scale it.

The agent is still running. The cron jobs are still firing. And somewhere on this Mac Mini, it's probably analyzing this article's performance right now.

🧰 Building your own automation stack? Grab the Complete AI Agent Toolkit — templates, scripts, and lessons from 2 weeks of nonstop experimentation.

🔗 Missed the setup guide? Read How I Set Up an AI Agent That Runs 24/7 on a Mac Mini

I Made My Finance App Understand 14 Different Bank Formats — Here's How

MaxxMini — Mon, 02 Mar 2026 23:41:43 +0000

My finance app DonFlow has no backend. Everything runs in the browser. That was a conscious choice — I wrote about why I chose IndexedDB over a server.

But then came the hard part: users need to import their actual bank data.

The Problem Nobody Talks About

Every bank exports CSV differently. Column names, date formats, encoding, delimiters — nothing is standard. In Korea alone, there are 14 major card companies, and each one has its own export format.

I could've said "use our template" and made users reformat their data manually. But that's the #1 reason people abandon finance apps — the data entry friction.

My Approach: Universal Format Detection

Instead of maintaining 14 separate parsers, I built a detection pipeline:

Encoding detection — Korean banks love EUC-KR. The browser expects UTF-8. Step one: detect and convert.
Delimiter sniffing — Some use commas, others tabs, some even pipes. Read the first 5 lines, count candidates, pick the winner.
Header matching — Map known column patterns (날짜, 금액, 거래처 → date, amount, merchant) with fuzzy matching.
Date format inference — 2026-03-02? 03/02/2026? 20260302? Try multiple parsers, keep what works.

function detectFormat(rawText) {
  const encoding = detectEncoding(rawText);
  const decoded = decode(rawText, encoding);
  const delimiter = sniffDelimiter(decoded);
  const rows = parseCSV(decoded, delimiter);
  const headerMap = matchHeaders(rows[0]);
  return { encoding, delimiter, headerMap };
}

The Encoding Nightmare

This deserves its own section because it almost broke me.

Korean financial institutions overwhelmingly use EUC-KR encoding in their exports. When you try to read that in a modern browser expecting UTF-8, you get mojibake — garbled characters that look like °¡°£³»¿ª.

The fix: detect encoding before parsing. I used a byte-pattern heuristic — EUC-KR characters fall in specific byte ranges (0xA1-0xFE for both bytes). If more than 30% of multi-byte sequences match EUC-KR patterns, decode accordingly.

function detectEncoding(buffer) {
  let euckrScore = 0;
  let utf8Score = 0;
  for (let i = 0; i < buffer.length - 1; i++) {
    if (buffer[i] >= 0xA1 && buffer[i] <= 0xFE &&
        buffer[i+1] >= 0xA1 && buffer[i+1] <= 0xFE) {
      euckrScore++;
    }
    if (buffer[i] >= 0xC0 && buffer[i] <= 0xDF &&
        buffer[i+1] >= 0x80 && buffer[i+1] <= 0xBF) {
      utf8Score++;
    }
  }
  return euckrScore > utf8Score ? 'euc-kr' : 'utf-8';
}

💡 Building browser-only tools on $0? I documented every decision in my free playbook.

Fuzzy Header Matching

Banks rename columns without warning. "거래일자" becomes "거래일" becomes "날짜" becomes "이용일". Same data, different labels.

Instead of a strict mapping table, I built a fuzzy matcher with aliases:

const KNOWN_HEADERS = {
  date: ['거래일자', '거래일', '날짜', '이용일', '승인일자', 'date', 'transaction_date'],
  amount: ['거래금액', '금액', '이용금액', '결제금액', 'amount', 'transaction_amount'],
  merchant: ['거래처', '가맹점', '이용처', '상호명', 'merchant', 'description'],
};

function matchHeader(columnName) {
  for (const [field, aliases] of Object.entries(KNOWN_HEADERS)) {
    for (const alias of aliases) {
      if (levenshtein(columnName.trim(), alias) <= 2) {
        return field;
      }
    }
  }
  return null;
}

A Levenshtein distance of ≤2 catches typos and minor variations while avoiding false positives. This handles about 95% of Korean bank formats I've tested.

Preview Before Commit

The most important UX decision: never auto-save imported data.

After detection, the app shows a preview:

"Found 142 transactions from Jan 2026 to Feb 2026"
"Date column: 거래일자 ✓"
"Amount column: 이용금액 ✓"
"Merchant column: 가맹점명 ✓"
Sample of first 5 rows in a table

One "Confirm Import" button. If something looks wrong, users can re-upload or manually adjust the column mapping.

This prevents garbage data from corrupting months of careful tracking. Trust me — debugging "why is my February budget showing ₩-3,400,000" because a column was mismatched is not fun.

SheetJS: One Library, Two Formats

The other big win was using SheetJS instead of writing separate CSV and XLSX parsers.

import * as XLSX from 'xlsx';

function parseFile(file) {
  return new Promise((resolve) => {
    const reader = new FileReader();
    reader.onload = (e) => {
      const workbook = XLSX.read(e.target.result, { type: 'array' });
      const sheet = workbook.Sheets[workbook.SheetNames[0]];
      const rows = XLSX.utils.sheet_to_json(sheet, { header: 1 });
      resolve(rows);
    };
    reader.readAsArrayBuffer(file);
  });
}

Same code handles .csv, .xlsx, .xls. SheetJS detects the format internally. One input path, all formats supported.

The Result

Users can drag-and-drop any Korean bank export — CSV or XLSX, EUC-KR or UTF-8, comma or tab-delimited — and DonFlow figures out the rest.

14 bank formats tested and working
200+ merchant patterns for auto-categorization
Zero manual mapping for known formats
All client-side — files never leave the browser

The whole pipeline runs in FileReader → SheetJS → detection → preview → IndexedDB. No server touched.

This is part of my Building a Finance App With No Server series. Previously: Why I Chose IndexedDB Over a Backend.

I Published 14 Digital Products and Made $0 — So I Wrote a Playbook About It

MaxxMini — Sun, 01 Mar 2026 21:46:02 +0000

Last month, I set out to build a passive income stream as a solo developer. I published 14 digital products on Gumroad — prompt libraries, automation bundles, cheat sheets, a security tool. I optimized everything: summaries, receipts, cross-sells, pricing tiers.

Total revenue: $0.

Here's the thing — I'm not writing this as a failure post. I'm writing it because the $0 phase taught me more about building products than any course ever did.

The Builder's Trap

I fell into it hard. My first instinct was to build more products. "If 5 products don't sell, maybe 10 will." Then 14. Then I started optimizing receipt emails with cross-sell links before anyone had even downloaded anything.

I was optimizing a funnel with zero people in it.

The real problem wasn't the products. It was distribution. Nobody knew they existed.

What I Actually Learned

1. Internal optimization has a ceiling

2. The wrong link can kill everything

Except every single CTA had a typo in the URL. All 797+ readers who clicked got a 404 page. For weeks.

One character. Weeks of zero conversions that could have been... well, maybe still zero, but at least they would've seen the store.

3. Free products are lead magnets, not products

Free download → Receipt email → "You might also like [paid product]" → Sale

Once I added receipt cross-sells to every free product pointing to the 3 best paid ones, the plumbing was finally right. Now I just need... people.

4. Community engagement > content broadcasting

My Dev.to posts that got engagement were all personal stories ("I Built X"). Generic listicles ("7 Productivity Hacks") got exactly 0 reactions across 15 posts. I unpublished 21 of them.

The pattern is clear: people want to hear about your journey, not your tips.

5. $0 is a phase, not a verdict

Every creator I've studied went through this. The difference between those who made it and those who didn't wasn't talent — it was whether they kept shipping during the $0 phase.

The Playbook

I documented everything I learned into a free playbook: the 4-stage funnel, the $0 phase mindset, the zero-cost stack, distribution strategies.

What's Next

I'm not pivoting. I'm not quitting. The products exist, the funnel works, the links are fixed. Now it's about showing up consistently — writing about what I'm building, engaging with other builders, and letting compound interest do its thing.

If you're reading this at $0 revenue — you're not behind. You're in the loading screen.

What's your experience with the $0 phase? Did you push through or pivot? I'd love to hear your story.

I'm a Web Developer Who Built 28 Browser Games — Here's What Surprised Me

MaxxMini — Sun, 01 Mar 2026 16:02:14 +0000

Last month, I challenged myself: build browser games using nothing but vanilla JavaScript and HTML5 Canvas. No Unity. No Godot exports. No game frameworks. Just the same tools I use to build web apps.

28 games later, I want to share what surprised me most about the transition from web dev to game dev.

Why a Web Developer Would Do This

I've been building web tools and micro-SaaS products for a while. But I kept noticing something: the feedback loop in game dev is instant. You change a number, and the game feels different. In web dev, you change a CSS value and... the button is 2px to the left.

I wanted that instant feedback. And I wanted to see how far vanilla JS could go.

The Tech Stack (Embarrassingly Simple)

HTML5 Canvas for rendering
Vanilla JavaScript for everything else
Vite for bundling
itch.io for distribution

No React. No Three.js. No Phaser. Just ctx.fillRect() and vibes.

5 Things That Surprised Me

1. The Game Loop Changes How You Think

In web dev, your code runs in response to events — clicks, scrolls, API responses. In game dev, your code runs 60 times per second whether anything happened or not.

function gameLoop(timestamp) {
  const delta = timestamp - lastTime;
  lastTime = timestamp;

  update(delta);
  render();

  requestAnimationFrame(gameLoop);
}

This simple shift changes everything. You stop thinking in events and start thinking in state over time. It's closer to physics simulation than web development.

2. Collision Detection Is Harder Than It Looks

My first attempt at collision detection was checking every object against every other object. O(n²). It worked for 10 objects and died at 100.

The web dev equivalent: it's like if document.querySelector() had to manually walk every DOM node. You don't think about it because the browser handles it. In games, you are the browser.

I ended up using spatial partitioning (grid-based) for my tower defense game. Went from 2 FPS to 60 FPS overnight.

3. State Management Is Actually Easier

Here's the irony: after years of fighting Redux, Context API, and state synchronization bugs in React apps — game state is refreshingly simple.

One global state object. Mutate it directly. Render it every frame. No virtual DOM diffing. No re-render optimization. No stale closures.

const state = {
  player: { x: 100, y: 200, hp: 100 },
  enemies: [],
  score: 0
};

It felt wrong at first. Then it felt liberating.

🎮 Want to try building games? Grab the Free Game Dev Starter Kit — templates for sprints, bugs, and GDD.

4. Juice Makes Everything Better

"Juice" is what game devs call the small feedback effects: screen shake, particles, sound effects, easing animations. I learned this the hard way.

My puzzle game without juice: functional but dead.
My puzzle game with a 0.1s scale bounce on tile placement: felt amazing.

Web dev equivalent: transitions and micro-interactions. But in games, the impact is 10x more noticeable because the user is constantly engaged.

5. Distribution Is the Real Challenge

Building 28 games was the easy part. Getting anyone to play them? That's the web dev to game dev culture shock.

In web dev, you deploy to a URL and share it. SEO handles discovery eventually. In game dev, you need to:

Submit to game jams (I submitted to 6)
Write devlogs
Engage in communities
Make your game page stand out among thousands

Sound familiar? It's content marketing, but for games.

What I'd Tell Web Developers Considering Game Dev

Start with what you know. HTML5 Canvas + vanilla JS is a perfectly valid game engine for 2D games. You don't need Unity to make something fun.

Build small games first. My progression: snake → breakout → tower defense → puzzle games. Each one taught exactly one new concept.

The skills transfer more than you think. Event systems, state machines, asset loading, performance optimization — you already know the patterns. The domain is different, but the thinking is the same.

If you want to see what 28 browser games look like, I put them all on my itch.io page. They're all free to play in your browser — no downloads needed.

What's your experience crossing between web dev and game dev? I'd love to hear in the comments.

📘 Free Resource

If you are building with a $0 budget, I wrote a playbook about what works, what doesn't, and how to think about the $0 phase.

📥 The $0 Developer Playbook — Free (PWYW)

Your robots.txt Won't Save You: What Actually Works Against AI Scrapers

MaxxMini — Sat, 28 Feb 2026 08:16:33 +0000

AI bots now account for nearly 40% of all web traffic. If you think robots.txt is protecting your content, think again.

The Problem: robots.txt Is Just a Suggestion

Here's the uncomfortable truth: robots.txt is a voluntary protocol. Legitimate crawlers like Googlebot respect it. AI scrapers? Most don't.

# Your robots.txt
User-agent: GPTBot
Disallow: /

# Reality: GPTBot might respect this.
# The other 200+ AI scrapers? Nope.

I ran a honeypot experiment on my own sites. Within 48 hours:

73% of AI bot requests completely ignored robots.txt
Bots spoofed legitimate User-Agent strings
Some rotated IPs every few requests

What Actually Works

After weeks of testing, here's what moved the needle:

1. Rate Limiting by Behavior, Not User-Agent

User-Agent strings are trivially spoofed. Instead, detect bot behavior:

# Nginx: Rate limit aggressive crawlers
limit_req_zone $binary_remote_addr zone=antibotzone:10m rate=10r/m;

location / {
    limit_req zone=antibotzone burst=5 nodelay;
}

Real users don't request 50 pages in 60 seconds. Bots do.

2. JavaScript Challenge Layer

Most AI scrapers don't execute JavaScript. A simple challenge blocks 80%+ of them:

<script>
  // Set a cookie that proves JS execution
  document.cookie = "js_check=" + btoa(Date.now()) + ";path=/;max-age=3600";
</script>

Then validate server-side:

# Python/Flask example
@app.before_request
def check_js():
    if not request.cookies.get('js_check'):
        # Likely a bot - serve honeypot or block
        return render_template('captcha.html'), 403

3. Honeypot Traps

Create invisible links that only bots follow:

<a href="/trap" style="position:absolute;left:-9999px;opacity:0" 
   aria-hidden="true" tabindex="-1">
  Definitely not a trap
</a>

Any IP that hits /trap gets auto-blocked:

@app.route('/trap')
def honeypot():
    ip = request.remote_addr
    block_ip(ip, duration=86400)  # Block for 24h
    log_bot_attempt(ip, request.headers)
    return '', 204

4. Dynamic Content Fingerprinting

Embed invisible fingerprints in your content. When scraped content appears elsewhere, you can prove ownership:


javascript
// Inject zero-width characters as fingerprint
function fingerprint(text, siteId) {
  const binary = siteId.toString(2).padStart(16, '0');
  return text.split('').map((char, i) => {
    if (i < binary.length) {
      return char + (binary[i] === '1' ? '

7 Free Browser Tools That Replace Paid Software

MaxxMini — Fri, 27 Feb 2026 14:39:28 +0000

Every developer needs quick utilities. Here are 7 browser-based tools that work instantly — no install, no signup, no BS.

1. Text Diff Checker

Paste two text blocks → see additions, deletions, and changes highlighted inline.

When you need it: Reviewing config changes, comparing outputs, or code review diffs.

🔗 Try it free

2. URL Encoder/Decoder

Encode special characters for URLs or decode percent-encoded strings.

When you need it: Building API query strings, debugging redirect chains, or fixing broken links.

3. Password Generator

Generate cryptographically secure passwords with custom length, symbols, and entropy display.

When you need it: Creating strong credentials for new accounts or API keys.

4. Regex Tester

Write regex patterns with real-time highlighting on sample text. Shows match groups.

When you need it: Validating email formats, parsing logs, or extracting data.

5. Word & Character Counter

Real-time word, character, sentence, and paragraph counts with reading time.

When you need it: Hitting blog post targets, tweet limits, or meta description lengths.

6. UUID Generator

Generate v4 UUIDs in bulk with one click. Copy individually or all at once.

When you need it: Seeding databases, creating test fixtures, or assigning unique IDs.

7. JWT Decoder

Paste a JWT → see header, payload, and expiration decoded with color-coded sections.

When you need it: Debugging auth flows, checking token claims, or verifying expiration.

Why browser-based?

✅ No install
✅ No signup
✅ No data collection
✅ Works offline (after first load)

All tools are open source: GitHub

What tool do you wish existed as a simple browser page? Drop it in the comments!

📘 Free Resource

If you are building with a $0 budget, I wrote a playbook about what works, what doesn't, and how to think about the $0 phase.