DEV Community: Ashley B

I Turned an Old HP Laptop Into a Linux Automation Server and Learned Why Browser Automation Is a Liar

Ashley B — Tue, 07 Jul 2026 03:54:00 +0000

I Turned an Old HP Laptop Into a Linux Automation Server and Learned Why Browser Automation Is a Liar

There is a very specific kind of optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah. This should run production browser automation.”

This thing had:

6 GB RAM
a mechanical hard drive
integrated AMD graphics
the general aura of a haunted library computer

I had already memorized Alt + PrintScreen + REISUB because the machine had seen things.

Naturally, I decided to turn it into a self-hosted automation server running Playwright workers for PostPunk.

And honestly?

At first, it mostly worked.

The Linux side was fine. Queue workers were fine. Background jobs were fine. Firefox behaved surprisingly well.

Then Chromium entered the chat and everything became spiritually unstable.

The Problem Wasn’t Immediate

The annoying part is that the automation sometimes worked.

Pinterest would post.
Facebook would post.
Dev.to would post.

Then suddenly:

selectors would fail
pages would flicker
interactions would stop working
rendering would glitch out
Chrome would randomly pixelate the display

And the best part?

Rebooting the machine fixed it for about ten minutes.

Which is one of the worst debugging outcomes possible because it tricks you into thinking you solved something.

Headed vs Headless Was the Real Trap

At first I tested everything with a visible browser because I like seeing automation happen.

Honestly, most developers do.

Watching the browser click through workflows makes the system feel real. You can visually confirm:

login state
navigation
selectors
button clicks
page rendering

But on this machine, visible Chromium was apparently part of the problem.

Headed mode flickered constantly. Sometimes opening multiple windows would cause random visual corruption. Firefox looked normal. Chromium behaved like it had unresolved personal issues with Linux.

Ironically, once I moved more flows to headless mode, reliability improved.

Not because the automation logic changed.

Because the machine stopped trying to visibly render Chrome on ancient hardware held together by optimism and thermal paste.

Headless and Headed Browsers Are Not Really the Same

People talk about headless Chrome like it is just:

“Chrome without the window.”

That is a comforting lie.

Headless and headed runs differ in:

rendering behavior
GPU paths
timing
compositor behavior
resource usage
sandboxing
viewport defaults

On modern hardware, those differences are annoying.

On old hardware, those differences become a horror genre.

This laptop was running:

a spinning HDD
integrated Radeon R6 graphics
limited RAM
multiple worker processes
Playwright automation

That is exactly the kind of setup where browser rendering starts acting cursed under load.

Linux Makes Browser Automation More Honest

Linux is great because it exposes every hidden assumption your workflow was making.

A browser launched manually from your terminal is not living the same life as:

a headless browser
a system service
a scheduled worker
an unattended automation process

Once I started debugging seriously, I ended up deep in the usual Playwright rabbit hole:

screenshots
tracing
Chromium launch flags
disabling GPU paths
sandbox weirdness
comparing headless vs headed runs
logging everything to Telegram because the local logs were not helpful enough

Some of the flags that helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});

And yes:

npx playwright install-deps

ended up mattering more than I wanted it to.

The Machine Had Vibes

Every self-hosted setup eventually develops a personality.

This one had raccoon energy.

It worked just well enough to encourage confidence right before doing something deeply suspicious.

Firefox? Fine.

Chromium?
Flickering like a cursed artifact from a forgotten Best Buy clearance aisle.

At some point I stopped treating the server like infrastructure and started treating it like a slightly unstable coworker that needed supervision and good logging.

What Actually Improved Reliability

The biggest improvement was honestly:

moving more automation to headless mode
improving logging
adding Telegram notifications
testing under actual production conditions instead of “works while I’m watching it”

That last one matters.

Because “works on my machine” means almost nothing in browser automation when:

the hardware changes
the rendering path changes
the browser mode changes
the workload changes

Browser automation is part application logic and part environmental superstition.

Old hardware amplifies that reality fast.

Lessons Learned

A few things I would absolutely do again:

keep a visible debug mode available
capture screenshots aggressively
log browser launch args
test under the exact conditions production uses
assume old hardware will surface weird rendering bugs earlier

And a few things I learned the hard way:

headed success does not prove headless reliability
Chromium on aging Linux hardware gets weird fast
rebooting is not a debugging strategy
self-hosted automation needs observability way more than optimism

I still like the setup.

Repurposing old hardware into useful infrastructure is genuinely fun.

But browser automation was the thing that forced honesty into the system.

The stack looked stable right up until Chromium had to behave unattended on a 10-year-old Linux laptop with a mechanical hard drive and trust issues.

That’s when the project stopped being a fun experiment and started becoming engineering.

The Bug Only Existed When Nobody Was Watching

There is a special kind of insult that only browser automation can deliver.

You build a Playwright workflow.
You test it manually.
You watch the browser open, click, type, submit, navigate, succeed.

Everything looks solid.

Then you run the exact same flow in production, headless, unattended, on the actual worker machine, and it falls apart like it has never seen a DOM before.

That was the bug.

It only existed when nobody was watching.

And yes, that is an incredibly annoying genre of engineering problem.

The Setup

This lived inside a self-hosted content automation stack running on an old HP laptop I repurposed into a Linux worker box for PostPunk.

The stack was basically:

Linux
Playwright posting workers
browser automation for publishing flows
scheduled background jobs
queue-driven content automation

The machine itself was already operating mostly on vibes.

It had:

6 GB RAM
a mechanical hard drive
integrated Radeon graphics
the general aura of a haunted library computer

The kind of laptop where opening Chrome was basically rolling percentile dice against the gods of thermal management.

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to need emotional support.

Naturally, I decided this was suitable production infrastructure.

Because apparently I enjoy problems with texture.

The First Real Sign Something Was Wrong

At first I thought the automation itself was flaky.

Maybe a selector issue.
Maybe timing.
Maybe Playwright weirdness.

Then one night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
Everything briefly distorted.
Linux made that horrible little ringing system noise like the machine was actively negotiating with death.

I stopped touching the mouse for a few seconds and eventually the system recovered.

Firefox mostly behaved normally.

Chrome behaved like the laptop was trying to reject it biologically.

That was the moment I realized this was no longer just an automation problem.

The Lie: “It Works Fine”

While visually testing the automation, everything looked perfect.

Headed Chromium launched.
The page loaded.
Selectors resolved.
Buttons clicked.
Posts published.

Pinterest worked.
Facebook worked.
Dev.to worked.

If you watched the browser run manually, you would absolutely think:

“Cool. This is production-ready.”

That was the trap.

Because the moment I switched the same workflows into unattended headless production mode, things became cursed.

Suddenly:

selectors timed out
pages rendered differently
interactions fired but did not land
uploads silently failed
waits became inconsistent
browser state got flaky
random inputs were skipped entirely
jobs hung forever for no obvious reason

The automation would sometimes just stop mid-flow like Chromium had emotionally checked out.

Headed and Headless Chromium Are Not the Same Thing

People describe headless Chrome like it is just:

“Chrome without the window.”

That is a comforting lie for people who have not suffered enough yet.

Headed and headless Chromium differ in ways that matter:

rendering paths
GPU behavior
compositor timing
focus handling
viewport defaults
performance under load
environmental dependencies

On a modern machine, those differences are annoying.

On old Linux hardware, they become plot-relevant.

In headed mode, the visible browser was accidentally helping me.

Rendering slowed things down just enough that:

animations finished
panels stabilized
listeners attached properly
React stopped rearranging the DOM
uploads completed before clicks fired

Then headless mode removed all that accidental timing padding.

Suddenly the automation was operating at full machine speed against an unstable environment.

That is where reality started.

The Machine Had Chrome-Specific Hatred

The weirdest part is that Firefox mostly behaved fine.

Chrome specifically was the problem child.

Even opening normal Chrome windows on this machine felt risky.

There was basically a 50/50 chance:

things would work normally
the UI would partially freeze
rendering would glitch
the system would briefly pixelate
the browser would become unstable under load

I still do not fully understand why.

Maybe Chromium was hitting GPU paths the laptop hated.
Maybe Linux and Chrome were fighting somewhere deep in the graphics stack.
Maybe the machine itself was simply old and tired.

I genuinely do not know.

At some point debugging old Linux hardware stops being science and becomes folklore.

Timing Bugs Are Worse in Automation

One of the hardest lessons with browser automation is this:

Watching something work manually proves almost nothing.

Manual observation accidentally hides instability.

Humans naturally slow workflows down.
Visible rendering introduces delays.
The environment stabilizes itself while you are watching.

Production workers do not care about your vibes.

Headless Playwright runs at machine speed.

So this:

await page.click('[data-testid="publish-button"]');

suddenly becomes dangerous because the UI might:

exist visually but not functionally
still be animating
still be hydrating
still be attaching listeners
still be processing uploads

The bug was not random.

The bug was exposing assumptions I did not realize I had made.

Linux Browser Automation Is Its Own Genre of Suffering

Linux browser automation always includes at least one phase of:

“Which dependency is ruining my life this time?”

Eventually I ended up deep in the usual Playwright rabbit hole:

screenshots
tracing
Chromium launch flags
sandbox weirdness
GPU disabling
headless comparisons
HTML snapshots
Telegram alerts
aggressive logging

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering way more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely cared about my Telegram notifications because I could physically watch the automation run on the screen.

Once everything moved headless, the notifications suddenly became the only proof the system was still alive.

At some points, my entire monitoring setup was basically:

Telegram alerts
log files
listening for the laptop fan spinning up

If I heard the fan kick on, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin waiting to see whether Chromium would survive the night.

The Most Linux Thing I Did

At one point I started deleting Chrome-related Linux components trying to “clean up” the environment.

I removed things I absolutely should not have removed.

X11 desktop pieces.
Chrome shell integrations.
Random Chromium-related packages I barely understood.

Eventually I broke the setup badly enough that I had to reinstall parts of it.

And somehow?

That actually improved stability afterward.

Which is the most Linux sentence I have written in a while.

What Actually Helped

The final “fix” was not one fix.

It was a pile of smaller operational improvements:

moving workers fully headless
improving logging
relying on Telegram notifications
adding screenshots on failure
testing under actual production conditions
waiting on UI state instead of luck
reducing rendering overhead
reinstalling the Chrome components I accidentally destroyed

The biggest shift was psychological.

I stopped treating:

“it worked once”

as evidence of reliability.

Because reliability is not:

“worked on my machine”
“worked while visible”
“worked during testing”
“worked three times in a row”

Reliability means:

unattended
repeatable
observable
stable under load
stable overnight
stable when nobody is babysitting Chromium personally

That is an entirely different standard.

Final Thoughts

I still like this setup.

Repurposing old hardware into useful infrastructure is genuinely fun.

There is something satisfying about turning a neglected old laptop into a working automation server instead of throwing it away.

But browser automation forces honesty into your system very quickly.

The stack looked stable right up until Chromium had to behave unattended on a 10-year-old Linux laptop with trust issues and a mechanical hard drive.

Eventually the workers became stable enough that I stopped staring directly at them while jobs ran.

Honestly, that was probably the real milestone.

Not:

“The script finally worked.”

But:

“I no longer felt emotionally required to supervise Chromium personally.”

Running Playwright + Headless Chrome on Old Hardware Is Less “Automation” and More “Systems Archaeology”

There is a very specific type of developer optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah, this should absolutely run production browser automation.”

This machine had:

6 GB RAM
a mechanical hard drive
integrated Radeon graphics
Linux
Chrome
trust issues

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to require spiritual intervention.

Naturally, I turned it into a self-hosted automation server running Playwright workers for PostPunk.

Because apparently I enjoy creating problems recreationally.

The Basic Fantasy

The fantasy sounds reasonable enough.

Take an old laptop.
Install Linux.
Run some worker processes.
Use Playwright for browser automation.
Queue content posts automatically.
Stop manually posting to platforms one miserable click at a time.

Honestly?

That last part mattered the most.

I’m stubborn, cheap, and deeply allergic to manually posting content platform-by-platform forever.

Which is basically the entire psychological profile required to build self-hosted automation systems.

At some point this stopped being:

“a fun Linux experiment”

and became:

“the engine for how I actually want to work.”

That meant the machine suddenly mattered.

And unfortunately, so did Chrome.

Everything Was Fine Until Chromium Entered The Story

The Linux side was mostly solid.

Workers behaved.
Scheduling behaved.
Queue processing behaved.
Notifications behaved.

Then Chromium showed up and started acting like the laptop was trying to process emotional trauma in real time.

At first the failures looked random:

selectors timing out
uploads silently failing
clicks not landing
pages freezing
workers hanging forever
random skipped inputs
inconsistent rendering

The worst part?

The automation usually worked while I was watching it.

Pinterest posted correctly.
Facebook posted correctly.
Dev.to posted correctly.

So naturally I thought:

“Cool. Stable.”

That was a lie.

The Moment I Realized This Wasn’t Just A Script Problem

One night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
The machine made that horrible little Linux system ringing noise like everything inside the laptop had briefly entered a panic attack.

I stopped moving the mouse.
Waited a few seconds.
The machine recovered.

Firefox mostly behaved normally.

Chrome behaved like the unstable roommate Linux was too polite to evict.

That was the moment I realized:
this was no longer just a Playwright problem.

Something deeper was happening.

Old Hardware Changes Failure Modes

A lot of browser automation advice accidentally assumes healthy hardware.

People say:

“Playwright works great.”

And I believe them.

But there is usually an invisible footnote:

“on hardware that is not actively fighting for its life.”

Old hardware changes the nature of failures.

On modern systems:

bad waits
selectors
auth issues
flaky timing

On old systems:

GPU weirdness
rendering instability
browser freezes
memory pressure
disk latency
thermal throttling
random Chrome existential crises

At some point the machine stopped feeling “slow” and started feeling medically concerning.

The fans would suddenly kick on like the laptop had just seen a tax audit.

Opening Chrome on this thing felt less like launching software and more like asking an elderly wizard for one final favor.

Headless Chrome Is Not Lightweight. It Is Just Invisible

People hear “headless browser” and imagine some tiny efficient automation process.

No.

Headless Chromium still wants:

RAM
CPU
rendering resources
shared memory
dependencies
graphics support
enough system stability to not implode under load

And when resources get tight, the browser does not always fail cleanly.

Sometimes it just becomes weird.

Which is worse.

The browser would get 95% through a workflow and then suddenly remember it was running on archaeology.

That’s the dangerous middle ground:
not broken enough to diagnose instantly,
not stable enough to trust.

Headed And Headless Chromium Are Basically Different Species

This ended up being the biggest lesson.

The workflows behaved differently depending on whether I could physically see the browser.

That sounds fake until you experience it yourself.

In headed mode:

rendering slowed things down
animations had time to finish
uploads stabilized
UI transitions completed
the environment accidentally synchronized itself

Headless mode removed all that padding.

Suddenly the automation was running at full machine speed against a browser environment held together with aging hardware and optimism.

That’s when the race conditions showed up.

This:

await page.click('[data-testid="publish-button"]');

turns out to mean absolutely nothing if:

React is still hydrating
uploads are incomplete
event listeners are not attached yet
the UI exists visually but not functionally

Watching successful automation manually proves almost nothing.

Production workers do not care about your vibes.

Linux Browser Automation Slowly Becomes Folklore

At some point my debugging strategy stopped being engineering and became ritualistic behavior.

I started:

reinstalling packages I barely understood
randomly deleting Chrome-related components
tweaking launch flags endlessly
waiting before clicks
comparing screenshots
listening for fan noise
praying to God a little bit

At one point I removed enough Chrome/X11-related stuff that the machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which is the most Linux outcome possible.

GPU Weirdness Is Real

Firefox mostly behaved fine on this machine.

Chrome specifically was chaos.

Even normal Chrome windows were basically a 50/50 gamble:

maybe fine
maybe flickering
maybe partially freezing
maybe pixelating
maybe emotionally collapsing halfway through rendering

I still do not fully understand why.

Maybe Chromium was hitting rendering paths the machine hated.
Maybe Linux and Chrome were fighting deep in the graphics stack.
Maybe the laptop itself was just old and tired.

At some point debugging old Linux hardware stops being science and becomes folklore.

What Actually Helped

Not one thing.
Several things.

Moving more flows to headless mode helped because visible Chrome rendering was apparently making the machine more unstable.

Proper waits helped a lot.

I learned very quickly that:

waits matter more than confidence
“loaded” does not mean “ready”
visible UI does not mean interactable UI

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering far more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely paid attention to my Telegram notifications because I could physically see the automation running.

Once everything moved headless, the notifications became the only reliable proof the workers were alive.

At one point my monitoring stack was basically:

Telegram alerts
screenshots
log files
listening for fan noise

If I heard the fan suddenly spin up, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin trying to convince Chromium not to explode overnight.

Reliability Is A Much Higher Standard Than “It Worked Once”

This was the real lesson.

A successful run does not prove reliability.

It proves:

one run succeeded under one set of conditions.

That’s all.

Reliable automation means:

unattended
repeatable
observable
stable under load
stable overnight
stable when nobody is staring directly at Chromium like a nervous zookeeper

That is a completely different standard.

Eventually the workers became stable enough that I stopped compulsively checking them every few minutes.

Honestly?

That was probably the real milestone.

Not:

“the scripts worked.”

But:

“I no longer felt emotionally required to supervise Chrome personally.”

Chrome Was The Unstable Roommate In My Linux Automation Stack

I honestly thought the script was broken at first.

That’s the embarrassing part.

I thought maybe:

my selectors were wrong
Playwright was clicking too early
Pinterest changed something again
Facebook loaded weird
Dev.to timing shifted

Normal automation stuff.

Then Chrome itself started pixelating.

And that’s when I got the very specific gut-drop feeling of:

“Oh no. This is a REAL problem.”

The Machine

This entire setup lived on an old HP laptop I turned into a Linux worker box for PostPunk.

Which sounds fun and experimental until the machine becomes responsible for your actual workflow.

The specs were basically:

6 GB RAM
mechanical hard drive
integrated Radeon graphics
Chrome
suffering

The kind of machine where opening Chromium felt less like launching software and more like asking an elderly wizard for one final favor.

And honestly?

I loved the setup anyway.

Because I like building things.

That’s what I do.

Why I Even Built This

I hate manually posting content one platform at a time.

Absolutely hate it.

If I write something, I want it to:

queue
schedule
publish
move on with life

I do not want to spend every morning manually reposting things across half the internet like a social media intern trapped in a Groundhog Day loop.

So I built PostPunk.

Not because I wanted “startup founder energy.”

Because I literally needed infrastructure.

I can’t afford a marketing team.

So if I want my work to consistently exist online, I have to build the system myself.

That’s the reality.

The writing.
The scheduling.
The posting.
The visibility.

All of it depended on this weird old Linux laptop not emotionally collapsing during browser automation.

Everything Worked While I Was Watching It

That was the trap.

When I manually tested the workers:

Pinterest posted
Facebook posted
Dev.to posted
selectors worked
uploads worked
clicks landed

Everything looked stable.

Then I would let the workers run unattended and suddenly:

uploads stalled
inputs got skipped
pages froze
rendering glitched
jobs hung forever
Chrome started acting possessed

The worst bugs were the inconsistent ones.

Those are the bugs that make you question your sanity because they fail just rarely enough to feel random.

The Fan Noise Became A Warning Sign

Eventually I started recognizing failure patterns from the machine itself.

Not logs.
Not stack traces.

The actual hardware.

If Chrome started flickering during login, whatever workflow I was running was probably doomed.

Sometimes the screen would:

partially freeze
pixelate
glitch out briefly
make that horrible little Linux system ringing noise

Then recover if I stopped touching anything for a few seconds.

At some point my operational monitoring strategy became:

“if the fan suddenly screams at 2 AM, something is probably wrong.”

Which is not exactly enterprise-grade observability engineering.

Chrome Specifically Hated This Machine

Firefox mostly behaved fine.

Chrome was chaos.

Even opening normal Chrome windows was basically gambling:

maybe fine
maybe frozen
maybe flickering
maybe halfway into a rendering crisis

I still do not fully understand why.

Maybe GPU weirdness.
Maybe Linux graphics stack nonsense.
Maybe Chromium was hitting rendering paths the laptop hated.

I genuinely don’t know.

At some point Linux troubleshooting stops being engineering and becomes folklore.

Headless And Headed Browsers Are Different In Ways That Matter

This was the biggest lesson.

The workflows behaved differently depending on whether I could physically SEE the browser.

That sounds fake until you experience it.

Headed mode accidentally slowed everything down enough to stabilize parts of the UI.

Headless mode removed that safety padding.

Suddenly Playwright was operating at full speed against:

flaky rendering
unstable browser state
old hardware
race conditions
half-finished uploads
incomplete UI hydration

This innocent-looking line:

await page.click('[data-testid="publish-button"]');

turned out to mean:

“I hope the UI actually exists yet.”

Which are two very different things.

The Most Linux Thing I Did

At one point I started randomly deleting Chrome-related Linux components trying to “clean up” the environment.

I removed things I absolutely did not understand.

X11 stuff.
Chrome shell integrations.
Random Chromium packages.

Eventually the entire machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which feels spiritually correct for Linux somehow.

What Actually Helped

The fixes were less glamorous than I wanted.

Mostly:

proper waits
more logging
screenshots
Telegram alerts
headless mode
disabling GPU paths
reinstalling dependencies
accepting that “works once” means nothing

These flags helped a lot:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});

And yes:

npx playwright install-deps

actually mattered.

Unfortunately.

This Was Never Really About Chrome

The reason I kept fixing it instead of quitting was simple:

I wanted it to work.

Because this machine became the engine behind everything else.

The Pinterest traffic.
The writing.
The visibility.
The projects.

At one point I dropped from around 5k Pinterest followers to around 4.5k during all the automation hiccups.

That stuff matters when you are trying to build things online consistently by yourself.

I’m a builder.
An inventor.
A writer.

And if I want people to actually SEE the things I make, then I also have to become:

infrastructure engineer
automation goblin
sysadmin
marketing department
overnight Chrome therapist

That’s just the reality now.

Final Thoughts

I think the funniest part is that the system eventually became stable enough that I stopped obsessively checking it every few minutes.

Honestly, that was probably the real milestone.

Not:

“the automation worked.”

But:

“I no longer felt emotionally responsible for supervising Chromium personally.”

And that’s probably the closest thing browser automation ever gives you to peace.

I Started Automating Content and Discovered I Had No Idea What People Wanted

Ashley B — Tue, 07 Jul 2026 03:41:04 +0000

I Started Automating Content and Discovered I Had No Idea What People Wanted

I originally thought I was building a scheduler.

I wasn't.

I just didn't know it yet.

Like a lot of developers, I have more ideas than time.

Coloring books.

Digital products.

Experiments.

Tools.

Projects that seemed brilliant at 2 AM and questionable by lunchtime.

The problem wasn't coming up with ideas.

The problem was getting anyone to see them.

So I started building what eventually became PostPunk.

At first, the goal was simple:

Create content.

Schedule content.

Post content.

Hopefully sell something.

Easy, right?

Yeah. Not even close.

I Thought Posting Was the Problem

My assumption was that marketing failed because I wasn't posting enough.

That seemed logical.

If nobody sees your stuff, post more.

If posting takes too much time, automate it.

Problem solved.

So I started building tools to help with scheduling, queues, publishing, and content management.

The engineering part made sense.

The marketing part did not.

Then I Learned Every Platform Wants Something Different

Pinterest isn't Facebook.

Facebook isn't LinkedIn.

LinkedIn isn't Dev.to.

Every platform has its own weird personality.

Pinterest wants visuals.

LinkedIn wants insights.

Dev.to wants stories.

And the same piece of content can perform completely differently depending on where it lands.

I thought I was building a posting engine.

Instead, I accidentally started studying platform behavior.

Then audience behavior.

Then content behavior.

Then discoverability.

The scheduler became one small piece of a much larger problem.

The Audience Kept Proving Me Wrong

This was probably the most humbling lesson.

I thought I knew what people would like.

I was wrong.

Repeatedly.

I'd spend time on something I thought was clever.

Nothing.

Then I'd post something weird and watch it take off.

Which brings us to the goblins.

The Goblin Chaos

One of my strangest content experiments involved chaotic goblin-themed humor.

If I'm being honest, I wasn't sure anyone would care.

It was weird.

A little niche.

Definitely not something I expected to outperform more practical ideas.

Then people started clicking.

Saving.

Sharing.

Engaging.

My first reaction wasn't:

"I have successfully validated a market opportunity."

My first reaction was:

"Well shit... that was unexpected."

The goblin content wasn't just getting attention.

People actually liked it.

That surprised me because it felt so specific and strange.

But it also taught me something important.

The audience doesn't care what I think should work.

The audience decides what works.

The Scheduler Was Never The Product

Looking back, the scheduler wasn't the interesting part.

The interesting part was learning.

Learning what people click.

Learning what people ignore.

Learning what gets shared.

Learning how often my assumptions are wrong.

I started this project because I wanted to automate content distribution.

What I ended up building was a feedback loop.

A system that constantly reminds me:

You are not your audience.

And that's probably a good thing.

The Unexpected Lesson

The biggest surprise wasn't that automation helped.

It did.

The biggest surprise was discovering how bad I am at predicting winners.

Some of my favorite ideas went nowhere.

Some of the weirdest ideas found an audience.

The goblins taught me that.

The analytics taught me that.

The clicks taught me that.

And honestly, that's probably the most valuable thing the entire project has given me.

Not automation.

Not scheduling.

Not publishing.

Humility.

Because every time I think I've figured out what people want, the internet finds a new way to prove me wrong.

And sometimes, thankfully, it does it with goblins.

P.S. If You're Still Reading This...

And you're wondering:

"What the hell is goblin chaos?"

Fair question.

One of the biggest surprises from this whole experiment was discovering that some of my weirdest ideas resonated with people far more than the ones I thought would succeed.

What started as a strange creative experiment somehow turned into coloring books, digital products, memes, and an audience that seems to enjoy chaotic woodland nonsense as much as I do.

If you're curious about the goblins that helped teach me this lesson:

👉 Goblin Core Coloring Affirmations on Gumroad

Turns out the internet wanted more goblins.

I was as surprised as anyone.

The AI Prompts I Wish I Had Right After Graduation

Ashley B — Mon, 22 Jun 2026 15:01:45 +0000

The AI Prompts I Wish I Had Right After Graduation

Graduation advice is weird.

Half the internet tells you to follow your passion.

The other half tells you to optimize your LinkedIn headline like you're trying to summon a recruiter through an ancient ritual.

Meanwhile, you're staring at a blank page thinking:

"Cool. I have a degree. Now what?"

Confession:

I don't even remember every prompt in the AI-Powered Grad Launch Kit.

I made it a while ago.

What I do remember are the problems.

The blank-page panic.

The feeling that everyone else somehow knew what they were doing.

The endless cycle of:

"Should I apply for this?"

"Am I even qualified?"

"How do I explain my experience?"

"What jobs should I even be searching for?"

Years later, while job hunting again and trying to figure out my own next moves, I found myself rebuilding the same kinds of prompts over and over.

Not because AI had all the answers.

Because sometimes you just need help figuring out the next question to ask.

These are the prompts I wish I'd had when I first graduated.

1. Turn My Experience Into Resume Bullets

Instead of saying:

"Help me write my resume."

Try this:

Act as a hiring manager for entry-level [ROLE]. Turn my experience below into achievement-focused resume bullets using action verbs and measurable outcomes when possible.

Paste your internships.

Paste your class projects.

Paste your volunteer work.

Paste the weird part-time job that somehow taught you conflict resolution and time management.

You probably have more experience than you think.

2. Help Me Figure Out What Jobs I Actually Qualify For

Nobody tells you this after graduation:

Job titles are basically made up.

Try this:

Based on my degree, skills, and interests, suggest 15 job titles I may qualify for that I might not have considered. Explain what each role actually does.

Sometimes the biggest obstacle isn't a lack of opportunity.

It's not knowing what to search for.

3. Practice Interviews Without Judgement

Interviewing is awkward.

Being interviewed by AI is also awkward.

But at least AI won't remember that one answer you absolutely butchered.

Try:

Pretend you're interviewing me for an entry-level [ROLE]. Ask me one question at a time, critique my answer, and help me improve.

It's free.

It's available at 11 PM.

And it won't judge you for needing to try the same answer three times.

4. Rewrite Networking Messages So They Sound Human

Networking advice often sounds like it was written by someone who has never had a conversation before.

Instead of staring at a blinking cursor, try:

Help me write a networking message that sounds genuine, curious, and professional without sounding like I'm begging for a job.

Because nobody wants to send:

Dear Sir or Madam,

Please validate my existence.

5. Build a Learning Plan Instead of Doomscrolling

One of the easiest ways to avoid taking action is convincing yourself you need to learn absolutely everything first.

Try:

I want to become a better [ROLE]. Build me a 30-day learning plan using mostly free resources. Assume I have one hour per day.

Small progress beats panic.

Every single time.

What I Actually Made

At some point, I realized I wasn't just collecting prompts.

I was trying to build the thing I wish someone had handed me at 18.

Not another motivational poster.

Not another "follow your dreams" speech.

Something practical.

Something that helped answer questions like:

What jobs should I apply for?
How do I figure out what I actually want?
How do I organize all these ideas?
How do I stop panicking long enough to take the next step?

So I turned it into a weird little launch kit.

It eventually became the AI-Powered Grad Launch Kit.

Inside, there's:

100 AI prompts
A CSV that works with Excel or Google Sheets
A Notion command center to organize everything
Prompt tracking and journaling tools
A "Hey Grad" letter for the person trying to figure it all out
Life lessons I wish I'd known sooner
A simple guide explaining how to use it without feeling overwhelmed

Basically:

The handbook I never got.

If You Want the Rest

Apparently, I kept rebuilding these kinds of prompts often enough that Past Me eventually decided to package them up.

If these five prompts helped, the full AI-Powered Grad Launch Kit includes:

100 prompts for self-discovery, career planning, and personal growth
Excel and Google Sheets compatibility
A Notion command center
Journaling tools
A welcome letter for grads
Life lessons I wish I'd heard earlier
Resources designed to help you move forward without pretending you have your entire life figured out

You can check it out here:

👉 https://fleurdevie.gumroad.com/l/ai-powered-grad

And if you're graduating, recently graduated, changing careers, re-entering the workforce, or simply trying to get unstuck:

You're not behind.

Most of us are just making the next best decision we can with the information we have and hoping it works out.

You don't need to have your whole life figured out.

You just need to know what to do next.

What Recruiters Can't See On My GitHub

Ashley B — Tue, 16 Jun 2026 18:34:02 +0000

What Recruiters Can't See On My GitHub

If you spend about 30 seconds looking at my GitHub profile, you might think I'm all over the place.

React.

Python.

Healthcare.

AI.

Scrapers.

Automation.

Marketing tools.

Job bots.

Honestly, that's something I've worried about.

I have over 100 repositories. Recruiters can see most of them, but not all of them. Some are private because they're client work. Some are private because they're unfinished. Some are private because they contain ideas I've spent years developing and I'm not quite ready to throw the blueprints onto the internet.

From the outside, it can look random.

But recently I realized something.

All of those projects are solving the same problem.

I hate repetitive work.

My GitHub is here: https://github.com/ashb4

The Job Application That Broke Me

I've applied to thousands of jobs over the years.

Thousands.

And one thing has always driven me absolutely insane.

You upload your resume.

Then the company immediately asks you to type your entire resume into fifteen different boxes.

Your work history.

Your education.

Your skills.

Everything.

The computer already has the information.

The resume is right there.

Yet somehow I'm sitting on page seven of an application retyping information that already exists.

It feels inefficient.

It feels stupid.

And most of all, it feels like a waste of time.

Eventually I got annoyed enough to start building tools to help.

Then I Noticed a Pattern

At first I thought I was building unrelated projects.

A job application helper.

A content scheduler.

A healthcare platform.

An AI framework.

A browser automation system.

But when I stepped back, I noticed the same motivation behind almost all of them.

Every project started with some version of:

"There has to be a better way to do this."

Take PostPunk.

Most people see a social media scheduler.

I see hours of repetitive posting that I never want to do again.

I like creating content.

I do not like manually posting the same content everywhere.

So I built a system where I can create when I'm feeling creative, queue everything up, and let the system handle the repetitive parts later.

Create once.

Reuse many times.

That's a pattern you'll see all over my GitHub.

The Projects Aren't Random

One recruiter might see:

PostPunk
Orchestrator
BoxerLogic
Healthcare applications
Scrapers
Automation tools

and think:

"These don't seem related."

I'd argue they're incredibly related.

They're all attempts to reduce repetitive human effort.

Different domains.

Same obsession.

Some developers love graphics.

Some love databases.

Some love distributed systems.

I seem to be drawn toward removing friction.

If something feels repetitive enough, eventually I start asking myself whether a computer should be doing it instead.

The AI Question

People sometimes assume that because I use AI, the projects are somehow doing all the work for me.

The reality is less exciting.

AI helps.

But AI is not magic.

I've found that the hardest part isn't generating code.

It's understanding workflows.

Understanding edge cases.

Understanding what people are actually trying to accomplish.

The code is often the easy part.

The thinking is the hard part.

That's true whether you're building a healthcare platform, a job application tool, or an automation system.

What I Hope Recruiters Actually See

I don't expect recruiters to inspect all 100+ repositories.

Nobody has time for that.

But if they do look at my GitHub, I hope they don't see a collection of random technologies.

I hope they see a systems thinker.

Someone who gets annoyed by repetitive work.

Someone who enjoys finding patterns.

Someone who likes building tools that save people time.

Because when I look at my repositories, that's what I see.

Not 100 separate projects.

Just one idea repeated over and over:

If a task is repetitive enough, there's probably a better way to do it.

And sooner or later, I'm probably going to try building it.

What Recruiters Can't See On My GitHub

Ashley B — Mon, 15 Jun 2026 15:00:02 +0000

What Recruiters Can't See On My GitHub

If you spend about 30 seconds looking at my GitHub profile, you might think I'm all over the place.

React.

Python.

Healthcare.

AI.

Scrapers.

Automation.

Marketing tools.

Job bots.

Honestly, that's something I've worried about.

From the outside, it can look random.

But recently I realized something.

All of those projects are solving the same problem.

I hate repetitive work.

My GitHub is here: https://github.com/ashb4

The Job Application That Broke Me

I've applied to thousands of jobs over the years.

Thousands.

And one thing has always driven me absolutely insane.

You upload your resume.

Then the company immediately asks you to type your entire resume into fifteen different boxes.

Your work history.

Your education.

Your skills.

Everything.

The computer already has the information.

The resume is right there.

Yet somehow I'm sitting on page seven of an application retyping information that already exists.

It feels inefficient.

It feels stupid.

And most of all, it feels like a waste of time.

Eventually I got annoyed enough to start building tools to help.

Then I Noticed a Pattern

At first I thought I was building unrelated projects.

A job application helper.

A content scheduler.

A healthcare platform.

An AI framework.

A browser automation system.

But when I stepped back, I noticed the same motivation behind almost all of them.

Every project started with some version of:

"There has to be a better way to do this."

Take PostPunk.

Most people see a social media scheduler.

I see hours of repetitive posting that I never want to do again.

I like creating content.

I do not like manually posting the same content everywhere.

So I built a system where I can create when I'm feeling creative, queue everything up, and let the system handle the repetitive parts later.

Create once.

Reuse many times.

That's a pattern you'll see all over my GitHub.

The Projects Aren't Random

One recruiter might see:

PostPunk
Orchestrator
BoxerLogic
Healthcare applications
Scrapers
Automation tools

and think:

"These don't seem related."

I'd argue they're incredibly related.

They're all attempts to reduce repetitive human effort.

Different domains.

Same obsession.

Some developers love graphics.

Some love databases.

Some love distributed systems.

I seem to be drawn toward removing friction.

If something feels repetitive enough, eventually I start asking myself whether a computer should be doing it instead.

The AI Question

People sometimes assume that because I use AI, the projects are somehow doing all the work for me.

The reality is less exciting.

AI helps.

But AI is not magic.

I've found that the hardest part isn't generating code.

It's understanding workflows.

Understanding edge cases.

Understanding what people are actually trying to accomplish.

The code is often the easy part.

The thinking is the hard part.

That's true whether you're building a healthcare platform, a job application tool, or an automation system.

What I Hope Recruiters Actually See

I don't expect recruiters to inspect all 100+ repositories.

Nobody has time for that.

But if they do look at my GitHub, I hope they don't see a collection of random technologies.

I hope they see a systems thinker.

Someone who gets annoyed by repetitive work.

Someone who enjoys finding patterns.

Someone who likes building tools that save people time.

Because when I look at my repositories, that's what I see.

Not 100 separate projects.

Just one idea repeated over and over:

If a task is repetitive enough, there's probably a better way to do it.

And sooner or later, I'm probably going to try building it.

Running Playwright + Headless Chrome on Old Hardware Is Less “Automation” and More “Systems Archaeology”

Ashley B — Mon, 08 Jun 2026 15:00:04 +0000

Running Playwright + Headless Chrome on Old Hardware Is Less “Automation” and More “Systems Archaeology”

There is a very specific type of developer optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah, this should absolutely run production browser automation.”

This machine had:

6 GB RAM
a mechanical hard drive
integrated Radeon graphics
Linux
Chrome
trust issues

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to require spiritual intervention.

Naturally, I turned it into a self-hosted automation server running Playwright workers for PostPunk.

Because apparently I enjoy creating problems recreationally.

The Basic Fantasy

The fantasy sounds reasonable enough.

Honestly?

That last part mattered the most.

I’m stubborn, cheap, and deeply allergic to manually posting content platform-by-platform forever.

Which is basically the entire psychological profile required to build self-hosted automation systems.

At some point this stopped being:

“a fun Linux experiment”

and became:

“the engine for how I actually want to work.”

That meant the machine suddenly mattered.

And unfortunately, so did Chrome.

Everything Was Fine Until Chromium Entered The Story

The Linux side was mostly solid.

Workers behaved.
Scheduling behaved.
Queue processing behaved.
Notifications behaved.

Then Chromium showed up and started acting like the laptop was trying to process emotional trauma in real time.

At first the failures looked random:

selectors timing out
uploads silently failing
clicks not landing
pages freezing
workers hanging forever
random skipped inputs
inconsistent rendering

The worst part?

The automation usually worked while I was watching it.

Pinterest posted correctly.
Facebook posted correctly.
Dev.to posted correctly.

So naturally I thought:

“Cool. Stable.”

That was a lie.

The Moment I Realized This Wasn’t Just A Script Problem

One night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
The machine made that horrible little Linux system ringing noise like everything inside the laptop had briefly entered a panic attack.

I stopped moving the mouse.
Waited a few seconds.
The machine recovered.

Firefox mostly behaved normally.

Chrome behaved like the unstable roommate Linux was too polite to evict.

That was the moment I realized:
this was no longer just a Playwright problem.

Something deeper was happening.

Old Hardware Changes Failure Modes

A lot of browser automation advice accidentally assumes healthy hardware.

People say:

“Playwright works great.”

And I believe them.

But there is usually an invisible footnote:

“on hardware that is not actively fighting for its life.”

Old hardware changes the nature of failures.

On modern systems:

bad waits
selectors
auth issues
flaky timing

On old systems:

GPU weirdness
rendering instability
browser freezes
memory pressure
disk latency
thermal throttling
random Chrome existential crises

At some point the machine stopped feeling “slow” and started feeling medically concerning.

The fans would suddenly kick on like the laptop had just seen a tax audit.

Opening Chrome on this thing felt less like launching software and more like asking an elderly wizard for one final favor.

Headless Chrome Is Not Lightweight. It Is Just Invisible

People hear “headless browser” and imagine some tiny efficient automation process.

No.

Headless Chromium still wants:

RAM
CPU
rendering resources
shared memory
dependencies
graphics support
enough system stability to not implode under load

And when resources get tight, the browser does not always fail cleanly.

Sometimes it just becomes weird.

Which is worse.

The browser would get 95% through a workflow and then suddenly remember it was running on archaeology.

That’s the dangerous middle ground:
not broken enough to diagnose instantly,
not stable enough to trust.

Headed And Headless Chromium Are Basically Different Species

This ended up being the biggest lesson.

The workflows behaved differently depending on whether I could physically see the browser.

That sounds fake until you experience it yourself.

In headed mode:

rendering slowed things down
animations had time to finish
uploads stabilized
UI transitions completed
the environment accidentally synchronized itself

Headless mode removed all that padding.

Suddenly the automation was running at full machine speed against a browser environment held together with aging hardware and optimism.

That’s when the race conditions showed up.

This:

await page.click('[data-testid="publish-button"]');

turns out to mean absolutely nothing if:

React is still hydrating
uploads are incomplete
event listeners are not attached yet
the UI exists visually but not functionally

Watching successful automation manually proves almost nothing.

Production workers do not care about your vibes.

Linux Browser Automation Slowly Becomes Folklore

At some point my debugging strategy stopped being engineering and became ritualistic behavior.

I started:

reinstalling packages I barely understood
randomly deleting Chrome-related components
tweaking launch flags endlessly
waiting before clicks
comparing screenshots
listening for fan noise
praying to God a little bit

At one point I removed enough Chrome/X11-related stuff that the machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which is the most Linux outcome possible.

GPU Weirdness Is Real

Firefox mostly behaved fine on this machine.

Chrome specifically was chaos.

Even normal Chrome windows were basically a 50/50 gamble:

maybe fine
maybe flickering
maybe partially freezing
maybe pixelating
maybe emotionally collapsing halfway through rendering

I still do not fully understand why.

Maybe Chromium was hitting rendering paths the machine hated.
Maybe Linux and Chrome were fighting deep in the graphics stack.
Maybe the laptop itself was just old and tired.

At some point debugging old Linux hardware stops being science and becomes folklore.

What Actually Helped

Not one thing.
Several things.

Moving more flows to headless mode helped because visible Chrome rendering was apparently making the machine more unstable.

Proper waits helped a lot.

I learned very quickly that:

waits matter more than confidence
“loaded” does not mean “ready”
visible UI does not mean interactable UI

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering far more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely paid attention to my Telegram notifications because I could physically see the automation running.

Once everything moved headless, the notifications became the only reliable proof the workers were alive.

At one point my monitoring stack was basically:

Telegram alerts
screenshots
log files
listening for fan noise

If I heard the fan suddenly spin up, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin trying to convince Chromium not to explode overnight.

Reliability Is A Much Higher Standard Than “It Worked Once”

This was the real lesson.

A successful run does not prove reliability.

It proves:

one run succeeded under one set of conditions.

That’s all.

Reliable automation means:

unattended
repeatable
observable
stable under load
stable overnight
stable when nobody is staring directly at Chromium like a nervous zookeeper

That is a completely different standard.

Eventually the workers became stable enough that I stopped compulsively checking them every few minutes.

Honestly?

That was probably the real milestone.

Not:

“the scripts worked.”

But:

“I no longer felt emotionally required to supervise Chrome personally.”

The Creator Block Debugger: Still Fixing It But It Works

Ashley B — Tue, 21 Apr 2026 18:40:55 +0000

Creator block is usually not a talent problem. It is a starting problem.

I built a system that works when motivation is zero. Here is how:

Have a queue of 30 ready-to-post pieces
Use prompts instead of waiting for ideas
Batch create when feeling creative
Schedule and forget

The goal is to never face a blank page.

How I Turn One Idea Into 10 Posts Without AI Slop

Ashley B — Tue, 21 Apr 2026 18:40:12 +0000

The Problem

I used to treat ideas like single-use objects.

One idea -> one post -> done.

Then I'd sit there the next day like:

"cool... now what?"

Repeat that enough times and you end up doing one of two things:

overthinking everything
or not posting at all

Neither one scales.

Where My Ideas Actually Come From

Nothing fancy.

random thoughts
things I've built
frustrations
"this sucks, there should be a better way"

That last one is the goldmine.

If I feel friction, odds are someone else does too.

What Changed

I stopped treating ideas like finished products.

Now I treat them like raw input.

And instead of asking:

"is this a good post?"

I ask:

"how many angles can I squeeze out of this?"

The Actual System (Not Pretty, But It Works)

Step 1: Rant first

I don't start structured.

I just dump everything:

what's annoying me
what I think is broken
what I wish existed

No filter. No polish.

Step 2: Extract angles

From one rant, I usually get:

a blunt take
a practical tip
a story
a system
a question

Same idea. Different surfaces.

Step 3: Map to platforms

Each angle becomes a different format:

short punch -> social post
structured idea -> Dev.to
repeatable idea -> Pinterest
casual version -> Facebook

Same core idea, different packaging.

Step 4: Store everything (this is the real unlock)

The biggest change wasn't AI.

It was having a place to dump everything.

I built a simple system (DB + queue) where I can:

drop ideas
expand them later
schedule without thinking

That removed the "what do I post today?" problem entirely.

Where AI Actually Helps (and Where It Doesn't)

I use AI a lot.

Probably too much.

Where it helps:

generating variations
breaking writer's block
speeding up structure

Where it fails hard:

When you try to force voice out of it.

What "AI Slop" Actually Is

AI slop isn't just bad writing.

It's this loop:

you ask -> it gives something generic -> you tweak -> it gets worse -> repeat

You end up with content that:

sounds like everyone else
says nothing new
feels safe and useless

Especially if you want something:

edgy
opinionated
slightly unhinged

AI struggles there.

The Fix

I stopped asking AI to create from scratch.

Now I:

start messy (my input)
use AI to expand, not invent
keep the tone mine

AI is a tool, not the source.

The Real Outcome

This changed two things:

1. Consistency

I don't rely on "feeling like posting" anymore.

I already have:

ideas
drafts
scheduled content

2. Output without burnout

Instead of forcing new ideas daily:

I reuse the same idea multiple times.

Which means:

less pressure
more content
better ideas over time

The Simple Version

If you do nothing else:

stop writing one post per idea
start extracting multiple angles
store everything

That alone will outpace most people.

Final Thought

You don't need more ideas.

You need to stop wasting the ones you already have.

https://fleurdevie.gumroad.com/l/100prompt-storm

What Building a Social Scheduler Taught Me About Reliability

Ashley B — Tue, 31 Mar 2026 21:15:43 +0000

Most automation tools feel impressive right up until you have to trust them.

It is easy to demo a scheduler.

It is much harder to build one that survives real life:

expired tokens
flaky platform APIs
posts that need review
queues that drift out of sync
failures that happen while you are asleep

That gap changed how I think about automation.

I have been building a project called PostPunk, and I thought the hard part would be generating content and wiring platform APIs together. That turned out to be the easy part.

The real work was operational trust.

A useful scheduler needs a few things that demos usually skip:

1. Approval states matter

Not every post should go straight from draft to published.

Some posts are written by you and are ready immediately. Some are AI-assisted and need a second look. If your system does not distinguish that clearly, you end up either babysitting everything or accidentally posting junk.

So I ended up treating post states as part of the core workflow, not just metadata:

draft
approved
posted
failed

That sounds simple, but it changes everything.

2. Failure is not an edge case

In scheduling systems, failure is normal.

A platform token expires.
An API rate-limits you.
A platform changes a field name.
An account is misconfigured.
A browser fallback stops matching the UI.

If the whole system falls apart the moment one target fails, you do not have automation. You have a fragile demo.

So the system needs:

retries
visible failure states
alerts
manual assist when automation is not trustworthy

3. Automatic is not the same as unattended

A lot of posting tools sell the dream of full autopilot. In practice, a better model is often:

automate what is stable
assist where platforms are hostile
keep the queue and schedule as the source of truth

That still saves a huge amount of time, and more importantly, it is honest.

4. Scheduling is really an operations problem

The UI part is not enough.

You also need:

a worker that checks for due posts
logs
retry logic
success and failure alerts
a clear what is due today view

Without those, the schedule is just decorative.

What I learned

The hardest part of automation is not getting software to do something once.

It is getting it to behave predictably enough that you stop worrying about it.

That is the part I care about now.

If you are building internal tools, creator tools, or any kind of scheduler, reliability is the actual feature. Everything else is packaging.

PostPunk is still a project I am actively working on, but building it has made me much less interested in shiny automation promises and much more interested in boring operational trust.

What Building a Social Scheduler Taught Me About Reliability

Ashley B — Mon, 30 Mar 2026 15:01:32 +0000

Most automation tools feel impressive right up until you have to trust them.

It is easy to demo a scheduler.

It is much harder to build one that survives real life:

expired tokens
flaky platform APIs
posts that need review
queues that drift out of sync
failures that happen while you are asleep

That gap changed how I think about automation.

I have been building a project called PostPunk, and I thought the hard part would be generating content and wiring platform APIs together. That turned out to be the easy part.

The real work was operational trust.

A useful scheduler needs a few things that demos usually skip:

1. Approval states matter

Not every post should go straight from draft to published.

So I ended up treating post states as part of the core workflow, not just metadata:

draft
approved
posted
failed

That sounds simple, but it changes everything.

2. Failure is not an edge case

In scheduling systems, failure is normal.

A platform token expires.
An API rate-limits you.
A platform changes a field name.
An account is misconfigured.
A browser fallback stops matching the UI.

If the whole system falls apart the moment one target fails, you do not have automation. You have a fragile demo.

So the system needs:

retries
visible failure states
alerts
manual assist when automation is not trustworthy

3. Automatic is not the same as unattended

A lot of posting tools sell the dream of full autopilot. In practice, a better model is often:

automate what is stable
assist where platforms are hostile
keep the queue and schedule as the source of truth

That still saves a huge amount of time, and more importantly, it is honest.

4. Scheduling is really an operations problem

The UI part is not enough.

You also need:

a worker that checks for due posts
logs
retry logic
success and failure alerts
a clear what is due today view

Without those, the schedule is just decorative.

What I learned

The hardest part of automation is not getting software to do something once.

It is getting it to behave predictably enough that you stop worrying about it.

That is the part I care about now.

If you are building internal tools, creator tools, or any kind of scheduler, reliability is the actual feature. Everything else is packaging.

PostPunk is still a project I am actively working on, but building it has made me much less interested in shiny automation promises and much more interested in boring operational trust.

Why I Stopped Overpolishing Side Projects

Ashley B — Tue, 17 Mar 2026 05:12:20 +0000

Most small projects die from overthinking, not lack of skill.

I’ve been shipping small creative products lately, including a kawaii coloring series.

What changed wasn’t tools.
It was lowering the bar to publish.

Instead of asking:
"Is this perfect?"

I ask:
"Is this usable and clear?"

That shift alone made me ship more in a month than I used to in six.

Curious how others approach this—do you optimize first or ship first?

Quick Build Note

Ashley B — Tue, 17 Mar 2026 05:08:29 +0000

Small creative products are underrated.

They don’t need complex systems.

Just:

clear idea
consistent style
actually shipping

This kawaii coloring series is basically that in practice.

Trying to keep things simple and repeatable.