Coder Legion - Recent posts tagged indiehacker

How I Built a Telegram Habit-Tracker Bot with No Programming Experience

Mon, 21 Sep 2026 12:26:13 +0000

Hi everyone!

This is my first post here. I am writing not for experienced developers, but for those who want to gain their first programming experience using AI models.

Here is how it went for me.

Recently, I had no idea about programming and had never built Telegram bots. Three months ago, as an experiment, I started "vibe coding," and now I have a working Telegram bot with several thousand lines of code, modules for selecting and saving time, passwords, a database, payment processing, 10 languages, and chart generation. You can launch the bot at https://telegram.me/I_promise_myself_bot (click the "Try free & Unlock" button).

I want to share my experience—how I used several different LLMs in a regular free chat, how I bypassed limits, and how I got out of dead ends when the AIs completely stalled, forgot context, and the bot started breaking.

Where It All Started

Like everyone else, I started with ChatGPT, then tried Grok, Mistral, Gemini, Qwen, and DeepSeek bit by bit. I wanted to figure out through trial and error what each could do and for how long. I quickly ran into token limits in free chats. Also, over long distances, they lose context at different times, start mixing up file structures, and produce non-working pieces of code.

As long as there were 200-300 lines of code, working with AIs was manageable, but when the code exceeded 1,000 lines, the problems began. To overcome bottlenecks, I couldn't paste or upload such an amount of code into the window for the AI to see the whole code, find the exact error, or add a new feature.

Another problem was that any AI, as a rule, forgets the conversation after a few hours or starts hallucinating heavily. After that, you have to kill the chat and create a new one, re-supplying the new chat with the general task, snippets of chat history and code, and almost the entire conversation so it understands what I want from it. I regularly read bloggers, and regarding this, I asked Kostya Doronin for advice on how to work with AIs when code accumulates to more than 1,000 lines across multiple files. Surprisingly, he readily suggested several free and paid workarounds, but I managed with free ones only. I fundamentally wanted to figure out if it's possible to make something working with AIs for free.

I had to change my approach a bit. First, I roughly figured out what can be squeezed out of this or that AI, when they start glitching, and how to bypass it. I stopped loading one AI with all tasks at once and started dividing tasks among models.

I settled on these:

1.Claude is the architect. It has the best logic and understanding of the general code and project structure. I used it for brainstorming and design, modularizing, and creating step-by-step instructions for other AIs. Also as a "rescuer" in dead-end situations when another AI started leading me in circles. The only downside is that free tokens run out very quickly, and you have to wait a few hours.
2.Qwen turned out to be the main "workhorse" over long distances. If you give it a detailed plan from Claude, Qwen handles it well and sticks to the plan. Claude has strict limits on free messages, but with Qwen, you could code all day long in the same chat, solving tasks one step at a time. It holds up for about 7 days before hallucinations begin, after which you need to kill the chat and start a new one.
3.Gemini is an additional tool for quickly double-checking individual pieces of code, like a "fresh perspective" on a problem or a new task. But in the free version, it is not particularly good at programming and architecture, and if you work with it for a whole day or two, it also starts hallucinating. Although there were periods when these same models worked for weeks without any hallucinations at all. And sometimes a day was enough for both Qwen and Gemini to start glitching, which I never encountered with Claude. Probably because it ran out quickly! From which I concluded that model owners for some reason release different quality versions of the same model into the wild.

In other words, all these LLMs are a very unreliable thing, and for serious projects, you should only work with people. But as assistants in simple coding tasks, they are very good.

Project Architecture

At the beginning of creating the bot, Claude guided me step-by-step to download and set up all these tools on my computer:

•Language and framework: Python 3.11+, aiogram 3.x.
•Database: Started with simple Google Sheets, but eventually switched to PostgreSQL, hosted on Supabase. Mistake: should have used PostgreSQL from the very beginning.
•Background tasks: APScheduler for push notifications.
•Graphics: matplotlib for reports.
•Payments: Paddle SDK integration.
•Localization: Multilingual system based on JSON (languages). Mistake: did it at the very end, but should have done it at the very beginning because I had to redo a lot of things.
•Security: Isolating tokens in a separate file.

Development Process

For each new bot feature, I tasked Claude with developing as detailed a step-by-step instruction plan for Qwen as possible. I coded in VS Code, but didn't use LLMs inside it directly, only in chats:

1.I initially split the entire project into logical modules: there is one main file up to 2,000 lines, and the rest are 200-700 lines. Everything is separate – handlers, database operations, notifications, buttons, and localization.
2.Working with Qwen: Before any changes, I saved all recent files with working code in a separate folder so I could easily roll back. I gave Qwen a step-by-step plan and changed or added functionality step by step. I inserted it into the project, ran the bot, and checked the operation and logs. If there was a problem, I gave the logs to all three AIs at once to find the issue. If the problem hit a dead end, I started over from the last working code, but mentioned in the task to Claude (if tokens remained) that there were such-and-such problems during the previous change and they needed to be avoided. If Claude was exhausted, I asked Gemini. And so I moved step by step.

How I Got Out of Dead Ends

Somewhere in the middle of the project, the code exceeded a thousand lines, and problems began: the AI forgot the context and broke what was already working when trying to fix a bug.

At that moment, I brought in Claude:

1.I described the essence of the technical problem and the bot's startup logs in VS Code.
2.I provided snippets of chat history where Qwen started going in circles.
3.I attached the problematic code.

Mostly, Claude found the error on the first try and provided a solution. If it didn't know, it asked leading questions and we ran additional checks. Unlike Qwen or Gemini, which immediately "poured out" a bunch of possible causes after which going in infinite circles began. In especially neglected cases, I "pitted models against each other": I drove the problematic piece in circles between Claude, Gemini, and Qwen until one of them found the bug. Their collective intelligence works much more reliably.

Conclusions

After a few months of casual work, I got a working Telegram bot with several thousand lines of code, written from scratch with no experience.

What I realized for myself:

1.On simple tasks, AI replaces a team, but you need to understand the project structure well yourself and at least superficially understand the code. If you have no knowledge, you can learn to think systemically and architecturally on such projects.
2.Use different models. Using a single AI for everything is undesirable. The "architect + coder + fresh perspective" bundle works better.
3.Small steps. Wrote a function – tested it. Broke – rolled back to the last working version.
4.Save chat history. Chat history with AI helps you not to lose the logic of the project yourself after a week or month of work, and to provide context to another AI for problem analysis.

I will be glad to answer questions in the comments!

InviteVia – Digital Invitation Maker

Wed, 09 Sep 2026 11:12:54 +0000

The Story Behind InviteVia

As a software developer, I had already built plenty of applications where the main goal was learning a technology, testing an idea, or adding something to a portfolio. But this time I wanted to take a different approach. I wanted to build a real product from scratch, put it on the internet, find real users, and deal with the problems that come with running an actual product.

That is how InviteVia started.

The idea was to make digital invitations much simpler. Traditional invitations often require creating designs, sending files, managing responses manually, and constantly asking people whether they are coming. I thought the experience could be much more straightforward.

With InviteVia, a host can create an invitation, add the event details, publish it, and share a single link. Guests can open the invitation and RSVP without creating an account or downloading an application.

Building the MVP

I built InviteVia as a solo developer, which meant that I had to think about much more than writing the frontend.

The application is built with Next.js and TypeScript. I use Supabase and PostgreSQL for the backend and data layer, while Vercel handles deployment.

One of the first things I focused on was keeping the invitation creation process extremely simple. The goal was that someone should be able to go from an empty page to a shareable invitation in just a few minutes.

The basic flow became straightforward: choose a template, enter the event information, customize the invitation, publish it, and share the generated link.

The interesting part came after the invitation was created.

I didn't want guests to have to register just to respond to an invitation. So I designed the RSVP system around the guest rather than the account system. A guest can open the invitation, provide their response, and submit it without creating an account.

That small decision made the product considerably simpler to use.

Solving Problems That Don't Appear in Tutorials

Building the first version was actually the easy part.

Once InviteVia became a real product, I started running into problems that you don't normally encounter when building a tutorial project.

I had to think about SEO, multilingual URLs, Open Graph previews, performance, accessibility, error handling, database design, deployment, analytics, payments, and how the application behaves when real people use it.

One particularly important problem was how invitations should appear when shared on platforms such as WhatsApp, Instagram, or other social platforms.

A normal web page is not enough for this. I wanted every invitation to have a proper preview containing the event information and visual design.

I implemented dynamic Open Graph image generation using Vercel OG so that invitation links could generate their own preview images dynamically.

This turned out to be one of the more interesting technical parts of the project because the application wasn't simply generating HTML anymore. It was generating a visual representation of dynamically created user content that could then be consumed by external platforms.

Building for a Global Audience

Another challenge was internationalization.

InviteVia wasn't designed specifically for one country. I wanted the platform to be usable by people around the world, so the application currently supports 19 languages.

That introduced another layer of engineering problems.

Routes, metadata, headings, translations, dates, invitation content, SEO, and user-facing messages all had to work correctly across different languages without duplicating the application logic.

This also made me realize that building a global product is very different from simply adding a language selector to a website.

From Developer Project to Real Product

At some point, InviteVia stopped feeling like a side project.

There was a real domain, real deployments, real analytics, real payment infrastructure, SEO issues to solve, and eventually the question that every indie developer has to face:

Will anyone actually use this?

That question changed how I approached development.

Instead of continuously adding features, I started paying more attention to friction. How quickly can someone create an invitation? How quickly can a guest understand what they need to do? Does the invitation load properly when shared? Does the page work on mobile? Can someone RSVP without thinking about the technology behind it?

The product became less about the technologies I was using and more about hiding those technologies from the user.

That is probably the biggest lesson I have learned while building InviteVia.

What InviteVia Does Today

InviteVia allows people to create digital invitations for weddings, birthdays, engagements, parties, and other celebrations.

A host can choose a template, add their event details, publish the invitation, and share it through a single link.

Guests can view the invitation and RSVP without creating an account or installing an application. Hosts can then see their guest responses and manage their event from a dashboard.

The platform also supports multiple languages, dynamic invitation previews, RSVP tracking, calendar and map-related functionality, and a free-to-use entry point with optional premium features.

The technical stack is intentionally modern but relatively simple: Next.js, TypeScript, Supabase/PostgreSQL, Vercel, and Vercel OG.

What I Learned

The biggest lesson wasn't about Next.js, Supabase, or any individual technology.

It was learning what happens when a project leaves the development environment.

A portfolio project can work perfectly with ten test users. A real product has to deal with unexpected input, SEO crawlers, social media previews, different languages, slow connections, payment flows, accessibility, broken URLs, database edge cases, and users doing things you never expected.

InviteVia has been my way of learning that process by actually experiencing it.

I'm still developing the product, fixing problems, experimenting with acquisition channels, improving the user experience, and trying to understand what people actually need rather than assuming I already know.

What's Next

InviteVia is actively maintained and continues to evolve.

My goal isn't to turn it into a huge platform with hundreds of unnecessary features. I want to keep the core experience simple: creating an invitation should be fast, sharing it should be effortless, and responding to it should require almost no effort from the guest.

For me, InviteVia is also an ongoing experiment in building and operating a real software product as a developer.

If you're interested in the technical side of the project, I'd be happy to discuss the architecture, implementation decisions, SEO challenges, internationalization, or the lessons I've learned while taking it from an idea to a live product.

You can see the product here: InviteVia

You Are Not Selling Your Code. You Are Selling the Next Commit

Tue, 08 Sep 2026 11:35:30 +0000

I spent the last few weeks reading the documentation, pricing pages and source of every tool I could find that sells access to a private GitHub repo. I expected the comparison to come down to features. It came down to one sentence in GitHub's own docs, and after that the shopping list looked completely different.

Here is the sentence, from the page on removing an outside collaborator: "While forks of private repositories are deleted when a collaborator is removed, the person will still retain any local clones of your repository." The next line tells you the rest of the job is yours - you are responsible for making sure the people who lost access delete what they copied.

A git clone takes ten seconds. No API call reaches it. So whatever you were told about protecting your source, the plain version is this: the only thing a refund can take back is the future.

Revocation is a subscription feature, not a security feature

Once you accept that, the whole category re-sorts itself. Revocation is not there to protect your code. It is there to keep a refunded buyer or a charged-back card away from the next tag, the fixed bug, the private issue tracker, the room where the other buyers talk.

That is a boring plumbing job, and boring plumbing is exactly what you should be shopping for. It also explains the refund policies of the people already doing this at scale: several of the big commercial boilerplates simply say access, once redeemed, is not returnable. The one I found with a proper no-questions window ships a generated download rather than repo access. A refund window is cheap when the product is a snapshot.

There is a pricing consequence hiding in there too. If you sell yearly access and your tool cannot revoke on its own, you are selling lifetime access at a yearly price, whatever the checkout page says.

Three things decide this before any tool does

GitHub's own rules come first. A repo under a personal account can only take collaborator invites; team-based delivery needs an organization. Organizations on a paid plan bill per seat, and a pending invitation is already a seat. Half the tools out there work one way, half the other, and that single fact eliminates most of the list before you have compared a single feature.

Then the invitation itself, which is where sellers actually lose money. GitHub emails the invite to the buyer's primary address, not the address they paid with, and it expires after seven days. There is no page on GitHub where a buyer can see invitations waiting for them - the community request for one was opened in 2018 and people were still adding "any update?" to the thread last year.

So your real timeline is: payment, an email into an inbox you do not control, six days of silence, expiry, a 404 that reads to the buyer as "I paid and got nothing", and a support ticket on day eight. Exactly one tool I looked at treats that as its own problem and re-issues before the deadline. Every other tool, and every tutorial script, leaves you as the retry mechanism.

Then geography and who is merchant of record. Stripe's availability page lists 51 countries and regions, and seven carry an asterisk: India and Indonesia in preview, five African countries handed to Paystack. That leaves 44 where you simply sign up, against 193 UN members. If you are outside that list, the entire "just connect Stripe" branch is closed to you and the question becomes which merchant of record will take you. If you are inside it, you get to choose whether the sales tax work is yours or somebody else's, and that choice costs a few points per sale.

Every option that exists, in one breath

Hosted, nothing to run: Polar has repo access as a built-in benefit, Dodo Payments is the newest merchant of record with a GitHub entitlement, and GitHub Sponsors will do sponsors-only repos at zero percent if monthly billing and an open-source-companion shape fit you.

Storefronts where you stay the merchant: BuyMyRepo, GitPaywall, Anystack. Crypto checkout with tarballs instead of invites: gitbuyer.

Payment platforms with no GitHub feature at all, where you bring your own glue: Gumroad, Lemon Squeezy, Whop, Patreon, Ko-fi, Buy Me a Coffee. The glue is usually Zapier, Make or n8n, and the recipes you will find online reliably cover the invite and quietly skip the revoke.

Self-hosted: Honorbox, Pay2Clone, SellRepo, Lemonrepo, and RepoAccess, which is mine - I will come back to that. Plus a long tail of $7 and $20 scripts and tutorials, which is where most sellers actually start.

And the option nobody frames as an option: skip repo access entirely. Ship a zip behind a license key. If your product is a snapshot rather than a stream of updates, the whole invite lifecycle is a cost with no benefit.

Where the tool sits	Examples	Revokes without you
Hosted, built-in GitHub delivery	Polar, Dodo Payments, GitHub Sponsors	Mostly yes
Self-hosted	Honorbox, Pay2Clone, SellRepo, Lemonrepo, RepoAccess	Depends, and the differences are large
Platform plus glue	Gumroad, Lemon Squeezy, Whop and friends, wired with Zapier or n8n	Usually no

Mine has a gap, and here it is

I built one of these. RepoAccess grants a GitHub team invite when a payment webhook arrives and removes it on refunds and chargebacks, and it runs as a single Cloudflare Worker on your own account.

It does not re-issue an invitation before the seven-day expiry. Honorbox does, at day six, up to three times, reading GitHub's own expiry flag rather than trusting a calendar. That is a real gap, I am naming it in my own comparison rather than hiding it, and it is on my list.

The two-minute test

Whatever you end up choosing, do this before your first sale: issue a refund in test mode, then open your organization's People page.

If the buyer is still sitting there, the tool you bought is a granting tool, and the revoking is you.

The long version - every tool with its actual behaviour, the fee table, what a month of twenty sales costs on each path, and six questions that each end in a name - is here: How to Sell Access to a Private GitHub Repo: Every Option Compared

A $1 market for side projects – first 100 listings free

Sun, 06 Sep 2026 14:45:32 +0000

Hey everyone,

I'm running a small experiment called AgentShare Market.

The idea is dead simple: you list your web app, tool, or API for $1. People browse. If someone wants it, they reach out. That's it.

No chat, no escrow, no promises. Just a board for the curious.

Why?
I've noticed a lot of vibe coders and indie makers building cool stuff but struggling to get any traction. This is a low-friction way to put your project out there and see if anyone bites.

First 100 listings are FREE to test the waters.

If you've got a side project collecting dust, give it a shot: https://agentshare.dev/market

Would you ever buy or sell a side project? Curious to hear your thoughts.

The Missing Freelance Time Tracker

Sat, 01 Aug 2026 10:02:43 +0000

The Missing Freelance Time Tracker

It has a name now: MelaFreelance. Here's what it is, and why it's yours — not mine.

In the last piece I explained the itch: every time tracker I tried was built for teams, and I'm one person with a client, a project, and a clock. So I stopped renting other people's tools and built the small one I actually needed.

This is that tool. It's called MelaFreelance, and this is what it turned out to be.

Built one summer, polished the next

The first commit landed in August 2025, in the slow, warm gap where the client emails thin out and there's finally room to make the thing you keep meaning to make. It wasn't pretty. It had no options, no settings, no polish — just the raw mechanics I needed to answer who owes me what. And then I did the most honest test there is: I used it. Every day, for a straight year, exactly as it was.

A year of real use is a brutally good editor. It tells you which features you invented and never touch, and which rough edges you step over so often you stopped noticing. Nothing survives that a design doc would have kept, and nothing gets cut that you actually reach for.

So here we are, another August, the same quiet slice of the calendar — and this time the work isn't building it, it's finishing it. The polish it earned by proving, over twelve months, that it deserved to exist.

There's a second reason the timing is right. Lately I've been deep in a much heavier project — S-MoE, a sparse mixture-of-experts build that lives in exactly the kind of complexity you can't hold in your head on a hot afternoon. After enough of that, coming back to MelaFreelance feels like stepping out of a machine room into the sun. Small surface, clear edges, an obvious right answer for every question. Simple work — but not unimportant work. Sometimes the most useful thing you can build is the one you can finish.

It's yours, not mine

Here's the decision that shapes everything else: MelaFreelance isn't a service you sign up for. It's a thing you run.

There's no account on my server, no subscription, no "free tier" quietly counting your clients until it asks for a card. You clone it, you point it at your own database, and it's yours — data and all. If I vanish tomorrow, your tool keeps working, because it was never on a server I control.

That's not an accident, it's the whole philosophy. The tools that broke me in the first place all had one thing in common: my data lived in their product, on their terms, one pricing-page change away from held hostage. A tracker for freelancers should be the one piece of software a freelancer never has to worry about losing.

So it's single-user by default — no seats, no invites, no "workspace." One person clones it, runs one command to create their account, and starts working. Everything about it assumes you are the only human who will ever log in, because for me, that's the truth.

The timer that's always there

The most-used thing in a time tracker is the start/stop button, so I refused to bury it.

In MelaFreelance the running timer isn't a widget you navigate to — it lives in the app's chrome, on every page. Wherever you are, you can see what's ticking and stop it. And there's exactly one rule the app enforces for you, quietly: you can only run one timer at a time. Start a task while another is running and the old one banks its minutes and stops on its own. A freelancer works one thing at a time; the tool should never let two clocks claim the same minute.

When you stop, the bar doesn't just disappear. It remembers the last thing you were on — "was I still on the Rossi homepage?" — with a one-click Resume, until you dismiss it. Small thing. I use it twenty times a day.

The number that matters

Open the app and the first thing it tells you is the number I actually came for: what am I owed, and what's still outstanding?

Not tracked hours dressed up as money. Not an invoice-count vanity stat. Just: across every project, how much has been paid, and how much is still out there. Because payments in MelaFreelance are a ledger, not a checkbox — a deposit, a milestone, a final balance — "paid" and "outstanding" are simply the arithmetic on that ledger. And the arithmetic is done once, on the backend, in whole cents, so the number on your dashboard is the number, every time. No rounding drift, no two screens disagreeing.

Money can be windowed — received this month — because every payment carries a date. Hours are all-time, on purpose: a task holds one running total, not a pile of dated entries I'd have to maintain. That asymmetry is a feature. It's the difference between a tool that answers your question and a tool that invents new ones to justify itself.

Still small on purpose

I've added things since launch — a gentle nudge to mark a project done when its last task finishes, a proper time picker, non-billable projects for the client called "Myself." But the rule hasn't changed: nothing ships unless I hit the need for it in my own week.

That's the luxury of building for exactly one user. There's no roadmap to defend, no enterprise deal bending the design, no feature added to win a comparison chart. When something annoys me, I fix it. When something's missing, I add it. When it's fine, I leave it alone — which is most of the time, and exactly the point.

MelaFreelance is free, it's open, and it's built to be cloned. If you're a freelancer who's tired of renting the basics, you don't have to wait for me to build your features. You can take it and make it the tool you needed all along.

That was always the missing one. Built in one summer, quietly proven through a year of real work, and finished in the next. If a tool can earn that, it's earned a place on your machine too.

MelaFreelance — built by a freelancer, for freelancers. Clone it, own it, get back to the work.

How to persist landing page attribution across OAuth redirects (30 lines of middleware)

Thu, 28 May 2026 15:54:27 +0000

Landing page attribution breaks the moment a user hits an OAuth flow.

Here's the scenario: you're running ads to multiple landing pages — one angle about speed, one about voice matching, one generic. All getting clicks. But by the time a visitor completes signup through Google OAuth or Twitter OAuth, the original URL params are gone. You see a new user in your database. You have no idea which LP or which copy variant sent them.

The solution is straightforward once you see it:

On first page load, write the landing page path + A/B variant to a cookie — before any auth redirect happens
On account creation (server-side), read that cookie back and persist both fields on the user record
The cookie survives OAuth round-trips regardless of which auth method they use

// middleware.ts — runs on first page load
if (request.nextUrl.pathname.startsWith('/lp/')) {
  response.cookies.set('signup_landing_page', request.nextUrl.pathname, { maxAge: 3600 })
  response.cookies.set('ab_variant', getVariantFromCookie(request), { maxAge: 3600 })
}

# users_controller.rb — on account creation
user.signup_landing_page = cookies[:signup_landing_page]
user.ab_variant = cookies[:ab_variant]

Why not just use GA4?

GA4 session attribution and database-level user attribution tell different stories when auth redirects are involved. GA4 may correctly attribute the session to the landing page — but if you want to segment your actual converted users by which LP they came from (to measure LTV, churn rate, or feature adoption by cohort), you need it on the user record.

Now every new signup in XreplyAI carries signup_landing_page and ab_variant. First week of data is already changing where ad spend goes.

About 30 lines of middleware total. Worth the afternoon.

Built for XreplyAI — AI social media tool for solo founders.

The building-in-public system that actually stuck (after failing every "just be consistent"

Tue, 26 May 2026 16:00:17 +0000

I spent the first year of my product treating social media like something I'd get to eventually. Posted sporadically, disappeared during crunch, felt guilty about it constantly.

Here's the system that finally stuck — and it works because it makes content a byproduct of building, not a separate job:

Keep a decision log.
Every real product decision gets one sentence: why did I do this. Not a post. Just a log. 30 seconds. This becomes the content backlog.
One post per week from the log.
Pick the decision that felt most uncertain at the time. Those are always the most honest posts. Honest posts outperform polished ones in every community I've tried.
Replies are reactions, not performances.
Stop trying to write the perfect reply. React genuinely, add one observation the person might not have considered, move on. 30 seconds per reply. It compounds.

The last piece was fixing the AI problem. Generic prompts made everything sound the same. Switched to training on my own tweet archive — replies actually sound like me now. I built this into XreplyAI as a BYOK tool — you connect your own Gemini or OpenAI key and pay the provider directly

Curious what systems other solo builders have landed on. Especially anything that makes replies less of a time sink.

We A/B tested value-first onboarding (generate before subscribe) — here is what happened

Tue, 12 May 2026 13:25:23 +0000

We've been running an A/B test on our onboarding flow and the early results are interesting enough to write up.

The old sequence

Voice setup → connect account → subscribe → generate posts. Classic SaaS — get commitment early, then show value.

The problem: users were dropping at the subscribe step having never seen a single piece of output. They were being asked to pay for something they'd only read about.

The value-first sequence

Pick topics → generate 5 posts in your voice → review them → THEN connect and subscribe.

By the time they hit the paywall, they've already seen their content calendar for next week. Drop-off on the subscribe step is lower. Makes sense — it's a lot easier to say yes to a tool when you're already holding the output.

Why it works

The subscribe step isn't a commitment to something abstract anymore. It's "do you want to keep the posts you just made?" That's a very different ask.

The implementation details

A few things worth noting if you're building something similar:

We run the sequence via a PostHog feature flag (onboarding-v2, variant value-first) — easy to roll back or adjust the split without a deploy
The full-tab onboarding (not a popup) was intentional — popups close if you click away, which kills any flow that involves a file upload or multi-step form
Preferences sync locally first (chrome.storage), then backend — so the extension is usable even if the API is temporarily unreachable

Full breakdown of both sequences and the design decisions behind each step: https://xreplyai.com/blog/xreplyai-onboarding-wizard?utm_source=devto&utm_medium=social&utm_campaign=blog-2026-05-12

Best AI Tools for Social Media in 2026 (Ranked and Reviewed)

Mon, 11 May 2026 20:00:09 +0000

AI has changed how people manage social media — but not all tools are doing it the same way. Some generate generic templates. Some are X-only. Some charge $99/mo for features you can get elsewhere for $19. This is an honest breakdown of the best AI social media tools in 2026, ranked by use case.

Before comparing tools, it helps to know what actually matters. Most AI social media tools do one or more of these things:

Draft content — generate posts from a topic or prompt
Schedule and publish — queue posts across platforms on a calendar
Generate replies — draft responses to comments and mentions
Voice matching — learn your tone so content sounds like you, not a template
Analytics — track what performs and why

No single tool does all of these equally well. The right choice depends on which combination matters most for your situation.

1 XreplyAI — Best for solo founders and creators who want AI that sounds like them

Platforms: X, LinkedIn, Instagram, Threads, YouTube, Pinterest, Bluesky, TikTok

Pricing: Pro $49.99/mo · BYOK from $19/mo · 7-day free trial

Pros:

Voice profile trained on your own posts — drafts sound like you wrote them
BYOK plan: pay your AI provider directly, no markup
AI reply generation + scheduling in one tool
8 platforms with per-platform formatting
MCP integration for power users

Cons:

Newer product — smaller community than legacy tools
No native analytics dashboard yet

Best for: Solo founders building in public, creators who post on multiple platforms, anyone tired of generic AI content

2 Typefully — Best for X/Twitter and LinkedIn writers who want a clean writing experience

Platforms: X, LinkedIn

Pricing: Free plan available · Pro from $29/mo

Pros:

Best-in-class thread composer for X
Clean, distraction-free writing UI
AI writing assist built in
Good LinkedIn scheduling

Cons:

Only 2 platforms (X and LinkedIn)
No voice matching or training on your past posts
No reply generation

Best for: Writers and thought leaders focused on X and LinkedIn

3 Hypefury — Best for X-focused creators who want automation and engagement tools

Platforms: X (primary), Instagram

Pricing: From $65/mo

Pros:

Auto-retweet, auto-plug, auto-DM features
Engagement automation built in
Strong X-native feature set
Good inspiration feed

Cons:

Expensive at $65/mo
Primarily X-focused — limited multi-platform support
AI content is template-based, not voice-trained

Best for: X power users who want engagement automation

4 Tweet Hunter — Best for X creators who want analytics and a content library

Platforms: X

Pricing: From $49/mo

Pros:

Large library of high-performing tweet examples
Good tweet analytics
AI tweet generation with examples
Engagement features

Cons:

X-only
Expensive for what you get vs newer alternatives
No voice matching

Best for: X creators focused on growth with data-driven content decisions

5 Buffer — Best for teams and agencies who need simple multi-platform scheduling

Platforms: X, LinkedIn, Instagram, Facebook, Pinterest, TikTok, YouTube, Mastodon

Pricing: Free plan · Essentials from $6/mo per channel

Pros:

Free plan available
Excellent multi-platform scheduling
Clean team collaboration tools
AI assistant for post drafting

Cons:

AI is generic — no voice training
No reply generation
Per-channel pricing adds up for many platforms

Best for: Teams and agencies who need reliable scheduling across many platforms

6 Taplio — Best for LinkedIn-only creators who want AI content and CRM features

Platforms: LinkedIn only

Pricing: From $49/mo

Pros:

LinkedIn-native AI content generation
Built-in LinkedIn CRM and lead tracking
Good content inspiration from viral posts
Carousel and document post support

Cons:

LinkedIn only
Expensive for a single-platform tool
No voice matching

Best for: LinkedIn-focused B2B founders and consultants

The BYOK difference

One thing worth understanding before you pick a tool: most AI social media tools are charging you a markup on AI. You pay $49–99/mo, and part of that covers their Gemini or ChatGPT API costs. The tool bundles the AI in so you don't have to think about it — but you also can't see what you're actually paying for AI vs the software.

XreplyAI is the only major tool with a BYOK (Bring Your Own Key) plan. You connect your own Gemini or ChatGPT API key, pay the AI provider directly, and the actual AI cost for most solo founders is $1–5/mo. The tool costs $19/mo. Total: roughly $20–24/mo vs $49–99/mo elsewhere.

Whether that matters depends on how much you use AI generation. If you're generating a lot of content daily, the savings compound quickly. If you use the AI occasionally, the difference is smaller.

How to choose

If you want...	Use
AI that sounds like you across 8 platforms	XreplyAI
Best X/Twitter thread writing experience	Typefully
X engagement automation (auto-RT, auto-DM)	Hypefury
Data-driven X growth with content library	Tweet Hunter
Team scheduling across many platforms	Buffer
LinkedIn-only content + CRM	Taplio

FAQ

It depends on your use case. For solo founders and creators who want voice-matched content across multiple platforms, XreplyAI is the strongest option. For pure scheduling, Buffer. For LinkedIn, Taplio. For X-focused growth, Hypefury or Tweet Hunter.

What is BYOK and why does it matter?

BYOK (Bring Your Own Key) means you connect your own AI API key instead of paying the tool's markup. With BYOK, you pay the AI provider directly — often $1–5/mo in actual usage — instead of $49–99/mo to the tool. XreplyAI is the only major social media tool with a BYOK plan.

Most generate generic content from a prompt. XreplyAI trains on your own past posts to learn your tone, vocabulary, and sentence structure so drafts sound like you, not a template.

XreplyAI supports 8 platforms. Buffer supports most major platforms. Typefully covers X and LinkedIn. Hypefury is X-focused. Taplio is LinkedIn-only.

Most offer free trials rather than permanent free tiers. XreplyAI has a 7-day free trial and a BYOK plan from $19/mo. Buffer has a free plan with limited scheduling. Most others are paid-only with trials.

Originally published at xreplyai.com.

Coder Legion - Recent posts tagged indiehacker

How I Built a Telegram Habit-Tracker Bot with No Programming Experience

InviteVia – Digital Invitation Maker

The Story Behind InviteVia

Building the MVP

Solving Problems That Don't Appear in Tutorials

Building for a Global Audience

From Developer Project to Real Product

What InviteVia Does Today

What I Learned

What's Next

You Are Not Selling Your Code. You Are Selling the Next Commit

Revocation is a subscription feature, not a security feature

Three things decide this before any tool does

Every option that exists, in one breath

Mine has a gap, and here it is

The two-minute test

A $1 market for side projects – first 100 listings free

The Missing Freelance Time Tracker

The Missing Freelance Time Tracker

Built one summer, polished the next

It's yours, not mine

The timer that's always there

The number that matters

Still small on purpose

How to persist landing page attribution across OAuth redirects (30 lines of middleware)

The fix: cookie before redirect

Why not just use GA4?

The building-in-public system that actually stuck (after failing every "just be consistent"

We A/B tested value-first onboarding (generate before subscribe) — here is what happened

The old sequence

The value-first sequence

Why it works

The implementation details

Best AI Tools for Social Media in 2026 (Ranked and Reviewed)

What to look for in an AI social media tool

The best AI social media tools in 2026

1 XreplyAI — Best for solo founders and creators who want AI that sounds like them

2 Typefully — Best for X/Twitter and LinkedIn writers who want a clean writing experience

3 Hypefury — Best for X-focused creators who want automation and engagement tools

4 Tweet Hunter — Best for X creators who want analytics and a content library

5 Buffer — Best for teams and agencies who need simple multi-platform scheduling

6 Taplio — Best for LinkedIn-only creators who want AI content and CRM features

The BYOK difference

How to choose

FAQ

What is the best AI tool for social media in 2026?

What is BYOK and why does it matter?

Can AI social media tools write in my voice?

Which AI social media tools work for multiple platforms?

Are there free AI social media tools?