DEV Community: Meysam

AI-Assisted Coding Killed My Joy of Programming

Meysam — Mon, 01 Dec 2025 00:00:00 +0000

The Cheat Code Moment

I remember when I was younger..

any time I was playing a video game, and I discovered that they support activating cheat codes in the game..

that I was initially way too excited.. I could finally bought that expensive house in uptown, one that I had my eye on for a while..

I told myself, I'll just add some cheat codes for the money and then I'll get back to the normal game playing..

it was simple, it was a promise to myself...

it was a lie!

The Slippery Slope

I eventually ended up using more and more of the cheat codes...

even the ones I initially set out not to use at all because I believed they'd ruin the game experience for me....

I used them all! it did ruin the game for me.. I uninstalled the game after a few hours.

AI Coding Assistants Feel the Same Way

honestly, working with AI assisted code editors give me the same feeling.. I initially get excited.

I can now do more, achieve more, implement and design more and create better projects..

I tell myself it'll only be for a specific business logic, or a specific file... and then I'll get back to normal coding..... I never do. I end up running the whole project through the AI coding editor.

spoiler alert: it ruins my experience and takes away the joy of programming I initially started my whole career for!

When Coding Stops Being Fun

then I end up doing what I ended up doing to my video games a few years back. I stop doing it.

I close my laptop and go play my piano... because the coding is no longer fun.. it's no longer exciting..

I am no longer solving any mentally-stimulating problems.. I am just copy-pasting code from an AI assistant.

it no longer scratches any itch, no longer feels rewarding, no longer feels like an accomplishment.

The Emptiness After AI-Generated Code

I feel dead inside afterwards. I feel like I hate myself, wasted hours for nothing... accomplished nothing.

it pains me because I love that excitment, that joy of programming, the troubleshooting and banging my head against the
wall for hours dealing with compiler errors, runtime errors, logic errors, bugs, edge cases and all that jazz.

The Democratization of Code in 2025

now that coding is democratized in 2025 with so many "agents", I no longer feel like I am special as a programmer.

I feel useless to be honest. I feel like anyone can do what I do, and better, faster, cheaper and with less effort.

you write one prompt, not even the most perfect and engineered one, and after 2-3 min you get a full-fledged, (near-)production-ready code.

deploy it and forget about it and it'll run forever.

experiment as much as you like because building is now no longer a bottleneck... some would argue that it never has been...

some would say that marketing and distribution are the heavier lifts... I might agree to some extent.. I wrote about why distribution beats product when I launched my first SaaS to zero customers.

I Miss the Grind

I still miss that feeling though.

I still want to do programming, use Ctrl + Space for auto-completion, not tab, tab, tab and you are done.

I would've loved to stay a few years more into the years of Fortran, Cobol, C, C++, Java, Python, JavaScript, TypeScript, Rust, Go, Dart and all the other languages.

grinding and learning how to deal with Rust macros (I never did!).

pity.

Losing Control of Your Own Codebase

and when you run your whole codebase through AI, you are no longer in charge, AI is.

you have no clue what is where, how to make the changes you want, how to debug issues, how to optimize performance, how to refactor code, how to scale the system.

you tell AI to do all that and you're completely ignorant to it all. you are just a consumer of AI generated code.

and if that's all that I can do, run a few prompts and sit there like an ugly duck, then what's the point of being a programmer?

What's Left for Programmers?

what's the point of me even being there to tell it what to do.

it can already ideate, brainstorm, perform market research, competitor analysis, design systems architecture, design database schemas, write code, test code, deploy code, monitor code, fix bugs, optimize performance, refactor code, scale systems and do everything else that I used to do as a programmer.

perhaps the ONLY thing it's not doing is customer discovery. the grind of calling people, reaching out to them,
asking about their pain points in their workflows, understanding their needs and desires, and then building something for them. The same customer discovery I learned to prioritize after my first product failure.

it's not far fetched to think that AI can do that too in the near future.

The Craft Evolves

programmers once felt this way about high-level languages replacing assembly. about IDEs replacing vim. the craft evolves.. maybe the joy migrates too. I just haven't found where it moved yet.

Why I Keep Going Back to My Piano

at least the piano doesn't autocomplete my scales. maybe that's why I keep going back. some things should stay slow.

Finding the Balance

so here I am, caught between efficiency and joy. maybe you're here too. if you've found the balance, I'd genuinely love to hear how.

leave a comment below and share your thoughts!

WE'RE LIVE ON PRODUCT HUNT

Meysam — Sat, 29 Nov 2025 12:21:44 +0000

WE'RE LIVE ON PRODUCT HUNT

Awesome Directories: 300+ curated launch directories for indie hackers

→ Free forever
→ Open source (Apache-2.0)
→ Built in 3 weeks
→ $0 revenue (it's free, but who cares)

🔗 Link below

https://www.producthunt.com/products/awesome-directories

If you've ever wasted time researching "best startup directories," this might save you 20 hours

That's it. That's the pitch.

I'm responding to EVERY comment on PH today

Ask me anything:

Tech stack
Why I built this
Why it's free
What I learned building in public

I'll answer everything.

3-week journey:

Week 1: Built MVP
Week 2: Shipped features based on feedback
Week 3: Panicked about launch (just kidding… kind of)

Building in public with zero audience was humbling.

But here we are.

How you can help:
→ Upvote if you find it useful (not charity)
→ Comment with your directory experience
→ Share with a founder friend

That's it.

No gimmicks.

No "I'll upvote yours if you upvote mine" BS.

Just: does this help you or not?

I'll be here all day

Responding.
Sharing updates.
Probably drinking lots of coffees.

Let's goooo 🚀

buildinpublic

I Sent 200+ Cold Messages and Got Zero Calls: My Customer Discovery Reality Check

Meysam — Sat, 29 Nov 2025 12:21:38 +0000

200+ cold messages.

2-3 weeks of outreach.

Zero calls booked.

That's my customer discovery reality check.

I could've waited to share this. Found a better story. Polished the numbers.

But here's what I've learned building in public:

The failures are the story.

After my first SaaS flopped (2-3 months building, 0 customers, $0 revenue), I made myself a promise: no code until someone's ready to pay.

So I'm doing customer discovery the hard way.

Cold LinkedIn outreach to strangers who don't know me, don't owe me anything, and mostly ignore me.

Response rate? Abysmal.
Conversion to calls? Zero.

Giving up? Not a chance.
My mamma didn't raise no quitter.

What I'm learning:
→ Consistency beats perfection (I'm seeing more engagement after 2-3 weeks of daily posts)
→ The work you do when nobody's watching compounds
→ Sharing losses builds more trust than curated wins

This week was a loss by any metric.

But there's only one way to go from here: forward.

Full breakdown on my blog (link in comments).

What's your cold outreach experience been like?

I'd genuinely love to hear; especially from folks who figured out what I'm clearly missing.

48 hours until Awesome Directories launches on Product Hunt

Meysam — Wed, 26 Nov 2025 15:00:00 +0000

48 hours until Awesome Directories launches on Product Hunt

Quick thread on what I learned building in public for 3 weeks 🧵

(Spoiler: Follower count is a lie)

I started with:

15k LinkedIn followers
200 avg impressions (lol)
150 X followers
Zero engagement

I thought: "I have an audience. This will be easy."

I was wrong.

Week 1:

Posted announcement: 3 likes
Posted tech stack: 12 likes
Asked a question: 47 likes

Lesson: People don't care about YOUR product. They care about THEIR problems.

Questions > announcements.

Week 2:

Shared daily build updates
Posted polls
Responded to EVERY comment
Impressions doubled

Lesson: Consistency beats perfection.

5 posts/week with engagement >> 1 perfect post/week

Week 3:

Stopped saying "I built this"
Started saying "This might help you"

Lesson: Make it about them, not you.
Nobody cares about your product.

Building in public. Real failures, real lessons.
Join 1,500+ → meysam.io
They care about their problem.

3-week stats:

LinkedIn impressions: 180 → 520 avg
X impressions: 30 → 90 avg
Early access signups: 2
GitHub stars: 2

Not viral. But real.

What I'd do differently:

✓ Start asking questions Day 1
✓ Share struggles sooner (vulnerability > polish)
✓ Post 2x/day on X (once wasn't enough)
✓ Use more GIFs/screenshots (visual > text)

Friday 12:01am PST:

We launch on Product Hunt

I'll be there.
Responding to comments.
Sharing behind-the-scenes.
Probably panicking.

Link in the comments

See you Friday 🚀

buildinpublic

Awesome Directories launches on Product Hunt THIS FRIDAY

Meysam — Mon, 24 Nov 2025 15:00:00 +0000

Awesome Directories launches on Product Hunt THIS FRIDAY

Here's everything you need to know in one thread 🧵

(And how you can help, if you want)

What is it?

300+ curated launch directories for indie hackers

Free forever
Open source (Apache-2.0)
No sign-up required
Built by a founder, for founders
CLI available for nerds

Why I built it

I wasted 20 hours researching directories for my last launch
You shouldn't have to

That's it. That's the reason.

Key features:

Filter by DR, dofollow, pricing
Multi-select checklist export
Community voting (wisdom of crowds)
Real-time search
Screenshot generator for social
Submission tracking (optional)

Launch day plan (Friday 12:01am PST):

I'll be:

Responding to EVERY comment on PH
Sharing behind-the-scenes on Twitter
Probably drinking too much coffee
Refreshing PH every 30 seconds

How you can help (if you want):

✓ Upvote on Product Hunt (Friday morning)
✓ Share your experience with directories (comment on PH)
✓ Retweet this thread (help me reach founders)

I'm not asking for charity. Only if you genuinely find it useful.

Link in the first comment

Why am I building in public?

Because 15k LinkedIn followers with 200 avg impressions taught me:

Follower count means nothing.
Trust means everything.

Transparency > polish.

See you Friday 🚀

I'll be the guy nervously refreshing PH at 12:01am

https://www.producthunt.com/products/awesome-directories

Let's goooo

buildinpublic #indiehacker #opensource

I Sent 200+ Cold Messages and Got Zero Calls: My Customer Discovery Reality Check

Meysam — Mon, 24 Nov 2025 00:00:00 +0000

I spent that last 2-3 weeks sending 200-300 cold outreach

I'm working on a new idea these days.

I've identified my niche...

researched the market...

analyzed the trends...

I've gathered some initial intel and aggregated some insights to help me navigate the next few steps.

they are essentially just a starter for me.. nothing fancy.

since I know from experience that the things that you can't sell, are the things not worth building, I'm not writing code yet
unless I know someone is taking out their credit card and paying for it with real money.

that means that I am strongly bullish on customer discovery these days.

I've sent out around a few hundreds so far

the conversions are low, to say the least..

but I'm locked in

I'm no quitter. my mamma didn't raise no quitter.

we're just getting started.

anyway, there's no crazy progress to share, only that I've been doing these cold outreach via LinkedIn and the response
rate is abysmal.

and so far, zero people got on a call.

the day I get to talk to 5-10 people is what I'd call Christmas.

Lessons learned so far

I've been building in public for the past 2-3 weeks, much more seriously than I've done so before.

I shared my progress, my screenshots, my numbers and metrics publicly...

and the lesson is that consistency is key.

prior to this, I didn't get lots of impression nor engagement.

but lately I'm seeing a few likes here and there, maybe 1 comment the lady luck is with me that day

nothing to celebrate like a La Liga championship, but it is still progress

and believe me, for a perfectionist, progress is hard to come by.

2nd Public Piano Performance

last week I had my second public performance as a student learning to play piano.

the result of that performance is available at the following YouTube link: https://youtube.com/shorts/jgPCoNX3iGI

I am not going to include an embed because Google will slow down the page loading speed significantly, not to mention
the massive tracking and privacy concerns it raises.

it's like a leach on your website, sucking the life out of it, ruining the user experience and making your visitors miserable.

this is another example of showing up consistently. small wins add up, whether in cold outreach, building in public, or learning an instrument.

Launching soon

https://awesome-directories.com is fully live.. two weeks so far...

we're live on Product Hunt this Friday: https://www.producthunt.com/products/awesome-directories

I would appreciate if you could take the time to check it out and leave a comment or an upvote

especially comments since those are a more serious signal of engagement than upvotes

What's next

I have a few ideas in mind
some pre-baked products that need final touches
more customer discovery to do
learning my craft

and most important of all, the thing that keeps me up at night is this:

for every Monday, I map out a plan for my upcoming seven days, in a way that I have something to share as a key takeaway and/or
lesson in the next week when sharing my build in public journey.

this piece you're reading right now is a part of that plan.

I hope to continue sharing vulnerable struggles and even losses.

for example, this week and with hundreds of outreach and zero customer calls is a loss.

onwards and upwards because there's only one way to go from here: forward.

I Built a Directory Aggregator in One Weekend (Then Made It Open Source)

Meysam — Mon, 17 Nov 2025 00:00:00 +0000

I Built a Directory Aggregator in One Weekend (Then Made It Open Source)

I spent 15 hours last week clicking through outdated listicles and $127 PDFs trying to find decent directories to launch a SaaS. I got frustrated. So I built awesome-directories.com over the weekend.

Total development time: ~10 hours spread across one weekend plus evening sessions this week. It's live. It's open source. It's free forever. And it's ready for beta users.

Here's what I built, how I built it, and why I'm giving it away.

The Problem Nobody Solved Well

Every founder I talk to has the same ritual: spending 2-3 days hunting for directories where they can launch their product. You click through blog posts from 2023 with half the links dead. You find "ultimate lists" with 300+ directories where maybe 10 actually matter. You discover paid spreadsheets charging $127-$6,999 for what amounts to a glorified CSV file.

The existing solutions have three fundamental problems:

Dead links everywhere. Most directory aggregators are one-time projects that never get maintained. Links rot. Sites shut down. Nobody updates them.

Signal-to-noise ratio is terrible. When someone gives you 300 directories, that's not helpful—that's overwhelming. My research showed that 3-5 directories drive 90-95% of actual launch results. The other 295? Noise.

No context, no curation. A URL and a name don't tell you what you actually need to know: Is it dofollow? Is it free? What's the Domain Rating? Is the site even active?

I needed something better. So I built it.

What I Built

Awesome Directories is a curated directory aggregator that helps you find the top 20-30 directories worth your time in under 3 minutes.

Core features:

388+ manually curated directories (verified, not scraped)
Real-time filtering by Domain Rating, category, pricing, dofollow status
Instant search across names, descriptions, and categories
Multi-select checklist with PDF/CSV export
Weekly automated Domain Rating updates
Community voting and reviews (authentication required)
Lightning-fast performance (all Lighthouse scores above 90)

What makes it different: Every directory is verified. I didn't scrape these from somewhere else. I went through each one, checked if it's active, verified the submission process works, and documented what actually matters: pricing, link type, Domain Rating.

The filtering is instantaneous. You can search, filter by multiple criteria, and see results update in real-time without any lag. Select the directories that match your product, export to PDF or CSV, and you're done. Three minutes instead of three days.

How I Built It (The Technical Deep Dive)

Here's where it gets interesting. I had one weekend and a constraint: zero ongoing costs. This forced some interesting architectural decisions that actually made the product better.

The Stack

Astro v5 as the foundation. Not React, not Next.js, not pure Vue. Astro lets me build statically generated pages that are SEO-optimized by default, with minimal JavaScript shipped to the client. The entire site is static HTML + CSS with tiny Vue islands for interactive components.

Why Astro? Three reasons:

pSEO capabilities. Every directory could theoretically get its own optimized landing page. Static generation makes this trivial.
Performance. Astro ships zero JavaScript by default. You only get JS for the components that actually need interactivity.
Developer experience. Component-based like modern frameworks, but outputs plain HTML. Best of both worlds.

Vue islands for interactivity. The filtering, search, and checklist features? Those are small Vue components that hydrate on the client. Everything else is just HTML. This is why the Lighthouse scores are all above 90—there's barely any JavaScript to parse and execute.

Supabase for everything backend. PostgreSQL database, authentication (Google and GitHub OAuth), and—here's the cool part—automated weekly updates via Supabase Edge Functions + the pg_cron extension.

Every Sunday at 2 AM UTC, a cron job triggers an Edge Function that fetches fresh Domain Rating scores from the Moz API and updates the database. No GitHub Actions. No external servers. It's all inside Supabase. Set it once, forget it forever.

Netlify for preview deployments. GitHub Actions builds the static site (bun run build), uploads the dist folder to Netlify, and I get instant preview URLs for every commit. Zero cost. Instant feedback on every change.

Tailwind CSS for styling. I needed to ship fast. Tailwind let me prototype rapidly without fighting CSS specificity or maintaining separate stylesheets. Is the design perfect? No. Is it functional and clean? Yes.

Architecture Decisions That Mattered

Static-first architecture. Everything that can be pre-rendered at build time is pre-rendered. The directory data lives in Supabase, gets fetched at build time, and baked into static HTML. Users get instant page loads. I get zero server costs.

The only dynamic parts are authentication (handled by Supabase), voting (requires auth, hits Supabase realtime), and comments (Supabase database + auth). Everything else is static files served from a CDN.

Authentication-gated interactions. Initially, I considered IP-based voting. Simpler, no login friction. But it's gameable and doesn't build a real community. I pivoted: you need to authenticate (Google or GitHub OAuth via Supabase) to vote or comment.

This does two things: it filters for engaged users, and it gives me a foundation for future features (saved lists, submission tracking, etc.). The friction is worth it.

Supabase for comments, not a third-party tool. I could've integrated Giscus or Disqus. Instead, I built comments directly in Supabase. Why? Control. Data ownership. And honestly, it was faster than integrating and configuring a third-party service.

Comments are stored in a PostgreSQL table with Row Level Security policies. Authentication is handled by Supabase. Realtime updates are built-in. I didn't need to build much—I just wired together Supabase primitives.

Performance obsession. All Lighthouse scores above 90. This wasn't an accident. Astro's static generation handles most of the heavy lifting, but I also:

Lazy-load images with proper loading="lazy" attributes
Minimize JavaScript hydration (only 3 Vue islands total)
Use Tailwind's JIT compiler to ship minimal CSS
Serve everything through Netlify's CDN

First contentful paint is under 1.2 seconds even on 3G.

The Time Breakdown

Saturday (5 hours):

Set up Astro project with Tailwind
Design Supabase schema (directories table, votes, comments)
Build core directory listing page with Vue island for filters
Implement real-time search and filtering

Sunday (3 hours):

Multi-select checklist component
PDF/CSV export (using jsPDF and Papa Parse)
Deploy to Netlify, set up custom domain
Configure Supabase authentication

Week 1 evenings (2 hours):

Set up Supabase Edge Function for weekly DR updates
Configure pg_cron for automated scheduling
Fix edge cases in filtering logic
Polish UI, fix responsive layout issues

Total: ~10 hours from zero to shipped product.

Why Open Source (The Strategic Pivot)

Here's where I need to be transparent.

I originally planned to charge for this. I did market research, validated the problem with 40+ founder interviews, built pricing tiers—$9/month or $49/year. The pain point was real. People said they'd pay.

Then I looked at the unit economics.

At my scale—no existing audience, no email list, no distribution—customer acquisition cost would be $40-60. To break even, I'd need subscribers to stay for 6+ months. But this is a tool people use once or twice a year, max. The retention math was broken before I even launched.

I could force a business model that doesn't make sense, or I could pivot to something that actually works at my scale: building credibility and audience through open source.

The real opportunity isn't $9/month from 100 people. It's recognition in the indie hacker space. This project is my credential. It's proof I can identify a problem, build a solution, and ship it fast. It's my way into conversations with other founders.

Plus, I just wanted this to exist. If it helps other founders save 15+ hours of research hell, that's already worth it.

What Apache-2.0 license means for you:

Fork it, modify it, self-host it
Use it commercially
No attribution required (though appreciated)
No paywalls, ever
No bait-and-switch to freemium

This is free forever because the business model isn't "charge users"—it's "build reputation in a space I care about."

Current State & What's Next

The product is stable. Most of the early bugs are fixed. Authentication works reliably. Filtering is fast. Export works. Weekly DR updates run automatically.

What I need from beta users:

Edge cases I haven't found yet
Feature priority feedback (what actually matters to you?)
Directory suggestions (know a high-quality one I'm missing?)
Reviews and votes (helps surface signal for other users)

Launching on Product Hunt next Friday. But I'm not waiting to get feedback. If you're launching a product soon, try it now. If something breaks or feels wrong, open an issue.

Immediate roadmap (shaped by community, not ego):

Browser extension for one-click directory submissions
Verified badges for directory creators who engage
More granular filtering (submission turnaround time, geographic focus)
Public API for programmatic access
Integration with popular launch checklists

But honestly? The roadmap will be shaped by what you actually need, not what I think is cool.

What I Learned Building This

Research saves time. I spent almost as much time validating the problem and researching the market as I did coding. That research saved me from building a subscription product with broken unit economics. It informed the curation strategy (focus on the top 20-30, not 300+). It shaped the feature set (filtering and export, not social features).

Static architecture = speed + zero costs. Astro's static generation isn't just about performance—it's about economics. No server costs. No scaling concerns. No database read costs spiraling. Just static files on a CDN. This is how you build sustainable side projects.

Supabase Edge Functions + pg_cron is criminally underutilized. Everyone reaches for GitHub Actions or external cron services. But if you're already using Supabase, you have PostgreSQL's built-in cron scheduler. Write an Edge Function, schedule it with pg_cron, and you have automated workflows that never leave your database.

Authentication-gated interactions filter for quality. The friction of requiring login kills casual spam and builds a real community. Yes, you lose some engagement. But the engagement you keep is higher signal.

Open source can be your credential, not just your code. This project won't make me money directly. But it's already opening doors. Conversations with other founders. Visibility in communities I care about. Proof I can ship. That's worth more than $9/month from 50 people.

Ship when it works, not when it's perfect. The UI isn't polished. Some edge cases probably exist. The roadmap is incomplete. But it solves the core problem—finding quality directories fast—and that's enough to ship. Perfection is procrastination in disguise.

Join the Journey

This is my first major public project as an indie hacker. I built it to solve my own problem, made it free because the unit economics made sense that way, and I'm documenting the journey because I'm learning as I go.

If you're launching a product and want to skip 15+ hours of directory research:
Try awesome-directories.com
If you think something could work better:
Open an issue
If you want to contribute:
Star the repo (helps with Product Hunt visibility)
Submit a PR for missing directories
Leave a review to help other founders

Built by indie hackers, for indie hackers. No VC funding. No growth hacking. Just solving real problems with good code.

Launch on Product Hunt: Next Friday.

See you there.

I Used AI to Write My Last Blog Post and HN Flagged It

Meysam — Fri, 14 Nov 2025 00:00:00 +0000

What's all this fuss about AI-written content on Hacker News?

so, this week, ~~I wrote~~ AI wrote a blog post for me on Monday Nov 10th.

I didn't submit it right away the same day, because I wanted a steady momentum from other social media platforms first.

The Unexpected Viral Moment

then on Thursday evening (my evening, EST/PST's morning)

it got submitted and over the first half an hour of submission, it got a few upvotes and a few comments

it was a clear and early sign of going "viral" on HN

I say viral in quotes because I have never had a viral moments on HN, never before, not at this scale

Why This Matters to Small Creators

now you might be a content creator who gets these numbers for lunch but for me it's a different story. for me these numbers matter

cause my normal numbers are usually around 200 impressions (from 15k linkedin followers), maybe 1-2 likes and zero comments (from my 150 X followers), and generally, I never got any more than 2 upvotes for my personal blog posts on HN before

so you can imagine this is a big deal for me. not for Elon Musk and others of course but I'm no billionaire, hell I'm not even a millionaire

now, you can go ahead and read the subsmission for yourself, it's at the bottom of this page in the references section

but here's my line of thoughts towards those folks who were calling me out, making me look like a villain

here's the unfiltered, non-AI generated format of how I would like to speak to those individuals who were so blatantly against my submission

My raw, non-AI and unfiltered response to HN folks

The Moral High Ground Problem

what's all this moral high ground everyone takes?

English is not my first language and HN is, let's face it, primarily for US and English speaking folks

I, just like any other small creator, am just trying to submit my website, get a juicy backlink and increase my chance of survival over millions of billions of other webpages across the web, and hopefully get some discussions going, learn something and ideally I may even get some email subscribers to my newsletter

which I DID

The Numbers Don't Lie

now, let's talk numbers before I go deeper.

in less than 12hr from submission, I got nearly 1200+ unique visitors to my website, meysam.io, I even got 100% traffic increase to my other OSS project awesome-directories.com in the same timeframe

that is not prejudice or bias, that is just pure data-driven outcome, or decision making framework if I may; out of those 1.2k, 4m avg duration spent on the website and 93% bounce rate from all around the glob and not just the USA (48%)

I even got two new subscribers to my newsletter, which is the whole fucking point of writing and building in public in the first place

here's the screenshot of my analytics page below

Fig.1 - Analytics screenshot showing 1.2k unique visitors, 4m avg duration, and 93% bounce rate

My Unapologetic Stance on Using AI

now I am not denying that I didn't write the blog post entirely from AI

I use AI daily for everything, development or marketing

and I am not shy nor am I going to apologize to no-fucking-body

I mean, technology is here to make our lives easier, more efficient and faster

does anyone blame students for using calculator for performing their number churn?

how about business worlds where we use tech everyday to speed up the revenue?

I was using C++ back in the day, then python and then Go, and now AI.
are you gonna cry about it? grow the fuck up.

I am using AI. sue me.

The AI-Written Content Backlash

why is there so many backlashes? what's the hate towards AI-written content?

do you not see AI blog post generator these days popping out like mushrooms?
I know a handful few and I'm not gonna drop names here but do you go out dismissing their entire business model because you don't like AI-fucking-writing-style?

It's Well-Written, Period

I mean, the blog post is very well-written, read it

it is punchy, very engaging, it is breathtaking and you almost do not blink while you're reading it

it is a very well-focused, high-engagement piece of article; a great storytelling, a solid narrative

and it is not something that's fake or anything

it's coming from my own raw thoughts

I fed the AI with my thoughts and asked it to ask me questions, the answers of which will shape a high-engaging blog post with my tone, with my authenticitiy, with my own personal and emotional twist

The Time Reality Check

and I am darn happy with the result because it has been written in a way I couldn't have done myself in a hundred years

ok, maybe that's exaggeration and I could've written it better without AI slop in a more authentic manner

but how long would that take me? months? years? with AI it only took minutes

and I have personal life outside this fucking creator world that I need to manage

I'm not even an influencer

I just need a very well written piece of content that is engaging, brings in eyeballs, and makes sure to captures the essence of my thoughts and feelings and hopefully results in a few email subscribers at the end of the day

First Viral Moment Ever

I have NEVER EVER in my life had any viral HN moment before and this "AI written slop" everyone is complaining about has gained 1.2k unique visitors in just half a day
and what's wrong with that?

Don't Like It? Don't Read It

EVERYONE is entitled to their opinion

but frankly, if you don't like the styling dude? don't fucking read it.

I'm not here to please you or any other motherfucker.

I'm sharing this stuff publicly, free of charge, in a democratized internet out to the world where things are shared freely without any regard to gender, race, or any other discrimination factor

you don't appreciate this style and this content? don't fucking read it and stop fucking complaining about other people's free contents you pay zero dollar to read

The Open Web and Real Struggles

it's a fucking democratized internet, the open web, the place where no idiotic politician prick is allowed to withhold me from entering the borders of a country because of my place of birth; any Iraninan citizen in the audience!? yeah, fuck, I can't even open a bank account (FATF, anyone?) in any part of the world without being slapped in the forehead that my country is sanctioned from all the eathly and non-earthly regions of this world.

This Is My Real Experience

this blog post, the earlier ones, and all the ones that will SURELY come is my real experience

real feelings

every line of the blog post is my own personal life

just written by AI in a high-engaging manner. not this one (for a reason).

and now all of a sudden everyone gets on a moral high ground that I am the fucking villain? fuck you

The Experiment Begins

I could never had done such a punchy masterpiece if I had written in an "authentic and genuine manner with my own tone and voice"

nobody would've cared enough to fucking read it. are you reading this one? well, then I consider myself a lucky fucking bastard!

for just a simple experiment, and just to test the waters, I will write the next few blog posts in the same tone and style as the one you're currently reading

let's see if the aggregate of all the view counts in the sum of all those blog posts will match the one written by AI in my last blog post!

let's see if any of those haters will come back to say "you did great, I love your authentic voice, keep going and I will keep coming back to read your unpolished bullshit"

The Experiment Begins

I Built an Open-Source Directory Aggregator So You Don't Waste 20+ Hours Researching Launch Platforms

Meysam — Wed, 12 Nov 2025 00:00:00 +0000

The Problem I Got Tired Of

Every founder I talk to has this same painful ritual: spending 2-3 days clicking through listicles, spreadsheets, and paid "ultimate guides" to find directories where they can launch their product. Most of these resources are either outdated, include 300+ low-quality directories, or cost $127-$6,999 for a glorified CSV file.

I went through this myself and thought: there has to be a better way.

What I Built

Awesome Directories is an open-source directory aggregator that helps you find the top 20-30 directories worth your time in under 3 minutes. Think of it as the antidote to directory overload.

Key features:

✅ 388+ curated directories (manually verified, not scraped)
🔍 Advanced filtering by Domain Rating, category, pricing, dofollow status
⚡ Real-time search across names, descriptions, and categories
📋 Multi-select checklist with PDF/CSV export
📊 Weekly automated DR updates via GitHub Actions
💬 Community reviews via Giscus (GitHub Discussions)
👍 IP-based voting system for quality signals

The Tech Stack

Built with a modern, performant stack:

Frontend: Vue.js 3 (Composition API) + Vite + Tailwind CSS
Backend: Supabase (PostgreSQL + Auth + Realtime)
Hosting: GitHub Pages (100% static SPA)
Newsletter: Mautic (self-hosted)
Analytics: Pirsch (privacy-first)
CI/CD: GitHub Actions
APIs: Moz API for Domain Rating scores

Why Vue + Supabase? I needed something fast to build with, great DX, and Supabase's free tier is genuinely generous for an MVP. The entire app is a static SPA deployed on GitHub Pages, which means zero hosting costs.

Why Free Forever?

Here's where I'll be transparent: I originally planned a subscription model. Did the market research, validated the pain point, built pricing tiers. Then I looked at the unit economics and realized something uncomfortable—the numbers didn't make sense for a sustainable business at my scale.

Instead of forcing a business model that would compromise the value, I pivoted to open-source. The real opportunity isn't in charging $9/month—it's in building credibility and an audience in the indie hacker space.

What this means:

Apache-2.0 License - fork it, modify it, self-host it
No paywalls, ever
No "freemium" bait-and-switch
Community-driven feature development
Transparent roadmap and development

Technical Highlights

1. Weekly Automated DR Updates

GitHub Actions runs every Sunday at 2 AM UTC to fetch fresh Domain Rating scores from the Moz API. This ensures the data stays current without manual intervention.

- name: Update Domain Ratings
  run: bun run scripts/update-dr.js
  env:
    MOZ_API_ACCESS_ID: ${{ secrets.MOZ_API_ACCESS_ID }}
    MOZ_API_SECRET_KEY: ${{ secrets.MOZ_API_SECRET_KEY }}

2. Privacy-First Architecture

No tracking cookies
IP-based voting (hashed, not stored)
Optional authentication (Google/GitHub OAuth)
All analytics via Pirsch (GDPR-compliant)

3. Static SPA Performance

The entire app is pre-rendered and served as static assets. First contentful paint under 1.2s, even on 3G.

4. Community-Driven Reviews

Instead of building yet another commenting system, I integrated Giscus. Every directory gets a dedicated GitHub Discussion thread. Developers already use GitHub—why make them create another account?

What I Learned Building This

Research matters more than I thought: I spent almost as much time validating the problem and researching the market as I did coding. That research saved me from building a subscription product nobody would pay for.

The 80/20 rule is extreme: In my research, I found that just 3-5 directories drive 90-95% of actual results for most launches. The rest is noise. This informed the entire curation strategy.

Product Hunt isn't what it used to be: Featured launch rates dropped from 60-98% (2023) to only 10% (2024). The conventional wisdom around launches is often outdated or wrong.

Open-source can be a business strategy: Even if this never makes a dollar directly, the credibility and audience it builds has measurable value for future projects.

How You Can Contribute

This is genuinely community-driven. Here's how you can help:

Star the repo: github.com/awesome-directories/awesome-directories
Submit directories: Know a high-quality directory? PR welcome.
Report issues: Found a broken link? Open an issue.
Improve the code: See something that could be better? Fork and PR.
Share your experience: Leave a review via Giscus.

Contributing Guidelines

Add directories with DR > 60 preferred
Verify links are active before submitting
Include description, categories, and pricing info
Follow the existing data format in supabase/seed-data.json

Quick Start for Developers

# Clone and install
git clone https://github.com/awesome-directories/awesome-directories.git
cd awesome-directories
bun install

# Set up environment variables
cp .env.example .env
# Edit .env with your Supabase credentials

# Run the migration in Supabase SQL Editor
# Then seed the database with supabase/seed-data.json

# Start dev server
bun run dev

Full setup instructions in the README.

What's Next

The roadmap includes:

Verified reviewer badges for directory creators
More granular filtering (submission type, turnaround time)
Browser extension for one-click submissions
Public API for programmatic access
Integration with popular launch checklists

But honestly? The roadmap will be shaped by what the community actually needs, not what I think is cool.

The Reality Check

This isn't going to solve all your launch problems. It won't guarantee you'll get featured on Product Hunt. It won't make your product go viral. What it will do is save you 20+ hours of manual research and give you a fighting chance at focusing on the directories that actually matter.

If that sounds useful, give it a try. If you find it valuable, star the repo. If you think something should work differently, open an issue or PR.

Built by indie hackers, for indie hackers. No VC funding. No growth hacking. Just trying to solve a real problem with good code.

Live Site: awesome-directories.com

GitHub: github.com/awesome-directories/awesome-directories

License: Apache-2.0

Made with ❤️ (and probably too much coffee) by Meysam

No Competition? That's Usually a Red Flag for Solopreneurs (I Learned the Hard Way)

Meysam — Mon, 10 Nov 2025 00:00:00 +0000

I spent two months building FindForce. Perfect architecture. Clean code. Zero customers. Zero revenue.

The moment that broke me wasn't the empty dashboard. It wasn't the crickets after launch. It was staring at my payment provider page showing $0.00 in revenue—the only metric that actually mattered.

All that beautiful infrastructure? All those nights and weekends? All that SRE expertise I'd spent 8 years cultivating?

Meant nothing.

Because nobody was paying.

The "No Competition" Trap I Fell Into

I built FindForce as a business email finder Chrome extension. Simple premise: help sales teams find and verify emails with 95% accuracy.

When I started researching the market, I found giants: Hunter, Apollo, dozens of others. My first reaction? Fear.

"How can I compete with them? They have teams. They have funding. They have thousands of customers."

So I looked for an angle. A gap. Something they weren't doing.

I found one: flat-rate pricing. Exceptional customer support. Speed.

Here's what I missed: Those competitors weren't obstacles. They were validation.

Thousands of companies were already paying for email finding tools. The demand was proven. The problem was real. People had budget allocated.

My job wasn't to invent a new category. My job was to do it better for a specific segment.

But I was too busy being proud of my "unique approach" to see it.

How My SRE Background Betrayed Me

I spent 8 years as a SRE engineer. I built internal tools for dev teams. Kubernetes clusters. CI/CD pipelines. Infrastructure automation.

Here's the thing about internal tools: if you build them well, people use them. There's clear communication. Defined requirements. Immediate feedback.

I had the wrong mental model.

I thought: "If I build it excellently, they will come."

That works when your customers are coworkers in the next room. It doesn't work when your customers are strangers on the internet who've never heard of you.

I was two layers removed from real end users:

Internal tools serve dev teams
Dev teams serve external customers
I never had to think about external customers

So I optimized for 10,000 users before I had 10. I built for scale before I had demand. I perfected the infrastructure before I validated the problem.

Classic engineer mistake.

The Reddit Post That Changed Everything

Last week, frustrated and processing the FindForce failure, I wrote a post on X:

"Unpopular opinion: if nobody's doing your startup idea, that's usually a red flag, not an opportunity."

Got some traction. Felt bold. Tried it on Reddit.

160+ upvotes. 60+ comments. 48,000+ views.

The most viral moment of my 30 years on this planet.

Here's what I argued:

No competition often means:

No demand exists
Customer acquisition costs are too high
Market education burden is too heavy for small teams
Regulatory barriers make it unviable

The sweet spot isn't an empty market. It's a crowded market with broken execution.

The responses were fascinating. Some agreed violently. Others called me out on exceptions: Airbnb, Uber, blue ocean strategies.

They were both right.

The Nuance Nobody Talks About (Solopreneur Reality)

Here's what I should have said in that Reddit post:

For VC-backed teams with deep pockets, blue ocean strategies can work.

You can afford:

A GTM team to educate the market
Designers and engineers to iterate quickly
Geographic advantages (SF networking, warm intros)
Multiple attempts before running out of runway

For solopreneurs, immigrants, new parents with limited time and zero network? Different game entirely.

I'm all three. Iranian immigrant. New father. Building from home. No alumni network. No conference circuit. No warm intros.

I have to do cold DM and cold email outreach for every. single. customer conversation.

Last week I sent 40 cold LinkedIn messages to my ICP. Got 9 responses. Booked 1 customer discovery call.

That's the reality. Not 100 interviews. Not warm intros through YC. Not a network from Stanford or MIT.

Just me, a spreadsheet, and a lot of rejection.

When "No Competition" Might Actually Work

I'm not saying blue ocean strategies never work for solopreneurs. But you need specific conditions:

✅ You MIGHT pursue a no-competition idea if:

1. You have deep domain expertise

You're not flying blind
You understand the problem intimately
You've lived it for years

2. You've done 10+ customer interviews

They're actively complaining about the pain
They're already trying to solve it (badly)
They have budget allocated

3. The market shift just happened

New regulation created the need
New technology made it possible
Timing is everything

4. You have an existing audience

You're not starting from zero
You have distribution built-in
Think: YouTuber launching a SaaS

5. It's a niche too small for VCs, too big to ignore

Not venture-scale
But sustainable for one person
Examples: specific industry tools

❌ Don't pursue no-competition ideas if:

You're learning the industry as you build
You have no audience or network
You need quick revenue to survive
The market education would take years
You're a solo technical founder with zero sales experience (hi, that was me)

What I'm Doing Differently Now (Build in Public)

I'm done building in a vacuum. Here's my new playbook:

1. Distribution First, Product Second

I just launched awesome-directories.com — a curated directory aggregator for indie hackers. 300+ directories, open source, Apache-2 license, completely free.

This is the opposite of FindForce:

FindForce: Built product → tried to find users
awesome-directories: Build for community → recognition → audience → monetize later (maybe even not!)

Why? Because people listen to you when you give first.

I'm not charging. No paywall. No "freemium" trap. Just pure value.

If people subscribe to my newsletter or buy me a coffee, great. If not, I'm still building trust and recognition.

2. Ruthless Customer Discovery

Before I write a single line of code for my next SaaS, I'm doing:

200 cold LinkedIn DMs (sent 40 last week)
Aiming for 6+ booked customer discovery calls
Asking about their last painful experience with the problem
Checking if they're already paying for a solution
Understanding why they're not satisfied

I'm doing A/B testing on my outreach messages. Data-driven iteration. Engineer's approach to sales.

Does it hurt when 31 out of 40 people ignore me? Yes.

Do I keep going? Also yes.

Resilience and persistence are founder prerequisites.

3. Value-First, Always

Every piece of content. Every tool. Every interaction.

Give, give, give. Ask little.

That's how you build an audience as an unknown immigrant founder with no network.

The Framework: Should You Pursue Your "No Competition" Idea?

Here's my decision tree for solopreneurs:

Step 1: Count the Competitors

0-1 competitors: 🚩 High risk. Proceed with extreme caution.
2-10 competitors: ✅ Good. Demand is validated.
10+ competitors: ⚠️ Can you differentiate? Do you have unfair advantage?

Step 2: Talk to Customers FIRST

Before writing code: 10+ customer interviews minimum
Ask: "Tell me about the last time you had this problem"
Ask: "What are you currently using to solve it?"
Ask: "What do you hate about current solutions?"
Red flag: If they're not actively searching for solutions, problem isn't big enough

Step 3: Check Your Resources

Time: Can you afford 6-12 months of market education?
Money: Can you survive without revenue during that period?
Network: Can you reach your ICP without paid ads?
Expertise: Do you understand this domain deeply?

If you answered "no" to 2+ questions, choose a validated market.

Step 4: Look for These Green Flags

✅ Competitors exist but execution is broken
✅ Customers complaining publicly about current solutions
✅ You have an unfair advantage (expertise, audience, speed)
✅ Clear, specific niche you can dominate
✅ People are actively searching for solutions (Google/Reddit evidence)

Step 5: Make the Call

Blue ocean: Only if you have resources, network, or deep expertise
Validated market: Default choice for bootstrapped solopreneurs
Crowded market: Your best bet—demand is proven, execution is improvable

The Honest Truth: I'm Still Figuring This Out

I haven't cracked the code. I'm not writing this from a yacht.

I'm writing this from my home office, with a 4-month-old son in the next room, trying to build something that matters while doing cold outreach to strangers.

But here's what I know for sure:

Competition validates demand. I was scared of Hunter and Apollo. I should have been grateful they existed.
Technical excellence means nothing without customers. My clean code didn't matter. My 95% accuracy didn't matter. Nothing mattered until someone paid.
Distribution > Product. Always. The best product that nobody knows about is worthless.
Solopreneurs can't afford to educate markets. Leave blue oceans to funded teams. You need validated demand.
Give first, ask later. Build trust through value. awesome-directories is my bet on this strategy.

What Happens Next

I'm continuing the 200 cold DM experiment. I'll share the results—success or failure.

I'm building awesome-directories in public, documenting everything.

I'm doing customer discovery the right way this time. Every conversation. Every pattern. Every insight.

And I'm accepting that progress beats perfection every single time.

Will it work? I don't know.

But I'm showing up. I'm pushing through. I'm learning.

That's the only way forward.

Key Takeaways for Solopreneurs

If you only remember three things from this post:

1. Competition = Validation
If nobody's doing it, ask "why" before assuming you found a gap. Most gaps exist because there's no demand or prohibitive barriers.

2. Talk to Customers Before Building
10+ interviews minimum. Ask about their past behavior, not hypothetical future. "Would you use this?" is a worthless question.

3. Distribution First
Build audience through free value (tools, content, templates). Trust compounds. Then sell to people who already know and like you.

Stay Connected

I'm documenting this entire journey in public. Every lesson, every mistake, every breakthrough.

Pick your platform:

📧 Newsletter — Weekly deep-dives (1,500+ readers)
🚀 awesome-directories — Free tools for indie hackers
𝕏 @meysamazing — Daily updates and real-time insights

No fluff. No overnight success stories. Just raw documentation from the trenches.

What's your take? Am I wrong about the "no competition" trap? Have you succeeded in a blue ocean as a solopreneur? Reply and let me know—I read every message.

Self-hosting Listmonk: From ConvertKit to €12/month infrastructure

Meysam — Mon, 03 Nov 2025 00:00:00 +0000

Originally published at meysam.io/blog

When Medium hid subscriber counts in April 2025, I had already solved that problem six months earlier by moving my newsletter to self-hosted infrastructure. Here's how I run a newsletter for 1,500+ subscribers on a €12/month server.

On April 2025, Medium hid everyone's subscriber counts.

I wasn't surprised. I was prepared.

Because six months earlier, I'd already moved my newsletter off platforms I don't control. Not because I predicted Medium's move specifically, but because I'd learned the hard way: if you're building in public and your audience is on someone else's platform, you're building on rented land.

When Medium announced the change, I checked my email list. 1,500+ subscribers. All mine. Real email addresses I can reach directly, regardless of what any platform decides to do tomorrow.

That peace of mind? Worth the setup effort.

Why This Matters (And Why I'm Sharing This Now)

Look, I get it. Self-hosting sounds intimidating. Kubernetes sounds like overkill. "Just use ConvertKit or Buttondown," your brain says. "They're made for this."

They are. And they're great. Until they're not.

Until they change pricing.
Until they add features you don't want but have to pay for.
Until they get acquired and shut down.
Until they decide your content violates their new policies.

I'm not against using SaaS tools. I use plenty. But for your audience—the people who chose to hear from you—I believe you should own that relationship.

The calculation is simple:

Managed newsletter service: $30-100/month (and rising with subscribers)
Self-hosted Listmonk: €12/month (flat, forever, unlimited subscribers)

That's not the only reason though. It's about control. It's about data. It's about not waking up one day to find the rules changed while you weren't looking.

What You're Actually Building

Listmonk is an open-source newsletter and mailing list manager. Think Mailchimp or ConvertKit, but you run it on your own server.

What you get:

Full control of your subscriber data
Unlimited subscribers (you only pay for server costs)
No platform risk
Modern UI (actually good)
API for automation
Campaign analytics
Subscriber segmentation
Template customization

What you're giving up:

Someone else handling the servers
One-click setup
Built-in deliverability reputation (use a good SMTP service!?)
Hand-holding support

If that trade-off makes sense to you, keep reading.

Prerequisites: Are You Ready for This?

This guide assumes you:

Know what Docker/containers are (even if you've never deployed one)
Can SSH into a server without panicking
Are comfortable copying and pasting commands
Have ~2 hours to dedicate to setup
Have €12/month for hosting

You don't need:

To be a DevOps expert
To understand every line of YAML
To have Kubernetes experience (I'll explain what matters)
To know Go or VueJS (Listmonk's languages)

If you're thinking "I barely know Docker"—that's fine. I'll walk you through it. The whole point is making this accessible.

The Architecture (Without the Jargon)

Here's what we're building:

A small server (Hetzner CCX13: 2 vCPUs, 8GB RAM, €12/month)
K3s (lightweight Kubernetes—it's easier than you think)
Listmonk (your newsletter app)
PostgreSQL (database for subscribers/campaigns)
Automated backups (to Hetzner Object Storage)

Why Kubernetes for a newsletter app? Valid question.

Because once you have K3s running, adding other self-hosted tools is trivial. Want analytics? Add Plausible. Want a CRM? Add Twenty. Want uptime monitoring? Add Uptime Kuma.

It's infrastructure that scales with you, not just for this one app.

But we'll start simple.

Part 1: Get a Server Running

Step 1: Buy the Server (5 minutes)

Go to console.hetzner.cloud
Create an account (if you don't have one)
Create a new project (call it "newsletter" or whatever)
Click "Add Server"

Server specs:

Location: Choose closest to your audience (I use Nuremberg, Germany)
Image: Ubuntu 24.04
Type: CCX13 (2 vCPU, 8GB RAM, 80GB SSD)
Networking: Public IPv4 + IPv6
SSH Key: Add your public key (generate one if needed: ssh-keygen -t ed25519)
Name: newsletter-1 or similar

Cost: €12.09/month

Click "Create & Buy Now."

Wait 60 seconds. You now have a server.

Step 2: Initial Server Setup (5 minutes)

SSH into your server:

ssh root@<your-server-ip>

Update packages and set up firewall:

# Update system
apt update && apt upgrade -y

# Install required tools
apt install -y curl wget git ufw

# Configure firewall
ufw allow 22/tcp   # SSH
ufw allow 80/tcp   # HTTP
ufw allow 443/tcp  # HTTPS
ufw allow 6443/tcp # Kubernetes API
ufw enable

That's it for basic server setup.

Part 2: Install K3s (10 minutes)

K3s is Kubernetes, but stripped down to essentials. Perfect for single-server setups.

# Install K3s
curl -s https://get.k3s.io | \
  INSTALL_K3S_CHANNEL=stable \
  INSTALL_K3S_EXEC="--secrets-encryption" \
  sh -

# Verify it's running
k3s kubectl get nodes

You should see your node in "Ready" status.

Set up kubectl access (so you don't need to type k3s before every command):

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
echo "export KUBECONFIG=/etc/rancher/k3s/k3s.yaml" >> ~/.bashrc

Test it:

kubectl get nodes

If you see your node listed, K3s is running. You now have a Kubernetes cluster on a €12 server.

Part 3: Install CloudNativePG Operator (5 minutes)

We need a PostgreSQL database for Listmonk. We'll use CloudNativePG—an operator that manages PostgreSQL for us.

# Install CloudNativePG operator
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.27/releases/cnpg-1.27.1.yaml

# Wait for it to be ready
kubectl rollout status deployment \
  -n cnpg-system cnpg-controller-manager

That's it. PostgreSQL management is handled.

Part 4: Set Up External Secrets Operator (10 minutes)

We need a way to store sensitive data (database passwords, etc.) securely. We'll use AWS Systems Manager Parameter Store (it's free for our usage).

Install External Secrets Operator

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

helm install external-secrets \
  external-secrets/external-secrets \
  --namespace external-secrets \
  --version 0.20.x \
  --create-namespace

Set up AWS credentials

Create an IAM user in AWS Console with AmazonSSMReadOnlyAccess permission
Generate access keys
Create a secret in K8s:

kubectl create secret generic aws-credentials \
  --from-literal=access-key-id=YOUR_ACCESS_KEY \
  --from-literal=secret-access-key=YOUR_SECRET_KEY \
  -n external-secrets

Create a ClusterSecretStore:

---
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-parameter-store
spec:
  provider:
    aws:
      service: ParameterStore
      region: eu-central-1 # Frankfurt - change if needed
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: aws-credentials
            key: access-key-id
            namespace: external-secrets
          secretAccessKeySecretRef:
            name: aws-credentials
            key: secret-access-key
            namespace: external-secrets

kubectl apply -f ClusterSecretStore.yml

Store your secrets in AWS Parameter Store

Go to AWS Console → Systems Manager → Parameter Store and create these parameters:

/listmonk/db/username → listmonk
/listmonk/db/password → (generate strong password)
/listmonk/db/superuser/username → postgres
/listmonk/db/superuser/password → (generate strong password)

All as SecureString type.

Alternatively, use AWS CLI:

aws ssm put-parameter --name /listmonk/db/username --value "listmonk" --type SecureString --overwrite
aws ssm put-parameter --name /listmonk/db/password --value "your-strong-password" --type SecureString --overwrite
aws ssm put-parameter --name /listmonk/db/superuser/username --value "postgres" --type SecureString --overwrite
aws ssm put-parameter --name /listmonk/db/superuser/password --value "your-superuser-password" --type SecureString --overwrite

Part 5: Deploy PostgreSQL (5 minutes)

Create a namespace:

kubectl create namespace listmonk

Create the database configuration files. I'm using the exact setup I run in production—tuned for the CCX13 specs:

---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg-listmonk
  namespace: listmonk
spec:
  bootstrap:
    initdb:
      database: listmonk
      owner: listmonk
      secret:
        name: postgres-listmonk
  instances: 1
  postgresql:
    parameters:
      effective_cache_size: 6144MB
      maintenance_work_mem: 512MB
      max_connections: "100"
      shared_buffers: 2048MB
      work_mem: 16MB
  resources:
    limits:
      cpu: "2"
      memory: 8Gi
    requests:
      cpu: "1"
      memory: 4Gi
  storage:
    size: 40Gi
  superuserSecret:
    name: postgres-listmonk-superuser

---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: postgres-listmonk-superuser
  namespace: listmonk
spec:
  data:
    - remoteRef:
        key: /listmonk/db/superuser/username
      secretKey: username
    - remoteRef:
        key: /listmonk/db/superuser/password
      secretKey: password
  refreshInterval: 24h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-parameter-store
  target:
    template:
      type: kubernetes.io/basic-auth

---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: postgres-listmonk
  namespace: listmonk
spec:
  data:
    - remoteRef:
        key: /listmonk/db/username
      secretKey: username
    - remoteRef:
        key: /listmonk/db/password
      secretKey: password
  refreshInterval: 24h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-parameter-store
  target:
    template:
      type: kubernetes.io/basic-auth

Apply them:

kubectl apply -f postgres/

Wait for PostgreSQL to be ready:

kubectl wait --for=condition=Ready \
  cluster/pg-listmonk -n listmonk --timeout=5m

Part 6: Deploy Listmonk (10 minutes)

Create the Listmonk configuration:

[app]
address = "0.0.0.0:9000"
root_url = "https://newsletter.yourdomain.com"
site_name = "Your Newsletter"

[db]
host = "pg-listmonk-rw"
port = 5432
database = "listmonk"
ssl_mode = "disable"
max_open = 100
max_idle = 50
max_lifetime = "1h"
params = "application_name=listmonk"

TZ=Etc/UTC

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: listmonk
spec:
  template:
    metadata:
      labels:
        app: listmonk
    spec:
      containers:
        - envFrom:
            - configMapRef:
                name: listmonk-envs
            - secretRef:
                name: listmonk-secrets
          image: listmonk/listmonk
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 3
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5
          name: listmonk
          ports:
            - containerPort: 9000
              name: http
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 3
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5
          volumeMounts:
            - mountPath: /listmonk/uploads
              name: uploads
            - mountPath: /listmonk/config.toml
              name: listmonk-config
              subPath: config.toml
            - mountPath: /tmp
              name: tmp
      initContainers:
        - command:
            - ./listmonk
            - "--idempotent"
            - "--upgrade"
            - "--yes"
          envFrom:
            - configMapRef:
                name: listmonk-envs
            - secretRef:
                name: listmonk-secrets
          image: listmonk/listmonk
          name: migrations
          volumeMounts:
            - mountPath: /listmonk/uploads
              name: uploads
            - mountPath: /listmonk/config.toml
              name: listmonk-config
              subPath: config.toml
      volumes:
        - emptyDir: {}
          name: tmp
        - configMap:
            defaultMode: 0400
            name: listmonk-config
            optional: false
          name: listmonk-config
        - name: uploads
          persistentVolumeClaim:
            claimName: listmonk-uploads

---
apiVersion: v1
kind: Service
metadata:
  name: listmonk
  namespace: listmonk
spec:
  ports:
    - name: http
      port: 80
      targetPort: 9000
  selector:
    app: listmonk
  type: ClusterIP

---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: listmonk-secrets
  namespace: listmonk
spec:
  data:
    - remoteRef:
        key: /listmonk/db/username
      secretKey: LISTMONK_db__user
    - remoteRef:
        key: /listmonk/db/password
      secretKey: LISTMONK_db__password
  refreshInterval: 24h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-parameter-store

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: listmonk-uploads
  namespace: listmonk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    traefik.ingress.kubernetes.io/router.middlewares: default-redirect-https@kubernetescrd
  name: listmonk
spec:
  ingressClassName: traefik
  rules:
    - host: newsletter.yourdomain.com
      http:
        paths:
          - backend:
              service:
                name: listmonk
                port:
                  number: 80
            path: /
            pathType: Prefix
  tls:
    - hosts:
        - newsletter.yourdomain.com
      secretName: listmonk-tls

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yml
  - externalsecret.yml
  - ingress.yml
  - pvc.yml
  - service.yml

configMapGenerator:
  - name: listmonk-config
    files:
      - config.toml
  - name: listmonk-envs
    files:
      - configs.env

namespace: listmonk

Apply everything:

kubectl apply -k listmonk/

Wait for Listmonk to be ready:

kubectl wait --for=condition=Ready \
  pod -l app=listmonk -n listmonk --timeout=5m

Part 7: Expose Listmonk to the Internet (15 minutes)

We'll use Traefik as our ingress controller (it comes with K3s).

Install cert-manager for SSL:

kubectl apply -f \
  https://github.com/cert-manager/cert-manager/releases/download/v1.19.1/cert-manager.yaml

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - http01:
          ingress:
            class: traefik

kubectl apply -f ClusterIssuer.yml

Point your domain DNS:

Add an A record: newsletter.yourdomain.com → <your-server-ip>

Wait 5-10 minutes for DNS propagation and SSL certificate issuance.

Part 8: Access and Configure Listmonk

Navigate to https://newsletter.yourdomain.com

Username: listmonk
Password: your-strong-password (you did change this, right?)

First-time setup

Settings → General:
- Update site name
- Add your logo
- Set timezone
Settings → SMTP:
- Use a transactional email service (I recommend Maileroo)
- Or use your own mail server
- Test the configuration
Lists:
- Create your first list (e.g., "Weekly Newsletter")
- Set double opt-in (recommended for deliverability)
Templates:
- Customize the default template
- Match your brand colors

Part 9: Set Up Automated Backups (10 minutes)

Your database is the most critical part. Let's back it up to Hetzner Object Storage.

Create a bucket in Hetzner:

Go to console.hetzner.cloud
Object Storage → Create bucket
Name it (e.g., newsletter-backups)
Create access keys

Configure CloudNativePG backup:

---
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: pg-listmonk
  namespace: listmonk
spec:
  configuration:
    data:
      compression: bzip2
    destinationPath: s3://newsletter-backups/postgres/
    endpointURL: https://fsn1.your-objectstorage.com
    s3Credentials:
      accessKeyId:
        key: ACCESS_KEY_ID
        name: hetzner-blob-storage
      secretAccessKey:
        key: ACCESS_SECRET_KEY
        name: hetzner-blob-storage
    wal:
      compression: bzip2
  retentionPolicy: 7d

Create the secret:

kubectl create secret generic hetzner-blob-storage \
  --from-literal=ACCESS_KEY_ID=your-access-key \
  --from-literal=ACCESS_SECRET_KEY=your-secret-key \
  -n listmonk

---
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: pg-listmonk
  namespace: listmonk
spec:
  cluster:
    name: pg-listmonk
  immediate: true
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
  schedule: 0 0 * * * # Daily at midnight

Apply:

kubectl apply -f postgres/objectstore.yml
kubectl apply -f postgres/scheduledbackup.yml

Your database now backs up daily to object storage. If your server explodes, you can restore from these backups.

What You Just Built

Let's recap:

✅ Self-hosted newsletter platform
✅ Unlimited subscribers (only limited by server resources)
✅ PostgreSQL database with automated backups
✅ SSL certificates (auto-renewing)
✅ Modern UI for managing campaigns
✅ API for automation
✅ Full control of your data

Monthly cost: €12 for server + ~€0-5 for backups + transactional email costs (starts at ~$0.4 per 1,000 emails with Maileroo)

Compare that to ConvertKit at $33/month for 1,000 subscribers, scaling to $50/month for 3,000.

The Trade-Offs (Let's Be Honest)

What you gained:

Full ownership of subscriber data
No platform risk
Predictable costs
Unlimited scale potential
Learning experience
Infrastructure for other tools

What you gave up:

Managed infrastructure (you're responsible for updates)
Built-in deliverability reputation (you'll need to warm up your domain)
One-click features (you configure everything)
Hand-holding support (you're on your own or rely on community)

For me, it's worth it. Your mileage may vary.

If you send one newsletter a week and have 500 subscribers, maybe ConvertKit makes more sense. If you're serious about building a long-term relationship with your audience and want to minimize dependencies, this setup pays for itself.

What I Learned Doing This

Setting up Listmonk forced me to stay sharp in my Kubernetes game. That knowledge paid off immediately when I wanted to add other self-hosted tools.

Now my €12 server runs:

Listmonk (newsletter)
Plausible (analytics)
Uptime Kuma (monitoring)
A few internal tools

That same infrastructure would cost $100+/month across different SaaS providers.

The biggest lesson: Self-hosting isn't as scary as it seems. The initial setup is the hardest part. Maintenance is mostly hands-off.

I spend ~30 minutes per month on server updates. That's it.

Next Steps

If you followed this guide, you now have a running newsletter platform.

Immediate tasks:

Configure your SMTP settings (Maileroo recommended)
Import existing subscribers (if you have them)
Create your first campaign template
Send a test email
Set up a subscription form on your website

Within the first week:

Warm up your domain (start with small sends)
Monitor deliverability (check spam folders)
Create a consistent sending schedule 9. Add analytics tracking (optional)

Ongoing:

Regular server updates (apt update && apt upgrade)
Monitor backup status
Scale server as needed (upgrade CCX type if you grow)

The Real Reason I'm Sharing This

When Medium hid subscriber counts, a bunch of indie hackers panicked in my DMs.

"How do I know if anyone cares?"
"Should I just quit?"
"All my metrics disappeared."

If your entire metric system lives on someone else's platform, you're vulnerable.

I can't control what Medium does. Or X. Or LinkedIn. Or any platform.

But I can control my email list. I know exactly how many people subscribed. I can email them directly, right now, without asking permission or paying per subscriber.

That's not about paranoia. It's about sustainability.

If you're building something long-term—a product, a community, a body of work—own the relationship with your audience. Rent the amplification platforms (social media), but own the foundation (email list).

This setup is my foundation. It took a Saturday afternoon to set up. It'll run for years.

You don't have to use Kubernetes. You could run Listmonk with Docker Compose on the same Hetzner server for even less complexity. I chose K8s because I wanted room to grow.

The point isn't the specific tech stack.

The point is: stop renting your audience.

Running this setup in production? Stuck somewhere? Email me. I read every message.

Building in public? Subscribe to my newsletter where I share lessons like this every week: meysam.io

Medium Hid My Subscribers: Why You Must Own Your Audience

Meysam — Fri, 31 Oct 2025 13:53:20 +0000

Medium Just Made Your Audience Invisible

Let me tell you about the email I can't send.

I've been writing on Medium for five years. Built up a decent following—nothing spectacular, but real people who clicked that "notify me by email" button because they wanted to hear from me specifically.

Then one morning in April 2025, Medium changed the rules. Quietly. No announcement. No migration plan. Just a single line buried in their help docs:

"Email addresses are no longer shared with writers when readers subscribe to receive email notifications about stories from a writer."

Just like that, everyone who subscribed after April became invisible.

The Moment I Realized What Happened

I was setting up my own newsletter. Not to leave Medium—I still valued the platform—but to have my own channel. A backup. A direct line.

You know, like every creator is supposed to do.

I went to export my subscriber list. The one I'd spent five years building. The people who explicitly said "yes, I want to hear from you."

The export worked. I got a CSV file.

But it only had my old subscribers. Everyone from before April 2025. Everyone after? Gone. Hidden. Locked behind Medium's wall.

Not deleted. Medium still has those emails. They still use them to send my posts. They just won't let me see them.

This Isn't About Privacy

Medium's excuse? "Privacy protection."

Let me be clear: I care deeply about reader privacy. I don't want to spam people. I don't want to sell email lists. I want to communicate with people who asked to hear from me.

But here's the thing about Medium's "privacy" argument—it's bullshit.

Substack gives writers email addresses. ConvertKit does. Ghost does. Every newsletter platform that respects both readers and writers does. And they all comply with GDPR, CAN-SPAM, and every other privacy regulation.

How? By making the subscription terms clear. By requiring double opt-in. By giving readers easy unsubscribe options. By treating email as what it actually is: a communication channel with clear consent on both sides.

Medium isn't protecting reader privacy. They're protecting their own control.

They have your subscribers' emails. They use them. They send newsletters with advanced tools you can't access. They segment audiences. They optimize delivery.

You? You get nothing. Not the emails. Not the names. Not even basic metadata about who these people are or when they subscribed.

Just a subscriber count. A vanity metric. A number that goes up while your actual connection to those readers gets weaker.

The Pattern I Should Have Seen Coming

This isn't Medium's first move like this.

They killed custom domains for non-paying writers. Then they killed the Partner Program for most people. Then they made it harder to drive external traffic. Each change optimized for Medium's business model while extracting value from writers.

I justified each one. "They need to make money." "It's their platform." "They're trying to create quality."

But the subscriber email change is different. It's not about improving quality. It's not about sustainable business models.

It's about making sure you can never truly own your audience. Even when that audience explicitly chose to follow you.

What the Export File Reveals

I exported my "legacy" list—the subscribers from before April who I can still access.

The CSV file is bare bones: just email addresses, no names, no subscription dates, no context about what they're interested in or which posts brought them in.

More importantly? It came with zero documentation about consent. Under GDPR, I'm supposed to be able to prove these people opted in. Medium gives me no way to do that.

So even the emails I can export are legally questionable to use. They're compliant enough for Medium to send to, but not documented enough for me to migrate anywhere else without risk.

That's not an accident. That's by design.

The Emails I Can't Send

Here's what I can't do now:

I can't invite my subscribers to follow my journey beyond Medium. I can't tell them about projects I'm building. I can't share early access to tools I create. I can't ask them for feedback on new directions.

Not because they don't want to hear from me. But because Medium won't let me reach them directly.

Every new subscriber after April 2025 is stuck in Medium's ecosystem. They think they're following me. They're actually following Medium's curated version of me.

And if Medium changes their algorithm tomorrow? If they decide my content doesn't fit their new priorities? If they shut down?

Those subscribers disappear. Forever.

Why This Matters (Even If You're Not on Medium)

You might be thinking: "I don't write on Medium, so this doesn't affect me."

Wrong.

This is about the fundamental relationship between creators and platforms. About who owns the audience. About whether you're building a business or just renting space in someone else's.

Medium is just the latest example. Twitter locked down API access. Instagram killed chronological feeds. YouTube changed monetization requirements overnight. TikTok bans accounts without explanation.

Every platform follows the same playbook:

Make it easy to grow an audience
Wait until you're invested
Change the rules to extract more value
Justify it with vague appeals to "community" or "safety"
Watch creators scramble to adapt

The email change is Medium admitting what we should have known all along: you were never building your audience. You were building theirs.

What I'm Doing Now

I'm not leaving Medium immediately. The distribution is still valuable. The writing interface is still good. But I'm treating it differently now.

Every new post starts with a clear CTA: "I write a weekly newsletter at meysam.io. This is where I share lessons Medium won't let me talk about. Where I build in public. Where I can actually reach you if Medium changes the rules again."

I'm aggressive about moving people to my own platform: Not spammy. Not manipulative. Just honest: "If you want the unfiltered version of this journey, here's where to find it."

I'm treating Medium like what it is: A discovery platform, not a home. A place to meet readers, not keep them.

And I'm exporting everything I can while I still can. Because if Medium changed subscriber policies this quietly, what's next? When do they lock down even the legacy lists?

How I Actually Did It (The Technical Part)

Setting up my own newsletter wasn't as hard as I thought it'd be.

I'm running Listmonk—an open-source newsletter platform—on a €12/month server. It took one Saturday afternoon to set up. Now I have unlimited subscribers, full control of my data, and zero platform risk.

No monthly fees that scale with my list size. No terms of service that can change overnight. No company that can decide my subscribers are actually their subscribers.

The whole setup: PostgreSQL database, automated backups, SSL certificates, modern UI for managing campaigns. All self-hosted. All mine.

I'm writing a complete guide on how to replicate this setup—every command, every configuration file, every decision point. Not because self-hosting is the only answer, but because you should know it's possible. Because "too technical" shouldn't be the reason you stay dependent on platforms that don't have your interests at heart.

If you want to own your audience infrastructure the way I do, that guide drops next week.

It's detailed. It's tested in production. And it assumes you're smart enough to follow along even if you've never touched Kubernetes before.

For the Subscribers I Can't Reach

If you subscribed to my Medium updates after April 2025, I want you to know something:

You chose to follow my work. Not Medium's work. Mine.

But I can't reach you directly anymore. I can't tell you about projects I'm building. I can't share early access to tools. I can't ask for your feedback on new ideas.

Not because I don't want to. But because Medium won't let me.

If you're reading this on Medium right now, and you care about staying connected beyond this platform, here's what you can do: visit my website and sign up there. It takes 30 seconds. And it means I can actually reach you—on my terms, on your terms—not Medium's.

No pressure. No manipulation. Just an honest ask: if you want a direct connection, here's how.

The Lesson I'm Learning Too Late

Five years ago, when I started on Medium, someone told me: "Own your audience. Build your email list. Never rely on any single platform."

I nodded. I agreed. Then I ignored it because Medium was working and building my own platform felt like too much work.

Now I understand what they meant.

It's not that Medium is evil. It's that they have different incentives than you do. They optimize for engagement and revenue. You optimize for connection and sustainability.

Those goals aligned for a while. Now they don't.

The subscriber email change isn't a bug. It's a feature. It's Medium telling you exactly where you stand: you're valuable to them as content supply, not as an independent creator.

What You Should Do

If you're writing on Medium—or any platform you don't own—here's what I wish I'd done earlier:

Start your own newsletter today. Not next month. Not when you "have time." Today. Substack, Ghost, ConvertKit, hell even just a simple email list through your website. Doesn't matter. Just start.

Put a clear CTA in every post. Not buried at the end. Not subtle. Obvious. "I send a weekly email about [thing]. Sign up at [place]."

Be honest about why. Don't pretend you're doing readers a favor. Tell them the truth: "I'm building on platforms I don't control. If you want to stay connected regardless of what those platforms decide, here's where to find me."

Export everything you can, now. Whatever access you have to subscriber data, export it today. Back it up. Document it. Because if platforms are tightening control, assume it's going to get worse.

Treat platforms like what they are. Discovery channels. Traffic sources. Not homes. You're renting, not owning.

The Part That Hurts

I'm not mad at Medium. I'm mad at myself.

I saw the signs. I heard the warnings. I knew better.

But I got comfortable. I liked watching that subscriber count go up. I liked the validation of "X people want to hear from you."

I just didn't realize that "X people" wasn't mine. It was Medium's. And when they decided to stop sharing, I had no recourse.

Zero customers taught me that distribution matters more than product.

Hidden subscribers taught me that audience access matters more than audience size.

Both lessons cost me months of work. Both are obvious in hindsight.

I'm sharing this now because someone reading this is making the same mistake I made. You're building on a platform. You're comfortable. It's working.

Until it isn't.

And by the time you realize you should have owned your audience, it's too late to export the emails they hid.

If you subscribed to my Medium updates after April 2025 and you're reading this, I genuinely wish I could reach you directly. If you want to stay connected beyond Medium's decisions, visit meysam.io. That's the only place I can actually promise you'll hear from me.

Everyone else: learn from my mistake. Own your audience. Today.