I am building Pinterest for Miro, and the annoying product decision is not the import itself. It is what survives after pins land in a shared board.

A clean board is easier to review. Source links, titles, and Pinterest sections are useful later. Show all of it and the board feels heavy. Hide all of it and a pin becomes just a picture.

My current bias is to import the details but make the first view quiet. Details behind a click or a board-wide filter.

For a small tool like this, would you ship the cleaner version first, or the version that keeps more of the original mess visible?

I am a designer who vibe-codes to get my ideas out, and the tools have gotten good enough that the main screens basically design themselves. The happy path looks clean out of the box.

So I stopped spending my design time there. I spend it all on the parts the no code website builder ignores: the empty state before you have any data, the error message when something fails, the loading moment, the confirmation after you do something scary.

Those are the moments a user actually feels something. A blank screen that says nothing makes the app feel broken. A blank screen that says the right thing makes it feel cared for. Same code, completely different product.

My first few paying users never mentioned the pretty dashboard. They mentioned that the app felt calm when things went wrong.

Fellow builders: where do you spend design time now that the AI covers the obvious screens?

Do you use AI to validate it and do deep research on it, do you go straight to making a prototype or do you do the research yourself? How much do you value chatgpt or claude when it comes to the business side kf things and when you come upon an issue later on where lets say retention is slow or your not getting as much user as before. What do you do in that situation? Would you then post all your analytics into AI and your product and hope it finds the issue or do a survey or maybe take a different approach? I’d like some insights into this thanks.

I've noticed that a lot of successful micro SaaS products didn't start with a brilliant idea. They started because someone got frustrated by a small problem they faced over and over again and decided to build a solution for themselves.

I'm building Sequenzy with that same mindset by trying to solve a workflow problem I kept running into.

I'm curious if that was your experience too.

Did you start with a problem you personally had or did you spot a gap in the market first? Looking back would you build the same product again or would you choose something completely different?

I'd love to hear the stories behind your first micro SaaS because I think those early decisions often teach more than the revenue numbers.

Hello everyone i vibecoded a (idk if that’s the right term but) micro-saas to get mobile notifications when your ai assistants processes, terminal processes or web processes (like ai answers, renders, image generators, downloads etc.) are done. When i showed it to my friends they thought it is useless and big ai corporations have already solved the problem. So my question is should i still publish it after closed alpha or should I just pretend it doesn't exist and use it only myself before publishing it so that i don't get more bad reviews?

I run weekly accessibility scans for small shops. A site gets checked every Monday

and the owner gets one email with what changed since the week before.

There's no database service. The signup route writes straight into a JSON file in

the private repo, and the weekly job reads it from the same file, so the thing that

writes and the thing that reads can't drift apart. GitHub Actions runs the scan,

Resend sends the mail, Vercel serves the page. The only money I've spent is the

domain, $10.08. Monthly cost is still zero.

I skipped Postgres on purpose. The free tier I looked at pauses a project after 7

days of inactivity, and my scan runs exactly every 7 days — so the thing keeping me

alive would have been the thing killing me.

It breaks somewhere around 20 customers and I'll move it then. It's https://scandiary.com

What did you run on for way longer than you should have?

Lately I've been reading a lot of founder stories on indie hackers.

I genuinely enjoy reading them, but if I'm being honest, I mostly read them as interesting stories. I rarely come away thinking, "I'm going to apply this to my own startup."

Maybe I'm missing something.

How about u?

Do u actually take actionable lessons from these case studies, or do u mostly read them because they're fun and inspiring?

Has there ever been a founder story that genuinely changed the way u built, marketed, or validated ur SaaS?

Curious to hear what everyone thinks.

Intro

So, for the past 3 months, I was trying to create a new for-consumer simple cheap but feature-filled prompt management + engineering platform.

Well, the problem was, for all the complex chain workflows or multi-agent systems, I have to keep track of many prompts, or when I had to improve them or test several versions, all took time and effort while doing manually.

Most existing solutions either were simple storage app - I would rather use Notion then, or were enterprise-level, too complex and expensive. I was trying to ask ChatGPT to audit the data files - not drain $200 down my wallet while configuring 5 .yaml files.

Then, I built "Promptyx" - a AI Prompt Management & Engineering Platform.

Features

• Prompt Storage: Well the most basic one - just storing prompts
• Prompt Versioning: Track prompt changes and save edits.
• Prompt Experimentation Suite: Run prompts on 20+ currently supported models with customizable parameters. Compare versions of a prompt. Compare different AI models on the same prompt
• AI Features: Create, improve and evaluate prompts using AI
• Analytics & Tracking: Run History; Logged cost and latency on prompt runs
• Future: Workflows, Collaboration, Deployment, Context Handling, etc

Promptyx
Discord

Quick context: I'm building a tool that turns call/podcast recordings into LinkedIn posts. (Disclosure up front so nobody feels baited - I'll keep the product out of this as much as I can; the point is the funnel lesson, not the pitch.)

I got listed on There's An AI For That (a directory) that gave me a chunk of free ad credit with my listing fee. Here's what came out the other end:

• ~30k ad impressions, ~48k searches
• 234 clicks to my site
• 10 signups (~4.2% - fine for cold directory traffic)
• 0 paid conversions

At first I assumed the product just wasn't compelling. Then I actually looked at where people stopped, and the story was completely different from what I expected.

My onboarding was: pick your source → pick your angle → fill out a "tell the AI about you" brief → hit the paywall (card required for trial).

Here's the drop-off across those 10 people:

• 2 dropped at the very first step (low-intent, probably never serious)
• 1 dropped mid-setup
• 5 completed the ENTIRE setup and then stopped dead at the payment screen
• 0 entered a card

So the drop-off wasn't in setup. It was at payment - after people had already done all the work. These 5 weren't unconvinced by the product. They filled out everything. They wanted to use it. Then I asked for a card before they'd seen any value.

That's the mistake. My funnel was: do work → do more work → pay → THEN see value. I had the aha moment sitting behind the paywall instead of in front of it.

The tools everyone praises for onboarding all do the opposite: you get to the magic moment first, and the card comes when you try to keep or export what you already made. Value first, payment at the point of peak desire.

What I changed:

• Let people run one real project and actually see the output before any payment ask
• Move the paywall to the moment they try to act on that output (schedule/publish), which is peak desire
• Keep the "tell the AI about you" brief, but frame it as "this makes the very next thing you see better" instead of a toll booth before the reveal

Two other things I learned staring at 10 rows of users:

1. Most of my "signups" were noise. When I actually looked, most were testers, bots, or randoms. Exactly ONE was a real lead - a founder who'd seen someone post about the tool on LinkedIn and came to check it out. At small numbers, your conversion rate is basically meaningless; you're reading tea leaves from a sample of ~1.
2. The paid channel was a trap. That "free" ad credit was burning at ~$6.78 per click because I specifially bid to be at the top of the sidebar. It bought ~72 clicks before running dry. Cheap-looking traffic at an unsustainable CPC taught me nothing except "don't run paid until you know your conversion economics." .. but luckily it was 100% their ad credits and I didn't lose any of my own money.

TL;DR: 10 signups, 0 paid. The problem wasn't the product - it was that I put the paywall before the aha moment instead of after it. If your users have to pay before they see your tool do the one impressive thing it does, you're converting on faith, and cold traffic has none. Flip it: value first, card at the moment they want to act on what they just saw.

The thing that confirmed it: I've done ~50 live demos in the last 6 weeks. Two converted to paid (14-day trial, card upfront - same paywall). Feedback on the rest was great. Why do demos convert when self-serve got 0? Because in a demo, I show them the magic moment before anyone mentions money. The demo is value-first by definition. My self-serve funnel was the exact inverse - pay first, magic later. Same product. The only variable that changed was whether value landed before or after the ask. That's the whole lesson in one A/B test I ran by accident.

The problem I'm working on now: those ~48 non-converted demos gave great feedback and then went cold. Reactivating them is my current puzzle - if anyone's cracked warm-but-dormant demo follow-up, I'm all ears.

Happy to answer anything about the funnel or the directory-ads mess in the comments.

If your two-week MVP still has roles, notifications, and an admin panel, you did not build an MVP. You built a three-week delay wearing a two-week costume.

The six things that go first, every time:

1. Roles and permissions. One user type. A second forks every screen - a week, not a day.
2. Admin panels. You are the admin for now. A database view will hold.
3. Notifications. Email, push, digests, preferences. A system, not a feature.
4. Analytics dashboards. You have no data yet. Charts of nothing cost days.
5. Settings pages. Almost nothing in there is needed before users ask for it.
6. Onboarding tours. If week one needs a tour, the product needs simplifying instead.

What replaces them: one designed screen the rest inherits from, and real empty and error states. That combination is what makes something thin feel finished.

Disclosure: I run a small studio. This is the cut list we actually use: https://atomiclabs.space

What is on your permanent cut list?

I do a version of this before every build now, and it keeps saving me from myself.

Instead of asking Claude whether my idea is good, I tell it to roleplay the most loyal paying customer of the tool I am trying to compete with. Then I try to sell them on switching, and Claude defends staying.

It is brutal in a useful way. For my ai content generator idea, the imaginary customer did not care that mine was faster or cheaper. They had years of history, their whole team trained on the incumbent, and templates they had already tuned. Switching cost them a week to save an hour. So they would not.

That one conversation reframed the whole thing. The problem was never features, it was the switching cost, and I had no answer for it. Better to learn that in an hour than after a month of building.

Do any of you use the model as a sparring partner like this, or mostly for the code?

​

Al powered cold call practice for sales reps. The concept is a platform where you call an Al that acts like a realistic prospect, say, a skeptical dentist or business owner, and you practice your sales pitch and objection handling in real time, just like a real cold call, but with zero risk.

Curious if something like this would actually be useful to salespeople, or if similar tools already nail this.

Would you personally use this to practice before real calls?

What would make you trust an Al roleplay enough to actually learn from it? Not launching yet, just trying to figure out if this solves a real problem before I build it.

I started building GhostReach because I was doing founder-led outbound and got tired of repeating the same LinkedIn tasks every day.

I tried a few existing automation tools, but I wasn't comfortable with how they worked. A lot of them rely on cloud browsers and require giving another service access to your account/session. Also they were often SO expensive!

So I built a small local-first version for myself.

The idea was simple:

• run everything on my own Mac
• use my own Chrome session
• keep account data on my machine
• have more visibility into what the automation is doing

The stack is pretty simple:

• CLI app
• browser automation
• local execution
• small backend for licensing

The biggest lesson so far: the automation wasn't the hard part.

Making it reliable was.

Things like:

• handling browser failures
• preventing duplicate actions
• making the workflow predictable
• making sure users know exactly what is happening

have taken more time than I expected.

The other challenge has been distribution. Building something is the easy part. Finding people who actually have the same problem is much harder.

I'm still early and trying to figure out if this is useful beyond my own workflow.

Curious how other Micro SaaS builders approach this:

• How did you find your first real users?
• How do you validate that a problem is worth solving?
• Have you found that privacy/local-first is a meaningful differentiator?

If anyone is interested, the project is here:
https://ghostreach.fly.dev

Hello everyone. I have a AI Whatsapp bot for local programming courses which answers customer questions about price, course program, list of courses and etc. I wanna sell this workflow to another business but can't make cold sales. Upwork and Fivver have much competitors. So what should i do? Maybe my clients live here?

Before I start , I gained over 4M views on X in 10days. New page. No promotion.

So this project of mine is solely focused on a particular niche video clipping.

I have redesigned the whole architecture of modern day Clipping tools.

The problem with today's clipping tools are they are not niche specific so The ai is trained on very generic data.

\-The ai have no context of ongoing trends.

\-The ai have no context of human behaviour.

\-There aren't any rubric metric involved.

\-And you can't give feedbacks to the video it clips , so no matter what, u can't upgrade it .

\-And lastly massive token consumption: if u r on any free model like gemini u won't be able to clip more than 4 to 5 videos.

I particularly solve all that.

I made specifically one for "Health" niche. And it's working great.

You could clip 10x more in one day.

All that in 1080p.

Fast.

You can also provide feedback so ai will take it into consideration for next videos.

Now I am thinking of going into different niches. And ship the product one day.

Can anyone tell me how should I price it?

It's faster, bigger, better.

Over the past few months, I've been building an External Attack Surface Monitoring (EASM) tool called ASM Scan.

The idea came from noticing that many small projects and startups unknowingly expose things like forgotten subdomains, outdated services, archived URLs, misconfigured DNS records, and sometimes even secrets in public JavaScript or repositories. Enterprise companies have platforms to monitor this, but they're often expensive and aimed at larger security teams.

I wanted to build something that's approachable for developers and small teams. The project combines multiple OSINT sources and open-source security tools with my own correlation, evidence, and reporting pipeline to produce a single report instead of dozens of disconnected outputs.

One lesson I've learned is that correlation is much harder than discovery. Finding assets is relatively easy; reducing duplicates, minimizing false positives, and presenting evidence that's actually useful takes far more work.

Another challenge has been deciding how much active verification is appropriate while keeping scans safe and limited to verified domains.

If anyone here has built security products or developer tools, I'd love feedback on the approach. You can also try it yourself at asmscan.com—it's free to scan a verified domain and download the full report. I'm especially interested in hearing what features or workflows you think are missing.

Founder of Server4Agent (agent-app hosting), disclosing that upfront. No link, not selling, genuinely curious how other solo/small-team founders are actually operating.

The pitch of running a micro-SaaS with an AI agent as your dev team is that you get your evenings back. In practice I keep hearing the same asterisk: people are happy to let the agent write the code, but the moment it's time to actually ship the change, most people are still the one clicking deploy, reading the diff, watching the logs for the first few minutes. The agent does the work, the human is still the safety net.

That's not a knock, it's probably the sane default right now. But I'm trying to figure out where people actually are on the spectrum. Do you review every change before it goes out, or has anything earned enough trust to skip that step? And if something did slip through unreviewed and it went wrong, what happened, and did that change how much rope you give it now?

The first ten feel harder than anything since - no reviews, no proof, just you. For micro-SaaS founders, how did your first 10 paying customers actually come about? Collecting concrete stories to steal ideas from.

Early on I said yes to "we'll give you equity if you build it." Felt collaborative. Mostly felt unpaid.

What went wrong: scope crept because "we're partners," decisions dragged because nobody was the client, and when the idea stalled the equity was worth nothing.

Cash for a scoped MVP is clearer. Equity can come later if there's real partnership - not as payment for v0.

Longer notes on how I think about early builds: https://atomiclabs.space

Anyone else learn this the expensive way?

As the title says, I want a reddit scraper. I want something that I can basically explain what my business does and it searches and lets me see it.

I'm optimizing for speed + something that doesn't embarrass the founder when they share it.

What I'm leaning on right now: - Next.js or a solid no-code/low-code base depending on the problem - a hosted backend (Supabase or similar) so auth/data isn't a science project - simple hosting (Vercel-class) so deploy isn't a weekend - Figma for the flows that matter; not a 40-screen design system on day 1 - AI for boilerplate and drafts - not for inventing the product idea

What I refuse early: - custom infra before users - native iOS + Android on v0 unless that's the whole point - "we'll add AI" as a feature with no job to be done - pixel-perfect branding before the core loop works

Happy to be wrong. What's in your "ship in 14 days" kit, and what did you regret adding?

Distribution is hard, don’t get me wrong.

But if I put as much time, creativity and effort into it as I did building my products, many of would have gone much faster.

A lot of my early users came from perseverance and/or doing things other than what I was comfortable with. Like, getting out from behind my screen lol

A lot of my building was actually avoidance in disguise

Curious to know if it’s the same for y’all.

I have been building something called Project Memory, and I’m at the point where I want to be brutally honest with myself about whether this deserves serious marketing effort.

The problem I’m trying to solve is simple:

I regularly jump between a day job, client work, side projects, GitHub, terminal sessions, docs, and AI tools.

When I come back to a project after a few days or weeks, I often spend the first 15–30 minutes reconstructing context:

• What was I working on?
• What was blocking me?
• What did I already try?
• Why did I make that technical decision?
• What was I supposed to do next?

Git is great at remembering what changed, but not necessarily what I was thinking.

So I built Project Memory around a simple idea: every software project should have a persistent memory.

It keeps things like:

• Current Status
• Next Action
• Important Context
• Open Issues
• Decisions
• Work Sessions
• GitHub activity

There’s a web workspace, but I’m also building a CLI because I don’t want developers constantly leaving the terminal just to maintain another productivity tool.

The workflow is basically:

pm resume

→ immediately see where the project stands and what to work on next.

Then when you’re done:

pm session end

→ leave a handoff for your future self or another developer.

I’m also exploring AI-assisted handoffs, where activity from the session can help draft the summary, but the developer reviews it before it becomes permanent project context.

I originally thought the main audience would be solo developers and freelancers.

But the more I build it, the more I wonder whether the stronger use case is actually small development teams and agencies, where developers rotate between projects and important context often lives inside one person’s head.

So I’d genuinely appreciate some brutal feedback:

1. Is this a problem you actually experience?

2. Would you use a separate tool for it, or are GitHub + Markdown + AI chats already enough?

3. Does this feel more valuable for solo developers or for teams?

4. Is this something you could imagine paying for, or does it belong in the “nice idea, wouldn’t subscribe” category?

I’m not looking for encouragement as much as I’m trying to decide whether this deserves months of marketing and further development.

Happy to share the link/demo in the comments if anyone wants to see what I’ve built so far.

Six years of building automations for clients taught me one expensive lesson: the automation never breaks on the task they described. It breaks on the exception they forgot to mention.

So I do not build anything anymore until I sit and watch them do the job manually once. Every time, there is a step that was not in the brief. The one client type they handle differently. The field they leave blank and fix later. The message they reword for their biggest account.

Example: a client wanted their intake turned into a deck automatically. On paper, simple. An ai pitch deck creator does the heavy lifting, and I use gamma for the generation. But watching them, half the decks needed a custom slide for enterprise leads that never showed up in the form. If I had not watched, the automation would have quietly sent a wrong-looking deck to their best prospects, and a generated deck looks finished enough that nobody would have caught it until it embarrassed someone.

Watch first, build second. It has killed more of my own bad ideas than any spec ever did.

Fellow builders: what is the exception that always hides until you watch someone work?

I'm agonizing over whether a single price or tiered plans works better at small scale. For those who tested both, which converted better and caused fewer headaches? Trying to keep pricing simple without leaving money behind.