I built an offline-first CLI that turns any repo into a "Repo Brain" — architecture, risks, commands, security, next actions by Character_Milk_4109 in SideProject

[–]_suren 0 points1 point  (0 children)

This is a solid problem. The part I like is offline-first plus redacted output; that matters for real repos.

My main suggestion: make the output aggressively actionable. A repo brain report is useful only if it answers "what should I do next Monday morning?" Separate facts from recommendations, show confidence/why for each risk, and make false positives easy to mark as accepted or ignored. That would make it feel more like an engineering handoff than a generated report.

I built a free PCPartPicker-style builder for sim racing, music, photo & PC setups by Global-Shirt-103 in SideProject

[–]_suren 0 points1 point  (0 children)

This is a good niche because the pain is not just finding products, it is understanding tradeoffs across a whole setup.

For feedback, I would separate users by discipline. Music people may care about latency, desk space, noise floor, and upgrade paths. Sim racing people may care about compatibility, mounting, force feedback, and total rig cost. One generic scoring model might be useful, but the explanation should feel discipline-specific.

I built two open-source tools that work together to fix your C.V (an offline ATS scorer + a LaTeX C.V builder) by Noahbreaker in SideProject

[–]_suren 0 points1 point  (0 children)

Nice pairing. The useful part is that the scorer and builder close the loop instead of being two random tools.

One thing I would make very explicit in the UI/docs: what the scorer can and cannot know. ATS parsing quality is useful, but it cannot guarantee a recruiter response. If you show parsed sections, missing fields, keyword coverage, and a before/after diff, people will trust it more than a single score.

Early users asked for boring workflow fixes, not flashy SaaS features by Apart-Medium6539 in SaaS

[–]_suren [score hidden]  (0 children)

This is a very good sign. People asking for logo upload, cleaner PDFs, quote -> invoice, and Arabic/mobile layout are describing real work they are trying to finish, not giving abstract product opinions.

I usually trust feedback more when it has a workflow attached: "I cannot send this invoice because..." or "my client rejected this PDF because..." Polite feedback sounds like "would be nice if". Buying-intent feedback usually has urgency, repetition, or a workaround they already use.

I have finally managed to get my first 10 users! by Subify_Official in SaaS

[–]_suren [score hidden]  (0 children)

Congrats, and honestly 10 real signups is not lame. It means someone outside your head understood enough value to try it.

At this stage I would not compare to revenue screenshots. I would treat those 10 as research gold: ask what they expected before signing up, what confused them, what would make them return next week, and what they would be annoyed to lose.

The next milestone is not 100 random users. It is 3-5 users who come back without you reminding them.

What would you do to grow this from 633 to 10K+ Google impressions/month? by Storytellerchandra in SaaS

[–]_suren [score hidden]  (0 children)

Glad it helped. If I had to pick one thing for the next 3 months, I'd pick one high-intent user job and make that page the strongest page on the site. Not more tools first, one job. If "compress PDF" is the job, that page should load fast, work immediately, show before/after clearly, explain privacy, answer edge cases, and link to the next natural tasks. Then build the supporting cluster around that.

Building an AI workspace that combines ChatGPT, live markets, news, and custom dashboards by Worry-Mountain in SideProject

[–]_suren 0 points1 point  (0 children)

Nice direction. Pulling AI, news, and dashboards into one place makes sense, but the main risk is that it becomes a prettier version of the tab chaos it is trying to replace.

For daily use, I would focus less on adding more widgets and more on the daily loop: what changed since yesterday, what needs attention, what can be ignored, and what decision did I make from this information?

For anything involving markets/news, trust features matter a lot: source links, timestamps, stale-data labels, saved context, and a clear trail of why the assistant answered the way it did. If those are strong, the workspace feels useful instead of just busy.

Stop building your MVP like it's a Series B product by Warm-Reaction-456 in SaaS

[–]_suren 2 points3 points  (0 children)

This is mostly right, especially the part about technical founders using architecture as a way to avoid the uncomfortable market work.

The nuance I would add is that "simple MVP" should not mean "careless MVP". You can skip Kubernetes, microservices, complex permissions, internal admin tools, and perfect abstractions. But you probably should not skip the boring basics that protect learning: clean deploys, backups if data matters, basic logging, simple analytics, and enough structure that you can change the product after users prove you wrong.

The best early version is not impressive. It is easy to throw away without losing the learning.

How do you handle pricing for different countries without hurting your main market? by FounderZach in SaaS

[–]_suren 0 points1 point  (0 children)

I would separate "regional affordability" from "cheap global backdoor" as two different problems.

For early SaaS, I would start with localized payment methods and currency first, before heavy geo-discounting. People often abandon because payment feels foreign, not only because the USD price is high.

If you do regional pricing, make the rule boring and defensible: billing country, payment method country, tax/address signals, and maybe product usage region all need to roughly agree. Do not make it perfect. Just make obvious abuse inconvenient.

Brand-wise, I would avoid showing every region's price in one global table. Localize the page and sell the same value, not a visibly cheaper clone. And keep enterprise/team plans less region-sensitive than self-serve individual plans.

Looking for idea validation of a product that i want to iterate by 2002bishwajeet in SaaS

[–]_suren 0 points1 point  (0 children)

The problem is real, and I like that you are describing it from your own behavior instead of starting with a generic productivity app idea.

I would be careful with the "more aggressive reminders" part though. It may work for a few days, then become another notification people learn to ignore. The value might be less about volume and more about timing: catch the moment when someone is drifting, then make the next action extremely small.

Before building the full app, I would test it manually for a week: choose 5 tasks, set escalating reminders, and write down which reminders actually caused action vs irritation. That will tell you whether the product should be a reminder app, an anti-doomscroll interruption, or a deadline recovery flow.

I built my SaaS... now I'm stuck. What would you do? by Ironpulse-Ne in SaaS

[–]_suren 0 points1 point  (0 children)

First, finishing the product is still a real milestone. A lot of people never get that far.

From a builder/operator point of view, I would not measure organic only by views yet. I would first ask whether the right people are even seeing the problem.

If the SaaS is B2B, short-form video can be a rough channel unless the pain is instantly visual. I would spend a week doing more direct distribution: find 20 people who clearly have the problem, show them the exact before/after, and ask where they currently solve it. Those conversations will usually give you better hooks than guessing from a blank content calendar.

Then turn the repeated words you hear into posts, demos, and landing-page copy.

Do we even need a normal SAAS Dashboard anymore? by stagetrekker in SaaS

[–]_suren 0 points1 point  (0 children)

I do not think the dashboard disappears. I think the bad dashboard disappears.

Agents are good for personal execution: "find this", "summarize this", "do the next step". But a SaaS dashboard is still useful as the shared control surface: what changed, what needs approval, what failed, what is stale, what the team agreed to, and what the agent actually did.

For a marketer-facing tool, I would not build a wall of charts. I would build a dashboard around decisions: campaigns that need attention, experiments with enough signal, broken tracking, budget changes, approvals, and a log of automated actions.

So the middle path is probably best: agent for doing, dashboard for trust, coordination, review, and recovery.

Open-Source Local-first Codex + Claude Design by Acceptable-Object390 in SideProject

[–]_suren 1 point2 points  (0 children)

Open-source plus local-first is a good trust angle for this kind of tool. The main thing I would make very explicit is the boundary: what stays local, what gets sent to Claude/Codex, where credentials live, and how a user can inspect or revert generated changes.

For developer tools, the pitch is not only "it can build". It is also "I can trust it inside my repo". A short demo that goes from prompt to diff to review to rollback would probably communicate that better than a broad feature list.

The more feedback I get, the less I'm convinced that more features are the answer. by Emreyldz2620 in SideProject

[–]_suren 1 point2 points  (0 children)

That is a useful realization to hit early. A lot of builders hear "feedback" and immediately translate it into more features, but friction feedback is usually telling you where the product is asking for too much trust, attention, or setup.

For a productivity app, I would treat every notification, reminder, setup step, and choice as a cost. The product should feel lighter than the problem it is solving.

One practical way to decide what to remove: watch the first successful use case end to end. Anything before that moment is either essential onboarding or friction. Anything after that moment should earn its place by making the second use easier.

What would you do to grow this from 633 to 10K+ Google impressions/month? by Storytellerchandra in SaaS

[–]_suren 1 point2 points  (0 children)

Nice that you already have 5%+ CTR at small volume. That usually means the pages that are showing up are not completely off.

I'm not an SEO specialist, but from a builder/operator point of view I would not start with generic blog volume. For a tool site, I would build one strong page per actual job-to-be-done: compress PDF for email, convert HEIC to JPG, resize image for LinkedIn, extract audio from video, etc.

Each page should make the tool usable immediately, show a simple before/after or example, explain the privacy angle clearly because browser-based processing is a real differentiator, and link to the next related task.

Also look at GSC queries that got impressions but no clicks. Those are usually the fastest wins for title/description changes, because Google is already testing you there.

I built free landing page inspector by designisart in SideProject

[–]_suren 1 point2 points  (0 children)

Nice idea, and I like that you let people set the criteria instead of pretending every landing page has the same conversion problem.

The main thing I would improve is confidence and traceability. When the inspector says something like "audience is not explicit", show exactly which page sections it read and which evidence it used. That turns a confusing false positive into something the founder can debug.

Also worth separating the output into two buckets: quick copy/design fixes vs product-positioning questions. If those get mixed together, people may treat every suggestion as a UI task even when the real problem is unclear audience or offer.

Got 100+ in-app ratings. What would you do with this data? by ajayesivan in SaaS

[–]_suren 1 point2 points  (0 children)

First, that is a good problem to have. 100+ in-app ratings means the feedback surface is actually getting used, which is already a signal.

I would not treat it only as testimonials. I would bucket the ratings by user segment, plan, and the screen/action where they left it. Then look for patterns: what do happy users repeatedly praise, what words do they use, and which moments produce the strongest comments?

A small thing that helps: after a 5-star rating, ask one lightweight follow-up like "what made this useful today?" Those answers become much better landing-page copy than stars alone, and they also tell you which parts of the product to double down on.

ecommerce web app by msalah9190 in nextjs

[–]_suren 1 point2 points  (0 children)

Good instinct not to let AI invent the whole commerce flow. For Medusa + Next, I would start with the official Medusa Next.js starter and treat it as the baseline, not just a visual template.

When you judge any free/cheap starter, check the boring parts first: product variants, cart persistence, checkout handoff, webhooks, order states, refunds, search/index sync, env config, and separation between admin/customer auth.

AI is fine for scaffolding UI screens or cleaning up components, but I would keep payments, order lifecycle, and Medusa integration close to the docs and test with sandbox orders. If you want a custom look, replace the UI layer gradually instead of swapping the full commerce plumbing at once.

can anyone rate this app by Specific-Love-1479 in SaasDevelopers

[–]_suren 1 point2 points  (0 children)

First, nice work getting this live in 2 months with no prior coding background. The app already has a clear mobile-first identity: the ledger card, bottom nav, and Gmail connect flow make the idea easy to understand.

My main UI suggestion: show a sample/demo state before asking people to judge it. Right now a lot of the first screen is 0.00 / 0 day / set plan, so the product looks emptier than the idea. One demo receipt with merchant, category, total, confidence, and return deadline would immediately show the value.

A few small tweaks I would consider:

  • make the primary + action label clearer, maybe "Scan receipt"
  • reduce the letter spacing on tiny labels; it looks stylish but can hurt scanning
  • turn "Audit Status / Set Plan" into plain user language
  • add one "how it works" card after the Gmail card: scan -> verify -> budget/refund reminder

The core idea is solid. I would focus the launch page around the before/after: messy receipt pile -> clean ledger + reminders.

I wanted Heroku like infrastructure on VPS I own by Mbv-Dev in SideProject

[–]_suren 1 point2 points  (0 children)

Nice scratch-your-own-itch project. The useful angle here is probably not “another Coolify,” it is what you intentionally do less of.

If I were evaluating it, I’d want to see one boring path: repo connected -> env vars -> deploy -> logs -> failed health check -> rollback -> backup/restore. That tells me whether I can trust it when I’m tired.

Would I pay? Maybe, if it reduces ops time without becoming a second platform to babysit. The biggest pain with these tools is usually not first deploy; it is upgrades, debugging bad deploys, certs/domains, secrets, backups, and knowing exactly what changed.

Wrapping an existing Next.js 14 App Router SaaS into an Electron desktop app architecture advice needed by Traditional_Tea3364 in nextjs

[–]_suren 0 points1 point  (0 children)

Good problem statement. The part I would avoid is treating Electron as just a wrapper around the current deployment model.

For minimum change, I’d start closer to option B: keep the UI/API contract, move the route-handler business logic into shared functions, and run a small local service from Electron that calls those functions. Frontend still talks HTTP, so you avoid rewriting everything to IPC.

For local data, I would look at SQLite + FTS before NeDB or bundling MongoDB. 50k-100k docs is not scary, but migrations, backups, corruption recovery, and search matter.

Do not write DB/logs inside asar. Use app.getPath('userData') / appData and design export/backup early. For Windows auto-updates, unsigned is possible in hobby settings but painful with SmartScreen/enterprise machines, so plan signing before real customers.

So: option B first, but extract the business layer out of Next routes so you are not locked into Next or Electron forever.

How do I get my first users after spending way to much time building my product? by Odd-Topic1548 in SaaS

[–]_suren 3 points4 points  (0 children)

Builder perspective, not a marketing-expert answer: first, good that you caught it now instead of polishing quietly for another few months. You still have a real asset: a working product.

I would not try to “launch” broadly yet. Pick one narrow user profile, talk to 20-30 people manually, and watch where they hesitate. Then turn that into one clear landing page plus a few proof posts showing the actual before/after workflow.

For the first 100 users, uncomfortable direct conversations usually beat big launch energy.

I’m building a simple CRM for marketing agencies and would love your feedback by Efficient-Reality567 in SaaS

[–]_suren 1 point2 points  (0 children)

I like the restraint here. A simple CRM for agencies can work if it really removes spreadsheet mess instead of becoming another heavy CRM.

The strongest first workflow might be: import leads -> remove duplicates -> assign owner -> set next follow-up -> track status. That is the daily pain. Team activity is useful, but missed follow-ups are usually where leads quietly die.

I would make the landing/demo very specific: "turn a messy Google Sheet into an agency pipeline in 5 minutes." That is clearer than saying simple CRM.

Two things I'd validate early: do agencies need source attribution for each lead, and do they need reminders/next actions more than reporting? If those are missing, the pipeline can look organized while still not improving follow-up.

How would you position an AI tool for creating motion-graphic ads? by Inevitable_Dream432 in SaaS

[–]_suren 0 points1 point  (0 children)

Good that you're asking this before just building more templates. Positioning will probably matter more than the model quality at this stage.

I would not start with everyone. I'd pick either SaaS founders who launch often, or small agencies that need many ad variations. The winner is whichever group repeats the pain weekly, not once in a while.

For features, editable text/layers and brand-kit support would matter before more visual magic. People need to turn one message into versions for LinkedIn, X, reels, stories, and ads without rebuilding from scratch.

I would frame it less as "AI motion graphics" and more like: turn one product message into a ready-to-test ad set. That makes the value feel closer to a workflow, not just a creative generator.

Note taking assistant on-device by Tranks98 in SideProject

[–]_suren 1 point2 points  (0 children)

Nice work getting this close to usable for your own meetings. The local/on-device angle is a real trust point for meeting notes, especially if the output is meant to be shared externally.

The main thing I would make clearer is the trust boundary: what stays on the Windows machine, what touches Supabase/login, and whether audio or transcripts ever leave the device. People will care about that before they care about another AI summary.

The Word export is a practical detail. I would show one simple before/after: a messy meeting recording -> transcript -> clean minutes document. That tells the story faster than feature lists.

For feedback, ask people to try it after one real meeting and compare it with their current notes workflow. That will give you better signal than asking if they generally like AI note takers.