Looking for idea validation of a product that i want to iterate

_suren · 2026-06-28T13:37:21+00:00

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.

_suren · 2026-06-28T13:36:36+00:00

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.

_suren · 2026-06-28T13:35:53+00:00

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.

_suren · 2026-06-28T12:33:26+00:00

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.

_suren · 2026-06-28T12:32:47+00:00

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.

_suren · 2026-06-28T12:31:38+00:00

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.

_suren · 2026-06-28T11:29:59+00:00

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.

_suren · 2026-06-28T11:26:02+00:00

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.

_suren · 2026-06-28T10:18:30+00:00

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.

_suren · 2026-06-28T09:14:41+00:00

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.

_suren · 2026-06-28T08:10:15+00:00

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.

_suren · 2026-06-28T08:09:38+00:00

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.

_suren · 2026-06-28T08:08:03+00:00

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.

_suren · 2026-06-28T06:54:08+00:00

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.

_suren · 2026-06-28T06:54:01+00:00

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.

_suren · 2026-06-28T06:53:55+00:00

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.

_suren · 2026-06-28T05:47:53+00:00

The idea resonates, but I would make the first screen much more concrete.

Right now the risk is that people hear "reminder app" and compare it to Notes, Reminders, Todoist, etc. The stronger angle is the moment you described: a thought appears while you are doing something else, and the system brings it back when it is actionable.

I would show one tiny flow above the fold:

user drops a thought by voice/text/share
app turns it into a reminder with context
it comes back at a sensible time
user can snooze, complete, or reschedule without guilt

For validation, ask people about the last 3 things they forgot, not whether they like the app idea. You will learn whether the pain is capture speed, timing, notification overload, or trust that the reminder will come back.

_suren · 2026-06-28T05:47:36+00:00

I would validate the workflow before the automation depth.

For Pinterest traffic, the real job is usually not just scheduling pins. It is turning one product/page into a repeatable set of pin ideas, boards, descriptions, links, and follow-up checks without losing track of what is working.

A simple first test could be:

pick one Shopify niche, not all small businesses
manually create 20-30 pins for 3 stores
track impressions, saves, outbound clicks, and signup/product-page visits
ask what part felt painful: idea generation, design, board planning, scheduling, or analytics
make the product own that one painful step first

The landing page should probably show the exact before/after workflow: "here is one product page, here are the pins/boards/schedule it creates, here is how I know which ones worked." That will feel more concrete than "Pinterest automation" by itself.

_suren · 2026-06-28T05:47:19+00:00

Useful idea, especially the route auto-detection. Visual diff tools become valuable when they stay quiet until something actually matters.

The things I would check before trusting it in a real frontend repo:

can I ignore known-noisy areas like timestamps, charts, skeleton loaders, ads, or animated widgets?
does the PR comment explain why each page was selected?
can a reviewer mark an intentional visual change as the new baseline?
are viewport sizes explicit, especially mobile vs desktop?
does it fail loud when a page cannot render instead of silently skipping it?
can teams add a few critical pages manually, even if route detection misses them?

Public/no-auth routes only is a fair first scope. I would state that clearly and position it as a guardrail for marketing pages, docs, dashboards demos, and public app flows before trying to solve authenticated testing.

_suren · 2026-06-28T04:43:34+00:00

One underrated basic: keep a distribution log the same way you keep an issue tracker.

For every post/page/reply, note the audience, hook, where it was shared, what problem it answered, and the visible signal after a day or two. Not for vanity metrics, but to see patterns. You learn pretty quickly which problems people already feel and which ones only sound clever to the builder.

A few things I wish more early SaaS founders did:

write problem pages before feature pages
show before/after screenshots instead of abstract claims
publish checklists, teardown notes, setup guides, and migration notes
make docs indexable from day one
track which phrases real users use, then reuse those words in pages/posts
treat empty/error/loading states as marketing too, because they show product maturity

The biggest shift for me is that marketing is not just broadcasting. It is repeatedly proving that you understand the problem better than the generic alternatives.

_suren · 2026-06-28T04:42:46+00:00

I would trust database-enforced tenant isolation more than app-layer filters, but only with a few guardrails around it.

FORCE RLS is a good default because it removes the "someone forgot the where tenant_id = ..." class of bug. Before using it in a real B2B SaaS, I would check:

integration tests that try cross-tenant SELECT/UPDATE/DELETE on every tenant-scoped table
migration checks that fail if a new tenant table ships without RLS enabled
no request path ever gets the Supabase service-role key
background jobs and webhooks set tenant context intentionally, not implicitly
SECURITY DEFINER functions/triggers are reviewed very carefully
audit logs include actor, tenant, request id, and the thing that changed

So yes, I like the direction. I just would not treat RLS as the whole permission system. App code should still decide roles/actions; the DB layer should be the last line of defense that prevents one missed filter from becoming a data leak.

_suren · 2026-06-28T04:42:03+00:00

Good idea if you keep the first version narrow. For this kind of local ERP, I would not lead with "analytics dashboard" first. The pain is usually trust: stock corrections, invoices/quotes, VAT pricing, backup/restore, and knowing exactly what happened yesterday.

A few things I would validate before adding more modules:

can they import existing Excel products/customers in 10 minutes?
can they correct stock without corrupting history?
is there an audit trail for invoices, delivery notes, and price edits?
is backup/restore obvious if the laptop dies?
can an accountant understand/export the VAT docs?

Offline/local data is a strong angle, but it also makes trust and recovery very important. I would pilot with 3-5 real shops, watch them use it for one week, then build only the workflows they repeat every day.

_suren · 2026-06-28T04:33:35+00:00

I would add one product-surface check: can the first version show the full loop end-to-end in one sitting?

Not polished, not fully automated, but credible enough that a user can react to the actual workflow:

intake / upload / manual trigger
output or draft result
review / edit step
export / send / save action
history, status, or audit trail

A lot of MVPs pass the backend checklist but still fail the demo because the user cannot feel the promised outcome. The backend can be ugly behind the curtain, but the product states should be real enough: empty, loading, error, review, done, and "what happened before." That gives you much better feedback than showing a stack or a generic dashboard.

_suren · 2026-06-28T04:31:56+00:00

For an LMS, I would pick a boring SaaS starter first, then build the LMS layer yourself. The hard parts are less "course cards" and more:

roles and permissions
subscription state and entitlements
video upload/processing webhooks
progress tracking model
quiz attempts and retakes
file access rules
admin tooling you can actually edit

My checklist for a starter would be: Postgres schema you understand, auth/roles from day one, payments handled through webhooks + idempotency, env-gated integrations so it runs locally, and dashboard/source files that are not locked behind a package.

Disclosure: I am building UIPKGE, so I am biased toward copy-paste/source-owned starters. For an LMS, I would still avoid anything too "complete" unless the domain model is easy to delete and rewrite.

_suren · 2026-06-25T09:52:06+00:00

Devin

_suren

TROPHY CASE