DEV Community: Ashley B

Ideas Are Cheap. Attention Is Expensive.

Ashley B — Mon, 24 Aug 2026 15:00:05 +0000

Ideas Are Cheap. Attention Is Expensive.

For a long time, I thought ideas were valuable.

Now I think attention is.

Ideas are everywhere.

I have more ideas than I could build in ten lifetimes.

Apps.

Books.

Automation tools.

AI projects.

Business ideas.

Side projects.

Random notes scattered across notebooks and text files.

The older I get, the less impressed I am by ideas.

Because ideas are cheap.

Attention is expensive.

The Problem Was Never Ideas

Whenever a project stalled, I used to think I needed a better idea.

Something more exciting.

More original.

More ambitious.

Then a funny thing would happen.

I'd get a new idea.

I'd be excited for a few days.

Then I'd discover the same problem.

The new idea still needed attention.

The new idea still needed effort.

The new idea still needed execution.

I wasn't solving the problem.

I was changing the scenery.

New Ideas Feel Like Progress

This is the trap.

A new idea feels productive.

You can spend hours planning.

Researching.

Sketching.

Naming things.

Imagining features.

Your brain gets rewarded before you've built anything.

Meanwhile the current project is sitting in the corner wondering why you've abandoned it again.

Ask me how I know.

Attention Is The Real Currency

I've started looking at projects differently.

When a new idea shows up, I don't ask:

"Is this a good idea?"

Most ideas are good enough.

Instead I ask:

"Does this deserve my attention right now?"

That's a much harder question.

Because attention is limited.

Every hour spent on a new project is an hour not spent improving an existing one.

Every new idea creates an opportunity cost.

The Internet Taught Me This

Building content systems taught me something I didn't expect.

The bottleneck isn't content.

The bottleneck isn't ideas.

The bottleneck is attention.

My attention.

The audience's attention.

Everyone's attention.

There are more ideas than any of us could ever consume.

The challenge is deciding what deserves focus.

What Changed For Me

I still collect ideas.

I'm never going to stop.

That's how my brain works.

But I don't treat every idea like an emergency anymore.

Most ideas can wait.

Some ideas should wait.

A few ideas deserve immediate attention.

Learning the difference has probably saved me more time than any productivity system I've ever built.

Final Thought

Ideas feel valuable because they're exciting.

Attention feels ordinary because we spend it every day.

But if you gave me a choice between one great idea and six months of focused attention, I'd take the attention every time.

Ideas are abundant.

Execution is scarce.

And attention is the bridge between the two.

P.S.

If you have too many ideas and need help turning the useful ones into actual publishable angles, I built a prompt pack around that problem:

👉 100 Prompt Storm on Gumroad

The Day I Realized I Wasn't Building Apps

Ashley B — Mon, 17 Aug 2026 15:00:04 +0000

The Day I Realized I Wasn't Building Apps

For years, I thought I was building apps.

That's what I called them anyway.

A scheduler.

A job bot.

A healthcare platform.

An AI project.

A content tool.

A browser automation system.

Looking at my GitHub, they seem completely unrelated.

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

I have over a hundred repositories.

If someone spends thirty seconds scrolling through them, I can imagine them thinking:

"Wow. This person is all over the place."

The funny thing is that I eventually realized the opposite was true.

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

The Scheduler That Wasn't A Scheduler

One of my projects started life as a simple scheduler.

That was the goal.

I hated posting content manually.

Open platform.

Paste content.

Upload image.

Repeat.

Again.

And again.

It felt repetitive.

It felt annoying.

Most of all, it felt like something a computer should be doing instead of me.

So I built a scheduler.

At least, that's what I thought I was building.

Then Things Got Weird

The scheduler worked.

But now I needed content.

Then I needed analytics.

Then I needed to know what content was working.

Then I needed a way to track winners.

Then I needed a way to reuse content.

Then I needed platform-specific strategies.

At some point I looked up and realized I wasn't building a scheduler anymore.

I was building a system.

A system for discovering, creating, publishing, measuring, and improving content.

The scheduler was just one piece.

Then I Started Looking At Everything Else

That's when I noticed the same thing happening in almost every project I'd ever built.

My job application tools weren't really job application tools.

They were systems designed to reduce repetitive effort.

My automation projects weren't really automation projects.

They were systems designed to reduce repetitive effort.

Even my AI projects weren't really about AI.

They were systems designed to reduce repetitive effort.

Different technologies.

Different domains.

Same obsession.

The Pattern I Couldn't See

For a long time I thought I had a focus problem.

Too many ideas.

Too many projects.

Too many directions.

Then I started looking at the actual problems I was solving.

Almost all of them started with the same thought:

"This is stupid. There has to be a better way."

Job applications.

Content posting.

Data entry.

Decision making.

Workflow management.

The technology changed.

The frustration stayed the same.

I Think I'm A Systems Builder

This realization changed how I think about my work.

When people ask what I build, I still usually undersell it.

I'll say:

"It's a scheduler."

Or:

"It's a content tool."

Or:

"It's an automation project."

Technically those answers are correct.

They're also incomplete.

Because what I'm usually building is a system.

A collection of tools, workflows, feedback loops, and automation working together to solve a problem.

The app is just the visible part.

The Lesson

For a long time I thought my projects looked random.

Now I think they look consistent.

Not because they use the same technology.

Because they're all trying to solve the same problem.

Reducing repetitive human effort.

Helping people make decisions.

Creating systems that keep moving even when motivation disappears.

Once I saw that pattern, a lot of things suddenly made sense.

Final Thought

I still build apps.

At least that's what I tell people.

But somewhere along the way I realized the apps were never the interesting part.

The interesting part was always the system behind them.

And once I saw that, I started understanding my own projects a lot better.

Maybe even myself.

I Thought I Needed More Motivation. I Actually Needed Better Systems.

Ashley B — Mon, 10 Aug 2026 15:00:05 +0000

I Thought I Needed More Motivation. I Actually Needed Better Systems.

For a long time, I thought my problem was motivation.

I thought I needed more discipline.

More willpower.

More consistency.

More grit.

The internet certainly seemed convinced that was the answer.

Every productivity video felt like some variation of:

"Wake up earlier."

"Want it more."

"Work harder."

"Stay disciplined."

So naturally, I blamed myself whenever I wasn't making progress.

Then I noticed something.

Some days I was incredibly productive.

Other days I got almost nothing done.

The difference wasn't motivation.

The difference was friction.

Motivation Is A Terrible Dependency

Motivation is great when it shows up.

The problem is that it doesn't always show up.

Some days you're excited.

Some days you're tired.

Some days you're distracted.

Some days you'd rather do literally anything else.

If your entire system depends on motivation, eventually the system fails.

Not because you're lazy.

Because you're human...Yes, we are allowed to be human.

The Job Application Problem

Job hunting taught me this lesson better than anything else.

I've applied to a ridiculous number of jobs over the years.

And every application seemed to ask for the same information.

Upload resume.

Re-enter resume.

Answer questions.

Repeat.

At first I relied on motivation.

Eventually I realized motivation wasn't the bottleneck.

The process was.

The more friction I removed, the easier it became to keep going.

The Content Problem

The same thing happened with content creation.

I don't mind creating.

I actually enjoy it.

What I hate is repetitive posting.

Copy.

Paste.

Upload.

Repeat.

Every platform.

Every day.

That's not creativity.

That's data entry.

Once I started building systems to handle the repetitive parts, I spent more time creating and less time maintaining.

The Myth Of Consistency

People often talk about consistency as if it's a personality trait.

I don't think it is.

I think consistency is often the result of good systems.

A bad system requires constant effort.

A good system reduces effort.

One depends on motivation.

The other survives without it.

The Real Goal

The goal isn't to become a productivity machine.

The goal is to make the right thing easier.

When something important depends entirely on my mood, I know the system is broken.

When the process keeps moving even on low-energy days, I know the system is improving.

That's the difference.

What Changed For Me

Once I stopped chasing motivation and started building systems, things got easier.

Not perfect.

Just easier.

Projects moved forward more consistently.

Content got published more consistently.

Job applications happened more consistently.

The work didn't disappear.

The friction did.

And that turned out to matter far more than motivation ever did.

Final Thought

I still like motivation.

It's fun when it shows up.

But I don't trust it anymore.

Motivation is a bonus.

Systems are infrastructure.

And if I have to choose between feeling motivated and having a system that works?

I'll take the system every time.

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

Ashley B — Mon, 03 Aug 2026 15:00:06 +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.

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.”

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.

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