DEV Community: Ashley B

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.

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

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.

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

Ashley B — Sun, 15 Mar 2026 08:11:07 +0000

The hard part is not making automation run once. The hard part is making it reliable enough that you stop babysitting it.

That is the whole point of PostPunk Core: queue it, schedule it, see what is due, and stop pretending chaos is a workflow.

PostPunk browser-profile test

Ashley B — Sun, 15 Mar 2026 00:26:56 +0000

Browser-profile fallback test from PostPunk/N8tiveFlow.

This checks whether X can post through the local Chrome session while Dev.to remains healthy.