I vibe coded a LinkedIn outreach automation tool from scratch, and made ~$2k in the first month 🫨

It started out as a random idea I had when talking to Claude, and I had no idea I could even build it, but I gave myself no choice.

Last year I decided to register a business, even though all I had was the website and a dream.

That way I felt forced to actually create the LinkedIn automation tool itself, simply for legal/taxation reasons if nothing else.

I knew I had a unique idea as the tool itself automates via a browser, instead of automating via the cloud or with a plugin, making it significantly safer when it comes to possible LinkedIn suspensions from automating.

I had no idea what I was doing at first and it was super buggy for a while, but over time I learned step by step and through trial and error how to build (mostly) effectively with Claude and how to build on top of LinkedIn’s code too (which is extremely challenging).

I was confident enough in the tool to launch it on April 1, and a month later I’m almost at 100 users. Most of them are on free trials but so far I made $2k from paying customers, which covered the costs of actually building the platform and then some.

It took a few months of 12 hour days and late nights but now it feels like it’s finally starting to pay off.

Hope I can inspire anyone else starting out to just keep going with whatever you’re doing/building 🚀

Hi everyone,

I’d love to hear about your startups. Drop a link + a few words about what you are building.

I am building StartupLibrary, and if you have not already, submit your startup to www.startuplibrary.net for a chance to be featured in our weekly newsletter.

Currently we are one of the fastest growing directories, and let’s keep the momentum going this week 🚀

Hey everyone,

Almost 2 months ago I launched a completely free personal finance app after getting frustrated with how hard it was to clearly track where my money was actually going.

A lot of banking apps automatically categorize transactions, but many times the categories just don’t really make sense for your own life, and after a while the data becomes messy and not very useful. I also wanted something that made managing multiple accounts easier without everything feeling disconnected or confusing.

So I started building something simpler and more flexible where you can organize transactions the way you actually think about your money.

Since the last time I posted here, the app somehow grew to 624 users, which honestly I never expected. I genuinely didn’t think we would get this close to 1000 users this fast, so thank you to everyone that tried it and gave feedback.

Recently I added iOS widget support, which was one of the most requested features.

The widget shows your most frequently used categories and when you tap one of them, the app opens directly into the add transaction screen with that category already selected.

The goal was basically to reduce as much friction as possible when adding transactions so expense tracking becomes something you can do in a few seconds instead of feeling annoying.

I also started working on an AI assistant inside the app.

You can use your own API key and ask questions about your finances and transactions, things like:

• “How much money did I spend on food last week?”
• “What category did I spend the most on this month?”
• “How much did I spend on subscriptions recently?”

It’s still in early stages and there’s a lot more to improve, but I thought it could become a more natural way to interact with your financial data instead of manually filtering through everything.

The app is still completely free.
No ads, no subscriptions.

Still improving it almost every day and every suggestion helps a lot.

If anyone wants to check it out, I can share the links.

The Premise

CalcByEA is a fully functional web calculator where almost every button is locked behind a paywall. You need to buy 'DLC packs' to unlock basic operations like addition, multiplication, and the equals sign.

The number 0 is free. Everything else costs money.

This is not a bug. This is the product.

It's satire on the video game industry's microtransaction model — specifically EA Games, who turned a $2 cosmetic DLC in 2006 (Horse Armor for Oblivion) into a multi-billion dollar monetization philosophy.

I built this as a mirror to the gaming industry. EA has been voted 'Worst Company in America' twice, and yet their model of shipping incomplete games and selling the rest as DLC became standard across the entire industry.

By 2021, FIFA Ultimate Team was generating $1.6B/year from digital card packs alone. The Sims 4 base game went free while the full content now costs $1,000+. Star Wars Battlefront II's loot boxes triggered government investigations into gambling laws.

So I asked: what if we applied the same logic to something universally free - a calculator?

Try it yourself. Try to add 1 + 1. See how far you get for free.

calculatorbyea.com

Month one your API costs are fine. Almost suspiciously fine.

Month three you pull the logs and realize a huge percentage of requests are the same handful of questions asked slightly differently every single day. "How do I cancel." "Can I cancel my plan." "Cancellation." The model generates a fresh answer every time and you pay full price every time.

At low volume this is invisible. At any real scale it is a significant chunk of your bill that was never in the budget because nobody modeled for repeat traffic properly before launch.

The math is simple. First time a question gets asked you pay. Every similar question after that should cost nothing because the answer already exists.

That is what semantic caching does and it is the single highest ROI infrastructure decision for any AI Product with real traffic. I built it into synvertas.com along with prompt cleanup and automatic provider failover. One URL change to get all three.

Here are some features I shipped for BiteTube this week:

• Added a dedicated “Why it’s worth watching” section so you don't have to watch videos just to end up closing them
• Built “Continue the Vibe” dynamic discovery which helps user stay on the same vibe of content
• Polished up the UI to improve user experience
• Integrated Sanity as the CMS to make managing content easier and efficient

Share what kind of features you shipped in the comments to let other users know about your project!

Just a few hours after posting on Reddit, my 100% vibe-coded project TaxCalcHQ.com started getting real traction.

My daily active users were usually below 50, but Reddit pushed it to nearly 400 within hours.

Search impressions also started climbing fast across countries like the US, Canada, Australia, UK, etc.

Although It was an experiment, if you want to check it out here's the website: https://taxcalchq.com

Reddit genuinely helps boost confidence, visibility, and reach — especially when you're building in public.

Crazy feeling seeing strangers actually use something you built from scratch.

Don't be shy, if you have something meaningful then post it everyday regardless of what some people say.

I’d love to see what everyone is building + how you’re getting your first users.

I’ll start:
I built an AI resume builder that generates resumes, cover letters, and portfolios from a prompt. - cvcons.com

Still early stage — currently focused on getting my first users and feedback.

What are you working on?

Hi ! i’m an indie dev and I wanted to share the journey of building my app, Keyri — a strict local-first digital vault for Android.

The Problem: Privacy vs Convenience

I’ve always been pretty paranoid about privacy. For years, I refused to use cloud-based password managers (and seeing breaches at major companies didn’t exactly help).

So my solution was… honestly terrible.

I kept all my passwords inside a password-protected zipped Word document stored only on my PC.

And because I was also terrified of losing everything, I kept a backup copy on a USB drive too.

This made the whole process even more painful:
every password update had to be manually synchronized between the PC copy and the USB backup.

Every time I needed to log into something on my phone or update a password, I had to:

- boot up my PC

- unzip the file

- enter the master password

- search for the entry

- update it manually

- remember to update the USB backup too.

At some point I realized I desperately needed a mobile solution, but I still didn’t want my sensitive data sitting on someone else’s servers.

The Journey: From Python Script to Flutter App

I’ve always loved coding, but never really had the time to go deep into app development. So I used this problem as an excuse to finally learn.

The first version of Keyri was actually just a local Python script running on my PC. It worked, but it obviously didn’t solve the mobile problem.

That’s when I decided to learn Flutter.

I spent months rebuilding the logic into a proper Android app during evenings and weekends. As I kept adding features for myself, I realized there were probably other privacy-focused people looking for a completely local alternative too.

So eventually I polished it up and published it on the Play Store.

Technical Challenges & Lessons Learned

here are a few interesting problems I had to solve without relying on a backend:

Handling images locally
I wanted users to store ID cards, receipts, and sensitive documents. Images are compressed on-device, encrypted locally using ChaCha20, and stored entirely inside the app sandbox.

Password breach checks without exposing passwords
I integrated the HaveIBeenPwned API using k-anonymity. Passwords are hashed locally and only the first 5 hash characters are sent. The real password never leaves the device.

Barcode & QR scanning
I used Google ML Kit for barcode scanning while ensuring image processing stays entirely on-device.

Data migration without cloud sync
Since there’s no traditional cloud account system, I built encrypted JSON backup/import support and CSV import tools to migrate from browsers like Chrome.

Backup experimentation
I’m currently testing optional encrypted backup integrations with Google Drive while trying to keep the app’s local-first philosophy intact.

What the app does today

Keyri (formerly SilentSaver) is now a full local-first digital vault for:

- passwords

- payment cards

- secure notes

- encrypted images/documents

It also includes:

- biometric unlock

- Android Autofill integration

- local breach checks

- encrypted backups

- zero ads

- zero tracking

- zero mandatory accounts

Play Store Link:
https://play.google.com/store/apps/details?id=com.nick.applab.silentsaver

I’d genuinely love to hear your feedback, especially from people who care about privacy, security, or local-first software.

Thanks for reading!

Hey everyone 👋

I recently launched my own expense manager app called MiSpent and would genuinely love some feedback from real users.

Most finance apps felt either:

too complicated
overloaded with features
or just ugly to use daily 😅

So I built something simpler and faster focused on:
✅ Quick expense tracking
✅ Clean UI
✅ Voice input for adding expenses
✅ Smart analytics & spending insights
✅ Budget tracking
✅ Lightweight experience without clutter

I’m still actively improving it and would really appreciate:

UI/UX feedback
feature suggestions
onboarding experience thoughts
anything confusing or annoying
what would make YOU actually use an expense app daily

Would love brutally honest feedback 🙌

Thanks a lot!

I’ve been building apps the traditional way for almost 20 years, and over the last year I’ve been doing a lot more agentic coding. The biggest thing I keep seeing is that the bottleneck is not really the model or the code. It’s the product context. People start building with vague prompts, loose scope, no real wedge, and no clear reason the thing should exist. That’s how you end up with a lot of vibe coded apps that technically work, but feel fragile, buggy, thin, or too simple to compete with real products.

I built LaunchChair to solve that part of the process. It’s a workspace that helps you go from rough idea to scoped MVP spec, then turns that spec into feature-by-feature dynamic prompts for a guided build. The goal is not to “validate an idea” and leave you with a report. The goal is to keep the product direction, scope, user outcomes, and build prompts connected so you can actually ship something sharper and more feature rich without rewriting the same context into ChatGPT, Claude, or Codex over and over.

I’d genuinely love feedback from other solo founders and builders. Does this match where you get stuck when building with AI, or is your pain somewhere else entirely? Here’s the site if anyone wants to take a look: https://www.launchchair.io

You post your app in a test for test group. You get 20 or 30 installs on day one. Looks great. You feel like you are finally making progress.

Then day two comes. You check your Play Console. Maybe half of your testers opened your app. The rest have already forgotten.

Day three. Even fewer. Maybe 4 or 5 people open it.

Day four. Maybe 1 or 2 people.

By day seven. Zero active testers. Google denies production access. You have to restart the full 14 days from zero.

You try again with different people. Same thing happens. Now you have wasted a month. Then two months.

Why does this keep happening? Because free testers have no reason to come back. They installed your app to get their own app tested. Once they have that, they disappear. Your app is not important to them. It does not matter how good your app is. They are not going to open it every day for two weeks. No one would.

Google does not care why your testers stopped. They only see that daily activity dropped. They deny production access. You restart.

Free testers are not reliable. They forget. That is the problem.

RealAppTesters solves this problem by providing testers who open your app every day for the full 14 days. We track daily activity. If someone drops off, we replace them. You do nothing else. No chasing. No reminding. No hoping people remember.

You add our emails to your Play Console. You wait 14 days. You apply for production access.

Stop wasting weeks on free testers that forget.

https://www.realapptesters.com

AI coding is built on two assumptions that will not hold forever:

1. Frontier intelligence feels cheap through flat subscriptions.
2. The user is assumed to be an engineer babysitting a chat agent.

Both are changing.

When subscription arbitrage narrows, AI coding must allocate intelligence efficiently. At the same time, companies will reorganize around smaller AI-native teams and builders who own more of the feature lifecycle.

Chat-based tools are not the right architecture for that world.

The next layer is an Intelligence Factory: a system where the feature becomes the durable artifact, planning manufactures context, tasks are routed across models and providers, and verification makes cheaper intelligence usable without asking the user to coordinate every step

The Elephant in the Room: Subscription Arbitrage

I analyzed my own usage over the last nine months. Priced as direct API consumption, it would have cost more than $500,000. Instead, I paid a few hundred dollars per month.

To be clear, this is not a claim about what the providers paid to serve my usage. It is the retail API-equivalent price of the same kind of heavy frontier-model consumption, estimated from observed usage and public API pricing. The point is not precision to the dollar. The point is the gap.

That gap changes behavior.

When frontier intelligence feels almost free at the margin, the default strategy becomes brute force: use the strongest model, run it longer, retry more, paste more context, and hope the agent eventually gets there.

That works while the economics are subsidized by flat subscriptions.

It becomes fragile when the system has to face the real marginal cost of intelligence.

The Arbitrage Will Narrow

The arbitrage may not disappear overnight. Inference costs may continue falling. Open models may keep improving. Providers may preserve flat plans for some user segments.

But the unlimited-feeling version of frontier intelligence will narrow.

Maybe through stricter limits. Maybe through higher prices. Maybe through usage tiers.

The mechanism matters less than the direction.

AI coding will eventually have to care much more about where intelligence is spent.

Today, most AI coding discussion is about capability.

Which model writes better code? Which editor has the stronger agent? Which CLI can run longer? Which assistant feels smartest?

The post-arbitrage question is different: How do we allocate intelligence efficiently?

Models are starting to look less like the product and more like the energy source. Providers sell access to intelligence. The valuable layer is the system that turns that intelligence into shipped work efficiently.

In that world, the expensive model becomes the escalation path, not the default runtime.

Cheaper models handle bounded work where the task is clear and verification can catch mistakes. Premium models handle ambiguity, architecture, deep debugging, integration risk, and final acceptance.

The largest frontier spend should sit near the verification boundary, where the system checks whether the feature meets its acceptance criteria, identifies uncertainty, and decides whether escalation is needed.

Current Tools Have the Right Primitives but State is Too Scattered

Current AI coding tools are improving fast.

They already expose many of the right primitives: repository access, file edits, shell commands, planning modes, memory, subagents, worktrees, hooks, cloud tasks, checkpoints, and resumable sessions.

Those primitives matter. They are the execution layer.

But execution is not the core problem anymore. The core problem is state.

Chat Is a Good Interface, but a Bad State Container

In most chat-based products, the conversation, thread, or agent run still acts as the source of truth.

The feature state gets scattered across the initial prompt, the model’s plan, later corrections, tool output, summaries, memory files, branches, commits, test logs, checkpoints, and the user’s own memory.

Those pieces exist, but they do not form one durable artifact. They do not reliably talk to each other.

That is why the human quietly becomes the coordinator.

The user restates intent, pastes logs, corrects drift, reminds the model what changed, restarts failed runs, and decides whether the final result still matches the original request.

That works when AI is an assistant. It breaks down when AI becomes part of the delivery system.

The problem is not chat as an interface.

Chat is still useful for intent, clarification, review, and approval.

The problem is chat as the state container.

Chat Discovers Too Much While Spending

The perfect example to illustrate this point is the recent /goal release by Codex.

A user can give the agent an objective, and the runtime can continue working toward that goal across turns, with controls to create, pause, resume, and clear the goal.

That is a real improvement. It moves the tool closer to long-running autonomous work.

But it also exposes the next bottleneck.

A persistent goal is still not the same thing as a durable feature artifact.

If the path is unclear, the agent still has to discover the plan while it is already running. It has to decide what matters, inspect the repo, infer dependencies, choose the next step, test, recover, and judge whether the goal is satisfied from inside the same expensive loop.

That loop needs frontier intelligence end to end because too much of the work remains ambiguous during execution.

The system keeps spending while it is figuring out the shape of the work.

How the Intelligence Factory solves the problem

The Intelligence Factory would handle the same problem differently.

It would turn the goal into a feature seed, inspect the repository before execution, extract acceptance criteria, build a task graph, classify task complexity, decide routing policy, generate focused task briefings, and only then start executing.

The long-running loop still exists, but it is no longer a dumb loop asking one frontier agent to keep pushing until the goal looks done.

It becomes an orchestrated production line: goal → feature seed → repo analysis → task graph → routed execution → verification → escalation if needed

The Intelligence Factory helps the system know what should happen next, who should do it, what context they need, how expensive the step should be, and how completion should be verified.

This is the lossy projection problem.

Using chat or a single agent loop as the durable container for software delivery is like trying to represent a cube on a flat plane: you can draw the faces, label the edges, and add shadows, but the object is still compressed into the wrong dimension.

A smarter model inside the loop still inherits the constraints of the loop.

Why the Durable Artifact Is the Feature

By feature, I mean a bounded unit of software delivery: large enough to represent real user or business value, but small enough to plan, route, verify, recover, review, and merge.

A feature can be a new capability, a bug batch, a refactor, a migration, a performance pass, or a full-stack change.

The category matters less than the lifecycle. A feature has intent, scope, acceptance criteria, implementation work, verification, and a handoff or merge boundary.

That makes it the right durable artifact for AI coding.

Why not the Project?

The project is too broad. A project contains old decisions, stale assumptions, unrelated work, conflicting priorities, and background knowledge that should not enter every task. Project knowledge should inform the work, but it should not become the active work artifact.

The feature sits at the right level.

It is bounded enough to control context and cost. It is large enough to represent shipped value.

What the feature has to preserve

Treating the feature as the durable artifact does not mean creating a bigger spec.

It means preserving the state required to keep delivery coherent across models, providers, sessions, failures, and reviews.

A feature has to preserve four kinds of state.

Intent State

Intent state records what the user wants, what is out of scope, which assumptions are accepted, and which questions still matter. Without this, every model call slowly reinterprets the original request.

Execution State

Execution state records the technical plan, task graph, dependencies, owned surfaces, and current progress. Without this, autonomy becomes a long-running loop with no durable understanding of what remains.

Economic State

Economic state records task complexity, failure cost, routing policy, preferred model or provider, fallback route, and escalation rule. Without this, the system cannot allocate intelligence before spending it.

Trust State

Trust state records verification targets, test results, unresolved gaps, recovery points, and review status. Without this, cheaper-model routing becomes risky and long-running work becomes hard to trust.

Verification does not make cheap intelligence magically safe. It makes cheap intelligence usable by bounding the work, checking known contracts, surfacing uncertainty, and escalating when unresolved risk remains.

Planning Is the Context Factory

The feature starts as a seed

The user should not need to write a perfect PRD.

A normal request should be enough.

The system’s first job is to turn that request into a feature seed: a small, structured starting point that makes the work actionable without pretending everything is already known.

A good feature seed answers three questions.

What is being changed? The system extracts the goal, expected behavior, visible constraints, and non-goals from the request.

What needs to be clarified? The system inspects the repository before asking questions. It should only interrupt the user for decisions that change scope, architecture, routing, or verification.

What would make this complete? The system turns the request into early acceptance criteria so later work can be verified against something stable.

This is the first moment where the system stops being a chat assistant and starts becoming a delivery system.

Planning manufactures operating context

Planning is not overhead. Planning manufactures the context that makes autonomy and routing possible.

A plan inside a .md file is fragile because it doesn't produce structured machine-readable knowledge. A plan promoted into feature state becomes reusable operating context.

The planning step has three jobs.

First, it aligns intent. It separates facts, assumptions, open questions, and non-goals. It asks only the questions that change implementation.

Second, it structures execution. It maps requirements to a technical approach, breaks the work into tasks, identifies dependencies, and defines which files or surfaces each task is likely to touch.

Third, it creates the control points for cost and trust. It classifies task complexity, chooses routing policy, defines verification targets, and records where recovery should resume if the workflow fails.

The most important output is not the plan document.

The output is clean structured context that allows downstream activities to run as efficiently as possible.

Each model call should receive a focused briefing: the task goal, relevant requirements, accepted decisions, constraints, likely files, integration contracts, and verification steps.

That is what reduces context rot.

That is what makes providers interchangeable.

That is what makes cheap models usable.

That is what lets the system run longer without the user babysitting every step.

The plan is the context factory. Without it, every model call has to rediscover the work.

----

Ps: I built a tool that embodies all the principles above (and much more that I left out to not write a poem). Happy to share more with anybody interested

----

I got tired of sounding like a robot.

Every time I used ChatGPT for an email, I’d spend the next 10 minutes editing it back into my own voice. Which kind of defeated the point.

So I built StyloMac a native Mac app that learns how you write and helps you sound like you, not like an LLM.

How it works:

1. Paste in a few emails or messages you’ve written or just rewrite exisiting

2. Hit ⌃⌥H from anywhere on your Mac

3. Get a version that sounds like you wrote it

It gets better as you use it. Every edit you make teaches it more about your voice.

Native Swift app. Not Electron. Sits in your menu bar. Uses ~30MB RAM idle.

for about a year i was making a lot of high-stakes decisions with no real sounding board.

i'd just finished my masters in the uk. i still had time on my visa but i could feel the writing on the wall. a part-time bartending job wasn't where i was supposed to be, and in india a non-linear career path has no value. so six months before my visa ended i moved back. practical decision. i thought so too.

cut to being back home.

i started applying the normal way. masters in advertising management, strong on paper. ad agencies said i was overqualified. pm roles said i didn’t have relevant experience. i was stuck in a gap nobody had a name for.

so i started building.

but the harder part wasn’t building. it was deciding.

what to build, who to build for, when to pivot, when to hold. every decision felt heavier than it should.

in therapy, my therapist pointed out a pattern.
i take the harder path first, and abandon it too quickly. because failing at something hard feels more justifiable than failing at something simple.

loss aversion, but in a very specific form.

once i saw it, i couldn’t unsee it. but i couldn’t call my therapist every time i hit a decision loop either.

so i built something for that gap.

it’s called Decision Theatre.
not a journal, not an ai therapist. a structured reflection tool based on behavioural science (loss aversion, prospect theory, identity protection).

you bring a decision you’re sitting on. it surfaces what’s actually driving it. takes about 10 minutes.

$19 one-time. no subscription. i didn’t want it to be another monthly cost.

i built it for myself first. turns out a lot of people are sitting in the same gap.

if you want to try it and share feedback, that’s genuinely what i’m here for:
DecisionTheatre

and if any of this sounds familiar the loop, the pattern, i’d love to hear how you deal with it.

Started building my AI SaaS around 2 months ago while managing college studies.

It’s still very early, but seeing users and revenue coming from different countries honestly feels surreal.

Biggest surprise for me wasn’t even the money - it was realizing strangers across the world are actually finding and using something I built.

Still improving the product every single week.

Would love feedback, suggestions, or growth advice from other indie hackers here.

Product: Clickcast.tech converts any website into a promo/explainer video in minutes.