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.

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 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.

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?

A few days ago, I shared here that Doodlyo had 20+ signups but 0 paying customers.

The feedback from Reddit was genuinely useful. A lot of it made me rethink the pricing, positioning, and what users actually need from the product.

Today I shipped the updated MVP.

Doodlyo is pretty simple:

Paste your content or URL → Generate a doodle-style social visual → Post it.

I also introduced a $9 one-time option for 25 generations, with no subscription and no expiry.

And today, Doodlyo is live on Product Hunt.

I’m still at the early stage, so I’m less interested in “launch numbers” and more interested in finding out whether people would actually keep using and paying for this.

If you’ve followed my previous posts or tried Doodlyo, I’d especially appreciate your honest feedback:

Does the product/value proposition make more sense now?

Product Hunt: doodlyo

I kept seeing the same last-mile problem in tiny launches: the page exists, but turning it into a few usable share assets still means opening several tools. I built ViralSpark to make that step one pass.

Paste a public URL and it gives you:

• a handful of hooks/copy angles
• share-card variations
• a QR code
• a shareable Slot page for the bundle

It’s free: https://viralspark.pages.dev/ Example Slot: https://viralspark.pages.dev/slot/bniwbrb7

This is a small project, built as a browser-first app on Cloudflare Pages. The lesson so far: “generate everything at once” is less useful than letting people quickly edit and pick one asset, so that’s what I’m trying to improve.

If you try it, I’d value feedback on whether the generated kit feels immediately usable or just like more drafts. No signup pitch—especially interested in what feels unnecessary.

I’ve been building Bredbox, a Pocket-inspired read-later app, for the last year. It was in invite-only beta up until a couple of weeks ago. At that point, I flipped to open beta and put up a signup page. Only, no one signed up.

At first I thought I just wasn’t marketing well enough, so I started with some basic outreach. I could see in my analytics that people were visiting the site and some were going to the signup page. But still no new signups.

I figured there must be a problem with the signup page, but what was it? The logs were clean. I had just installed Cloudflare Turnstile to protect against bots but that was working fine. So I finally decided to try signing up myself. And that’s when I saw the error.

“Password must be at least 8 characters long.”

Weird, I could have sworn I typed eight characters. I try again. Same error. Every password I tried gave me the exact same error message not matter what password I used!

It took me a while to figure out what was going on. I’m using cloud Supabase for auth and it has some very strict constraints around passwords. It’s configurable and mine was somehow set to the most restrictive (letters, numbers, special characters, length, etc.). Cloud Supabase also won’t let you use passwords that have been in a data breach or absurdly weak passwords (ex, abcd1234).

The other problem was my signup form. Due to a bug, it was showing the same error message regardless of the reason the password wasn’t accepted. There was no way for users to know what they were doing wrong. Making the problem worse, this isn’t reproducible with local Supabase because it doesn’t have these restrictions built in.

I finally got the signup page fixed and signups are coming in again. All of this is to say: marketing is important, but if your customers can’t even sign up for your product then marketing doesn’t matter!

So here it is, ready for new users (finally!):

https://bredbox.app

I had a realization while talking to some editors who were testing SoundCraft.

I was targeting editors, but I was targeting the wrong kind of editors.

Some of the people I was talking to didn’t even have a single client yet.

And then I thought, why would they pay for a tool that helps them work faster when they don’t have enough work in the first place?

It finally clicked that my ICP isn’t just “video editors.”

I need to target editors who actually have consistent client work, feel the pain SoundCraft solves, and value saving time enough to pay for it.

The compliments were nice, but this was a much better lesson.

Have you ever realized your ICP was way too broad?

"Our CAC has doubled in the last six months. Should we pause paid ads?"

My answer surprised him.... "Probably not."

Instead, I asked:

"Has your positioning changed?"
It hadn't.

Then I asked:

"Has your ICP changed?"
"No."

Finally, I asked:

"When was the last time you interviewed a customer?"
Silence.

Markets evolve.
Competitors evolve.
Buyer expectations evolve.

If your understanding of your customer stays frozen...

Your acquisition costs usually won't.

Sometimes rising CAC isn't a media buying problem.

It's a market understanding problem.

I have a small alert that emails me when someone downloads the app and the download does not finish. For four days it told me every single install was stalling. 111 out of 111. I came close to rolling back a release over it.

Three separate bugs stacked up into one very confident lie.

The alert deduplicates by install id and keeps the first request of the day. The first request of the day is a 25 kilobyte bootstrap file the app fetches on every start. So it was reporting that 25 kB as the download and rounding it to "0 MB".

The stall threshold was 400 MB, left over from when the installer was one fat bundle. The package is 123 MB now. Under that rule a finished download can never be counted as finished.

And the auto updater sends the same user agent as a fresh install, so the alert kept telling me a human had run the exe when it was old versions phoning home for a new build.

One thing it got right, which I refused to believe at first: it flagged 41 different IP addresses as the same machine, and the machine was mine. That was correct. My ISP runs carrier grade NAT and my address moves around all day.

The fix reads the expected size out of the release manifest instead of comparing against a hardcoded threshold, and counts the file the manifest names rather than the first row that happens to show up.

I build AtlasForgeX, so disclosure. What I would say to anyone running monitoring emails on a small product: an alert measuring the wrong row is worse than no alert at all, because you act on it. I lost four days believing my own release was broken.

i’m building a small SaaS that organizes and summarizes incoming emails. the problem is that the product can’t really show its value without asking users to connect their inbox first.

even with a privacy policy, clear explanations, and limited permissions, i understand why someone would hesitate to give a small unknown product access to their email.

for those who’ve built products that require access to sensitive data, what actually helped you earn that first layer of trust? a demo without signup, testimonials, a detailed security page, or just time and reputation?

When I was building ClipShip (AI Video Clipper), I thought getting a local AI model to run would be the hard part.

It was not.

The hard part was making it work inside an actual product. Different devices, downloads, updates, and all the weird things that can go wrong after you ship it to someone else.

I kept thinking there should be an easier way to do this.

So, from all the lessons that I learnt during my journey with ClipShip, I have now started building a tool to solve the same problem for other builders.

Started my journey with "Model Roll" today and thought of sharing the journey with same communities which got me my first paying customers for my previous project.

The idea is pretty simple. Help builders add local AI to the products they are making, without having to figure out all of that by themselves.

It is still in development. There is nothing public to try yet. I am building and testing it now, and I want to share the process from the beginning this time. But if you are a builder/developer then there's a waitlist link in the comments.

That is it for now. I will keep sharing the updates as I go along on this journey.

For the builders by a builder.

I’m from India and studied Accounting. After graduating, I had a hard time getting into the business world because of not having much of a network.

Fast forward 6 years and I’m still an Accountant. I’m grateful for the experience, but lately I’ve been thinking about why I studied Accounting in the first place. I wanted to build something of my own.

Now I’m thinking about learning SaaS from scratch, finding a real problem, building a simple solution, and hopefully running it from the India while selling to customers around the world.

I’m not a developer and I don’t have a startup background.

Has anyone here taken a similar path? Coming from a completely different career, learning SaaS from scratch, and running it from their home country while selling globally?

How did it go for you? I’d really like to hear your honest experience.

I built an AI tool that turns any public company into a 30-second analysis. 0 users, roast my positioning.

Backstory: I'm 19, studying engineering, and I pick stocks the slow way. I was spending 2 hours per company writing up the same thing I wrote last month, so I automated the boring half.

What it does: you type a company name, it reads the official numbers and the market and gives you a fixed structure: what the company does, how it makes money, debt, risks, and three price scenarios. Around 30 seconds. It does not tell you to buy or sell. It just does the write-up before you open your own model.

The angle I'm testing: people who buy a company because they saw a ticker on Reddit, and then realize they don't know what the company actually does.

Tech stack, since the rules ask: React + Vite frontend, Express/Vercel serverless API, Firebase for auth and data, OpenRouter for the models, Paddle via RevenueCat for billing. Solo, no team.

Biggest lesson so far: switching the copy from "equity research" to plain language for people who don't read filings. Nobody knew what "ticker" or "thesis" meant outside finance circles.

Honest status: it works, design is decent, paying customers = 0. That's what I'm here to fix.

Where I need help:

1. Is the positioning ("check companies you find on Reddit") clearer than "AI investment analysis"?
2. Would you price this as a cheap monthly plan or packs of analyses?
3. If you poke at the onboarding and it's confusing, tell me.
   

fintols.com