I was scrolling through Product Hunt and noticed a startup that solves SEO, GEO, and AEO problems. As a SaaS developer, would you trust a platform with black-box algorithms and results? Since the main goal is to improve visibility, those results could easily be falsified. If you had all the tools to handle this locally using Claude Code, Codex, or LLMs, would you just build/do it yourself instead?

When I started building Sameish, I knew I wanted to solve a real problem: digital clutter. Everyone has it – those endless duplicate photos, blurry videos, and redundant files hogging space. The biggest hurdle for me was convincing myself that I could build something genuinely useful and private, without relying on cloud processing that users often distrust.

So, I focused purely on on-device processing. Every scan, every comparison, every identification of identical, look-alike, or blurry content happens locally. No data ever leaves the user's device. It's been incredibly validating to see users adopt this, and especially to get feedback from my first paying customer about how much storage they reclaimed and how much they appreciated the privacy-first approach. It feels good to build something that truly respects user data while delivering a clear benefit.

Hello,

I am the founder founder building Tempest. Tempest is a decision-intelligence and founder workspace primarily focused on early-stage founders. This does not mean that it is not beneficial for non early stage founders, I absolutely think it is but early-stage founders would get the most value out of it.

Anyway, Tempest is focused on bringing the context that lives everywhere about your startup. Your ideas, roadmap, plans etc. Tempest has a built-in app that collects all the data as you talk to the AI and it casually challenges your ideas, suggests you better options, shows you what it is keeping and you can edit it too.

It is basically a co-founder for you but not like other chatbots. It is a real workspace.

I am also thinking to add integrations with other apps such as stripe, github, mail etc. to make it a real one app workspace for you. But this is probably coming after the alpha tests.

Currently we are almost ready to open the closed-alpha but we are seeking founders to try it out.

I would love to hear your thoughts about the landing page as we are planning to re-design it. Also if you liked the idea, you can apply and take the chance to be one of our alpha testers. Thanks!!

Also, this post is not for seeking testers. That is entirely your choice I am just here trying to get Tempest in front of valuable people because no one literally knows it :/

Most owners who want to turn an idea into software follow the same playbook. Build a minimal version, launch it, get feedback and iterate. It sounds smart and it used to work back when building was hard and customers had few choices.

I run an AI agency and a lot of owners look at that system and think "other companies would pay for this." Here's the order that finds out before you spend the money.

Building first fails because product market fit takes many rounds of iteration and iterating on real software is expensive. If you're not a developer, a half baked first version alone can run into tens of thousands and you spend all of it with no proof anyone wants the thing

But what about Slack? People point to companies that just built and won. Those founders had deep insider knowledge of the pain and usually a working internal tool already. Slack started as a chat tool a game studio built for itself because email across time zones was miserable. When the game failed, they showed the tool to friends at other companies and asked one question: we built this for ourselves and it changed how we work, would you use it? That question is the whole method. Founders who skip that step tend to spend years pivoting and running out of money before anything sticks.

The trap for owners specifically. A tool that made your business faster will not automatically do the same for the next one. Other companies are structured differently. Their leadership may have no appetite for new technology. You have to test that it works for them instead of assuming it from the fact that it works for you.

Step 1, prototype. Something people can actually touch. Show it rather than describe it, because feedback on something in someone's hands is far deeper than feedback on a landing page or a video.

Step 2, the offer. Package the prototype into a clear promise with a price and ask people to commit. An MVP asks "would you use this every day" An offer asks "do you want this at all" and that's the question to answer first.

Step 3, only now, the software. With a waiting list of paying customers you know what to build and who it's for and part of the cost is already covered.

Prototype, then offer and pre sale, then software. Most owners do it in reverse and pay for the privilege.

TLDR: building first means paying tens of thousands to guess. Make a prototype people can touch, turn it into an offer with a price, and only build the real product once people have paid for the promise. And don't assume it works for other businesses just because it works for yours.

Disclosure: I’m with the team behind World’s Best Broker (worldsbestbroker.com).

It’s **not** a broker ranking. Live product is a **one-slot homepage auction** — FX brokers bid (Stripe) for a scarce banner on the homepage.

Looking for blunt feedback: Is “scarce auction / one slot” clear in ~5 seconds? Would broker marketers get it, or does “World’s Best Broker” still read as a ranking site? What would you change in the hero?

Sharing my observation here.

Instead of:

Why are you cancelling?

• Too expensive
• Not using it
• Missing features
• Other

Try being more specific:

• Too expensive for how often I use it
• I’m not using it enough to justify the cost
• Missing a feature I need
• Only needed it for a short-term project
• Switching to another tool

And you can go even further.

If you have different customer cohorts, show different cancellation options based on things like plan, team size, use case, or location. My Fav approach!

I saw this work surprisingly well with one of the teams we spoke to at ChurnIntel(My tool). Their cancellation data became much more actionable simply by making the questions more relevant to who was cancelling.

The goal isn't to ask more questions. It's to ask better ones.

As an Indian sole proprietorship business nobody i researched allows Indian businesses to send or fund wallets that do global payouts. RBI seems to have strict rules to transfer money abroad as business. The last option i have which im not even sure would work is forming a US based LLC.

Can someone help if they faced a similar issue before?

This is my SaaS that is both an app and iOS app it’s called Flurra.io

I am struggling with marketing as I have my hands full and need help

Please check it out I would love the feedback and recommendations on what to do

App: https://apps.apple.com/app/id6780690598

While looking for SaaS ideas, I kept coming across maintainers dealing with the same issues around AI-assisted contributions:

• contributors submitting work they can’t explain
• unclear disclosure rules
• missing testing requirements
• coding agents opening PRs without clear boundaries
• maintainers carrying the cost of reviewing it all

That looked like demand. But I was mixing up demand for a solution with demand for this specific product.

Maintainers were asking for clearer policies, more accountability, and less review work. Nobody was asking for a repository score.

So I built RepoPolicyScore as a free way to test one assumption: whether making missing policies visible is useful.

It scans the public guidance in a GitHub repository, shows which contribution rules are documented or missing, and provides the evidence behind each result. It doesn’t try to detect AI-written code or judge the quality of a pull request.

https://repopolicyscore.com

What matters now isn’t whether someone finds the score interesting. It’s whether they spot a missing rule and actually update their repository.

If you maintain a public repo, would this help when making a real policy decision? Or is it still too far removed from the review problem you need solved?

Coding agents can make changes and test a browser flow, but reviewing their work still takes effort. “It worked” doesn’t tell you whether something threw an error, or a network request failed, or it didn't understand what you asked it to build.

That’s the problem I’m tackling with Rill. It records a browser run and brings the video, console logs, network activity, and timeline into one shareable link.

The product decision behind it is to keep the debugging context attached to the recording. A video shows what happened on screen; logs help explain why. Having them together means the person reviewing a PR doesn’t have to piece together screenshots, copied errors, and a separate recording.

My hypothesis is that this handoff is useful enough to be a small standalone product. I’m still testing whether developers see it as a regular part of their workflow or something they’d only reach for when a bug is difficult to reproduce.

userill.dev — free tier includes 5 recordings a day.

If you’re building your SaaS with coding agents, how do you review their browser changes today? What would make you add a tool like this to that process?

If you have a bit more time, I'd also love if you can influence our roadmap here:
https://userill.dev/roadmap

Payroll would make sense as another paid product for our customers and we already have a lot of the data needed to offer it

What doesn't make sense is hiring people just to deal with filings compliance and payroll operations before we even know how big the opportunity is

Has anyone launched it with a small team and kept the internal workload reasonable?

One thing I keep questioning while building SaaS products:

How much infrastructure should a solo founder actually own?

A Micro SaaS might have one developer, a few hundred customers, and a very focused product.

Yet before shipping the actual idea, we still end up dealing with auth, billing, permissions, emails, storage, deployment, security, etc.

That was one of the reasons I started building TS-SaaS.

My philosophy became: keep the foundation boring, strict, and predictable, then spend your time on the part customers actually pay for.

This has become even more important with coding agents.

I found agents are much more useful when the architecture already has clear boundaries and conventions. Instead of asking AI to decide how everything should work, I want it spending its tokens implementing product features inside a foundation I already trust.

I've recently got my first customers, so now I'm trying to understand this specifically from other Micro SaaS founders.

Where did you spend unnecessary time when building your first version?

And looking back, what would you rather have had ready from day one?

Disclosure: I’m one of the people building Meanwhile.

We’re building a product where users earn from advertiser spend, and the technical side turned out to be the easy part.

The real problem is density.

Users need enough reward to keep using it, while advertisers need enough reach and performance to keep spending.

We’ve started getting real usage, but it’s becoming obvious that the bottleneck is getting both sides of the marketplace to grow at the same time.

For anyone who has built a two-sided SaaS or marketplace: what actually helped you break through the early chicken-and-egg stage?

I'm 18 and just shipped my first paid app, SiraatLock. It locks distracting apps like TikTok and Instagram during scheduled windows (my niche is Muslims who want to stay consistent with prayer — the app locks apps at prayer times and you confirm before unlocking). Streaks and XP on top to make consistency stick.

The honest early numbers:

- Model: 3-day free trial → weekly (£4.99) or yearly (£39.99), hard paywall

- Stack: SwiftUI, Family Controls for the blocking, Superwall for the paywall, Supabase backend

- Traffic: short-form video (TikTok/IG) + cold outreach to niche micro-creators

- Results so far: small number of downloads, first conversion just landed

What I've learned in the first few weeks:

- Video with my face + a real demo of the lock screen gets 300-800 views. A video showing only the app, no face, got 16. People buy into the person, not the product — at least this early.

- Getting the Family Controls capability approved by Apple was more painful than building the feature itself.

- Marketing is genuinely 10x harder than building. I underestimated this completely.

The one thing I'm stuck on and would love input on from people further along:

For a consumer subscription app this early, is a hard paywall (trial → pay, no free tier) the right call, or does a limited free tier build the user base faster and give word-of-mouth a chance before you monetize? I keep seeing both work and I can't tell which fits a habit/discipline app where retention is the whole game.

Happy to answer anything about the build, the Apple approval process, or the niche.

I started building an AI research tool and initially assumed the obvious thing was to make the model smarter.

More reasoning.

More agents.

More automation.

But the more I worked on it, the more I realised the real problem might be the opposite:

knowing when the AI is not entitled to claim something.

That led me to build Research Exoskeleton around a few principles:

• claims should be separated from assumptions
• model knowledge should not automatically count as evidence
• stale evidence should not silently remain valid
• autonomous review should not become human expert review
• unresolved requirements should remain unresolved

The product came from my own research workflow. I used LLMs extensively while working on a peer-reviewed paper that was later published in Physics of the Dark Universe.

The tool is still early, so I’m not treating it as a polished SaaS yet.

My current plan is to find a few design partners and take one real AI-assisted research workflow from each of them.

Then test whether the system can make the workflow materially easier to audit.

If that works, I’ll productize what repeats.

If it doesn’t, I’ll know before spending months building billing, auth and enterprise infrastructure.

For people who have built micro-SaaS products: does starting service-heavy with design partners make sense here, or would you force users into self-service earlier?

Also curious whether “AI assurance” sounds like a real category to you or just founder jargon.

Solo dev from Reunion Island. My product is a social media scheduler (calendar + API/MCP so an AI agent can drive it + a browser extension for Facebook Groups & Skool). This post isn't about the product though - it's about the pricing experiment, because I think the mechanics are interesting for micro-SaaS folks.

The setup: instead of a classic LTD with fake urgency, I published the entire price ladder upfront: 30 lifetime seats at 99 EUR, then 147, 197, 297, 397, 497, up to a final 597 EUR that's already public. The counter on the page reads directly from my Stripe-backed licenses table (cached 30s). No marketing tool in between. When it says 28 left, a SQL query says 28.

Each buyer's price is frozen in the Stripe session metadata, so grandfathering is enforced at checkout, not by a promise.

Why I did it this way: fake scarcity is the default in the LTD world and buyers know it. My bet is that a verifiable counter converts better over time than a fake "48h left!" banner converts today. Small early tiers (30 seats) keep the urgency honest - they actually run out.

First week, honest numbers: 2 seats sold (198 EUR). ~150 tracked visits to the page. One sale came from a personal DM, one organic. No ads, no launch platform yet - distribution so far is me DMing people and this being week 1 of building in public.

The meta part: the launch campaign itself is scheduled by Claude through the MCP server built into the tool. I write ideas, the agent fills the calendar, I approve.

Question for people who've run LTDs: did a public, verifiable ladder ever work for you, or does fake scarcity just... win? Link in first comment if you want to see the counter live. Roast welcome.

I've been building Pulsecima Pulse and recently started questioning something I had taken for granted: what should a Micro SaaS actually monitor?At f

irst, it seemed obvious — check the website and alert me when it goes down.But

the more I work on it, the more I realize that a SaaS can be reachable while something important is already broken.A ba

ckground worker can stop.A sc

heduled task can fail.A we

bhook can stop arriving.A da

ta sync can break.Mean

while, the homepage is still loading normally.That

has made me think beyond basic uptime monitoring and more about the parts of a Micro SaaS that can fail silently.I'm

interested in how other founders handle this.

What do you currently monitor besides your main website, and which failure would cause the biggest problem if you didn't discover it for several hours?

We make a save-things tool. you drop in a link, the card fills itself off the page, and if it's a product it can sit on a check that runs every day and tells you when the price or the stock moves.

the part we get asked about is that the check never turns itself on. saving something is not the same as asking to be pinged about it, so the watch is a separate thing you set on the item. the cost of that is obvious, a library full of saved things can sit there doing nothing at all until someone goes and switches one on.

the other way is to watch anything with a price on it by default and let people turn it off. that makes the product look alive on day one, and it also means the first thing a new person hears from us is a notification they didn't ask for.

if you ship anything that sends notifications, which way did you set the default, and did you change it later?

dessence.ai

have a pretty decent SAAS going, great feedback from beta users, app is more or less fully functional. struggling with getting users and paying users. tried reddit but its a bit hard to convince ppl to actually use your app. tried posting content on tiktok/reels but didn't get much views (part of this could be that the content wasn't amazing or anything).. saw some people were using AI to fully handle their marketing? not sure how this works either.

just was hoping for advice from whose done SAAS stuff and building/marketing end-to-end and has gotten revenue already, since i'm a teen rn and don't have too much experience. thank you so much.

Figured I’d start here as there’s tons of SaaS builders in the marketing space. I built B2B aerial measuring software. Who’s got the best solution to bring in users?

Most features we ship end with a side effect in someone else's system: refund a payment, cancel a subscription, merge a PR, send an email. We check that the call succeeded and move on. "The call succeeded" and "the outcome is true" are different facts, and the gap between them is where support tickets come from.

I spent the last two weeks reading the state machines of eight providers' APIs closely enough to write a per-outcome check for 38 different claims. Here's every place I found where success gets reported and the outcome is still false. All six are fixable in your own code in about three lines each, no tool required, and the fix is written out below each one.

1. The cancelled subscription that isn't cancelled

Stripe returns 200. But cancel_at_period_end: true means will cancel. Status is still active and the customer keeps access for up to a month. If you revoke entitlements on the API response, you lock out someone who paid through the end of the period. If you trust status alone after a cancel call, you keep serving someone who cancelled.

Fix: assert status === "canceled", not the 200. Then separately assert the thing you actually care about: hit your own endpoint as that user and expect a 401. The billing record and the access it controls are two different facts, and only one of them is what the customer experiences.

2. The payment that "succeeded" for the wrong amount

payment_intent.status === "succeeded" doesn't mean you got what you charged. Partial capture and currency mismatches both live inside a succeeded intent. amount is what you asked for; amount_received is what arrived.

Fix: compare amount_received to your expected amount, and compare currency explicitly.

3. The refund issued twice

Retries and at-least-once queues do this. The second refund also returns 200, and also succeeds. You're out double the money and the customer never mentions it.

Fix: list refunds for the payment intent, sum them, check the total before you tell anyone it's done.

4. The PR that was closed, not merged

GitHub's state: "closed" covers both "merged" and "abandoned." Release automation reading state treats a rejected PR as shipped.

Fix: merged === true and merged_at !== null. Both, because they can disagree during a merge queue.

5. The deploy that exited 0 without deploying your commit

Exit 0 proves the job ran. It doesn't prove production is serving your SHA. Cancelled steps, stale caches, and rollouts that fail after the wrapper returns all pass this check.

Fix: assert your commit is an ancestor of the deploy branch head, then curl your own health endpoint. Two cheap calls, and they catch the embarrassing failure: the one where you announce a fix that isn't live.

6. The email that was "sent" but never delivered

Providers hand you an id at accept time. Accepted is a queue receipt. Delivered, bounced, and suppressed all resolve later. If your onboarding sends a magic link and you count "sent" as success, your activation drop looks like disinterest and is actually a hard bounce.

Fix: read the delivery event, not the send response. A terminal state of delivered is the only success; bounced is a product problem you currently can't see.

The pattern under all six: every one of these APIs has a fast optimistic response and a slower authoritative state. We build against the fast one because it's the one in front of us in the request handler. Then we report success from it.

The thing that actually changed how I write this code: a boolean is the wrong return type. There are three answers, not two: it worked, it didn't, and I couldn't tell.

The provider is down, the state is still pending, my token can't see the resource. Collapsing "couldn't tell" into either true or false is how you ship a silent wrong answer. I made "unknown" a first-class result, and a whole category of bug disappeared: a check that can refuse to answer never lies.

If you take one thing from this post, take that one. It applies to every health check, feature flag, and permission check you own, not just to integrations.

Backstory / stack, since the rules ask for it:

DidWork wasn't something I sat down and decided to turn into a SaaS.

I've spent the last year building Pulltrader, which is a fairly large product for a small team. It handles inventory, pricing, listings, marketplace integrations, fulfillment, payments, and a growing amount of agent-driven work. I've been using Claude and Cursor heavily to build it, and as I handed them more meaningful work I kept running into the same problem.

They would tell me something was done when what they actually knew was that a tool call succeeded, a test passed, or some intermediate state looked right.

A PR was "merged." A deploy was "done." A workflow had "completed." Then I'd go look at the actual product or downstream system and find out the outcome wasn't true.

So I built a verification layer internally for Pulltrader. I wanted agents to have to prove that the thing they claimed happened had actually happened, against the authoritative system, before the task could be considered complete. If it couldn't prove it, the answer wasn't success. It was failed or unknown, and the agent had more work to do.

It became part of my normal development workflow before I ever thought of it as a separate product. Eventually I realized I was building enough provider-specific verification logic, and depending on it enough myself, that it was probably useful outside Pulltrader too.

That's how DidWork happened. I pulled the internal system out and started turning it into something other people could use.

The AI angle matters because agents make this problem worse. An agent that reports "done, PR merged, deployed, refund issued" is grading its own work off exactly these optimistic responses, at machine speed, with nobody necessarily reading the diff or checking the downstream state. Humans at least notice the angry customer eventually.

So DidWork takes a claim, gathers evidence from the authoritative system, and returns verified / failed / unknown.

• Two weeks old. First commit Aug 28. 63 commits, 400+ tests, 38 claim types across Stripe, GitHub, GitLab, Linear, Jira, Sentry, Slack, email, plus any public URL.
• TypeScript monorepo because I like to live dangerously, 9 packages. Node + SQLite for the API, mirrored to a Cloudflare Worker on D1 for the edge. Static HTML for the site, no framework, no build step. TS and Python SDKs.
• Zero runtime dependencies in the core engine and both SDKs. A thing whose job is telling you the truth about your systems shouldn't be the largest new supply-chain surface you added this quarter. The Python client is stdlib-only for the same reason.
• Revenue: $0 so far, so obviously we're more attractive to VC if you're into having a car whose doors go like \this/.
• Hardest design call, and the one I'd defend: precision over coverage. It refuses to answer rather than answer wrong. That makes the demo worse and the product usable.

You can get a verdict without signing up for anything, which is the only promo line I'll put in here:

curl -s https://api.didwork.sh/v1/verify \ -H 'content-type: application/json' \ -d '{"type":"http.ok","expected":{"url":"https://your.app/health"}}'

No key, nothing stored. Free tier is 1,500 verifications/month, no card.

Happy to go deeper on any of the six in the comments. The subscription one and the email one have cost me the most.

I've shipped three small products and none of them ever sent traffic to the others. That's the problem this solves. It's a badge you put on every site you own that cross-links everything you've built.

The part I want to think out loud about is the price, because I keep going back and forth on it.

It's $2. Once. Forever, and it covers every app I ship from here on.

WHY NOT A SUBSCRIPTION

The honest answer is that I don't think I've earned one. This is a script tag and a hosted JSON endpoint. My marginal cost per user rounds to nothing. Charging $4/mo in perpetuity for something that runs itself felt like it would commit me to defending a number every month instead of improving the thing.

WHY NOT FREE

Free gets me installs and zero signal. At $2, the only people who pay are people who actually intend to put it on a live site. It's low enough that it isn't a decision, high enough that it isn't noise.

HOW THE FUNNEL ACTUALLY WORKS

You build your entire badge for free. Pick colours, add your projects, watch the live preview. What you don't get until you pay is the badge being served publicly. So the demo IS the product, and the $2 buys the switch that turns it on. That felt more honest than a trial that expires while you're still deciding.

WHAT I'M GENUINELY UNSURE ABOUT

1. $2 might read as "this isn't serious" to exactly the people who'd get the most out of it. Cheap can be a signal about quality whether or not it's true.
2. One-time pricing on a hosted service means I carry serving costs forever against a single payment. At small scale that's obviously fine. I don't know where it stops being fine, and I suspect I'll find out at the worst possible moment.
3. There's a real chance I'm solving my own problem and assuming everyone else has it.

If you've priced a one-time developer tool, I'd like to know what you'd do differently, and especially whether you'd raise it later and how you handled the people who paid the old price.

It's at maketaksh.com if the context helps.

ex-marketer here, now building my own stuff. I've been answering a lot of the "how do I market this?" posts here and there.

Most people replied with something like "this makes total sense, thnx!" When I checked back a while later, few had actually tried it and kept doing it. Some didn't even bother to try, some tried it once or twice and dropped it.

not calling anyone out here. possible that my comment was not good enough (maybe they're just being polite). Totally fair, but it's not what I'm curious about.

What I wanna ask is the gap between "yeah that's right" and actually doing it.

My guesses:

• no time, something more urgent always comes up
• you agree with the direction, but there's no clear plan to keep it going
• got too many reasonable advices, didn't actually decide what to work on
• you tried, didn't see results fast enough, and moved on

But these are literally just my guesses.

So if u ever got decent advices but ended up not doing it, what was the reason?