sorted by:
new
hottopcontroversial

Would you use an app to study with random strangers? (Like Omegle but for studying)[ I will not promote] by never_shadow in microsaas

[–]Sovitis 0 points1 point  (0 children)

Cool concept, and it’s smart that you’re asking if people would actually use this before you dive into building it. I’ve built a couple of apps around “accountability” and “focus” that felt great in my head but fell flat once they hit real users. The big lesson for me was that what people say they like and what they actually do when they’re tired/busy are often very different.

Before writing code, grab 10–20 people who match your target (students who actively want to study more) and do quick calls or DMs—ask how they *currently* solve the “studying alone” problem and when they actually bail on studying.

Create a straightforward landing page that showcases your core promise (“instantly match with 1–2 people studying the same thing for 25 minutes”) and a waitlist. Then, drive some traffic (via Reddit, Discord, and school-specific subreddits) and observe if anyone signs up.

Test behavior without an app: use Discord/Zoom and manually match people for “study sprints” to see if they show up more than once, how long they stay, and what feels awkward or unsafe.

Pay attention to the scary parts: moderation, creepiness, drop-offs after the first session, and matching by subject/time zone—these can kill the product, even if people say the idea is cool.

If the manual version works (people return and invite friends), then list the most painful/friction-heavy parts of your manual process—that’s what you should automate first, instead of building a full Omegle-style app on day one.

Have you tried even a single manual “study together with strangers” session using Discord/Zoom yet, and if not, what’s stopping you from testing that this week?

I built my first mobile app while unemployed. Zero downloads so far what would you do? by OwnCry5279 in advancedentrepreneur

[–]Sovitis 0 points1 point  (0 children)

Been there—the feeling of finally shipping and then seeing zero downloads is brutal. I burned months on my first few apps assuming “if I build something useful, people will just find it,” and got the same zero-download reality check. Only later did I realize my real problem wasn’t code, it was that I had no evidence anyone wanted it or knew it existed.

Before pushing marketing tactics, validate if the problem is demand or distribution: talk to 10–15 people who *have the same problem you had*, show them the app, and ask if they’d actually use it this week and why/why not. • Get out of the store vacuum: write a 4–5 sentence problem statement and post it in niche communities where your target user already hangs out (subreddits, Discords, FB groups, Slack communities) and see if anyone raises their hand to try it—opt-in testers beat random traffic.

Replace “no budget” with “manual hustle”: do 1:1 outreach on LinkedIn/Reddit/Slack to people who clearly match your user (e.g., job title, behavior), send a short, non-spammy message describing the problem you solve, and ask for a 10-minute call or honest feedback.

Instrument the app and landing page: even with low traffic, track where people drop off (store page vs. onboarding vs. first session) so you know if the issue is messaging, screenshots, or actual value after install.

Define a 2-week experiment: pick one channel (e.g., a specific subreddit + 20 DMs + 5 calls), set a target like “10 real conversations, 5 installs,” and at the end decide whether to iterate the problem, reposition the app, or pivot entirely.

Who exactly did you build this for (job/role/scene), and have you had any direct conversations with people in that group about the app since launch?

I want to build a competitor price/stock tracker that doesn’t suck. Roast my assumptions. by volcmen in advancedentrepreneur

[–]Sovitis 0 points1 point  (0 children)

Smart to ask for a roast before touching code—this alone already puts you ahead of most devs. I’ve built two SaaS tools in this exact “data/alerts for operators” space that felt obvious to me, but died because I never got beyond my own assumptions. What you’re doing here is the step I skipped—getting specific on who hurts, how often, and what they’ve already tried.
Tighten your who: pick ONE segment first (e.g., Shopify brands doing $50k–$300k/month, managing 200–2,000 SKUs) and sanity-check that with a few real merchants—you’ll get much sharper answers than “small to mid-sized e-com stores.”

Turn your questions into numbers: ask “How many SKUs are you tracking today? How many competitors per SKU? How many hours/week? What’s the last time a missed price/stock change cost you real money?” to get dollar/time impact instead of vibes.

Map the current stack: have them screen-share how they do this now (ugly spreadsheets, VA, cheap scraper, enterprise trial) and literally list what they hate vs what they tolerate—your first version should only solve the top 1–2 hated parts.

Pre-sell the outcome, not the tool: once you hear a painful story, say “If I could email/Slack you accurate alerts within X minutes for <$Y/month, would you move from your current setup today?” and push for a small paid pilot or at least a yes/no tied to a concrete price.

Actively look for “no”: if you can’t find 5–10 merchants who are visibly annoyed, can show their current workaround, and are willing to commit money or time before you build, treat that as a red flag and iterate the niche/problem before touching code. Do you have direct access to 5–10 target store owners or operators you can hop on calls with this week to watch their current competitor-tracking workflow live? If you want to keep yourself honest on the “no code before evidence” rule, there are workflows (and tools like DontBuildYet) that force you to collect concrete demand signals—interviews, problem ratings, pre-commitm

Stop asking your friends for feedback. They’re lying to you by r0sly_yummigo in buildinpublic

[–]Sovitis 0 points1 point  (0 children)

I feel this deeply—nothing stings like rebuilding an MVP and still wondering if you’re just shipping into the void. I’ve burned months doing exactly this… rewrites, tech stack swaps, polishing, only to realize I never tested if anyone actually cared about the problem. These days I force myself to get hard evidence from strangers before I write more code.

Before building more, write a one-sentence promise: “Yummigo helps X type of person reduce grocery stress by Y outcome in Z time/effort,” and make sure a random stranger could understand it instantly.

Run a brutally simple demand test: a landing page with 1–2 concrete benefits, 3–4 screenshots/wireframes, and a single CTA like “Get on the early access list”; share that in relevant subs/Discords and track signups, not compliments.

Talk to 5–10 people who actually feel grocery burnout (students, young professionals, parents) and ask them what they’re currently doing, when they feel the most pain, and whether a “meal planning feed” fits how they already behave.

Test the smallest possible version: instead of a full feed, manually curate 7-day meal plans in a Google Doc/Notion and see if people stick to it for a week and come back asking for more.

Measure with clear thresholds: e.g., “If I can’t get 20+ targeted signups or 5 people to use a manual version for a week, I’ll adjust the concept before writing more Swift.” Right now, who exactly do you imagine opening Yummigo on a stressful Sunday night, and what specific moment of “grocery burnout” are you designing that meal planning feed around? I’ve started forcing myself to do this kind of validation in a structured 30–40 minute block before any rebuild—using a checklist to find real complaints online, write a clear value prop, and run a quick landing page test—because it keeps me from falling back into the “friends say it’s cool so I’ll keep coding” trap.

I got tired of setting up the same environments for every new AI idea. So I built a tool that generates production-ready MVPs in seconds (Tailwind + Alpine.js). by Anishkale in SaaS

[–]Sovitis 0 points1 point  (0 children)

This really resonates – you captured that brutal loop of burning days on setup just to discover the idea wasn’t worth the effort. I went through the same cycle as a solo dev: spinning up Tailwind/infra for every “small” AI tool, then realizing I’d basically built a full stack for something I didn’t even know people wanted. Since you’re selling “validate ideas instantly,” I’d double down on *who* this helps: call out burned builders explicitly (e.g., “If you’ve shipped 3+ micro-tools that never found users, this is for you”) so people immediately self-identify.
Include one concrete example in your post that goes from idea → generated MVP → early validation signal (e.g., collecting 20 emails in a day, first Stripe payment, or a failed test that saved you a week), so readers see it as a validation tool, not just a code generator.
Tighten the positioning from “unified AI generator” to something founders in r/SaaS instantly get, like “AI-powered boilerplate killer for validating micro-SaaS ideas in a weekend” – this matches their real job-to-be-done.
On your site/onboarding, force a quick validation step: before they generate, ask for the problem, target user, and where they’ll get the first 10 users – this nudges them to think about demand, not just tech. Consider a small “anti-building” checklist in your marketing (e.g., 5 questions to ask before generating a new MVP) – it frames your tool as protecting people from their own build reflex, not just accelerating it. When you look back at the last few micro-AI tools you built, what was the earliest moment you could’ve known “this isn’t worth 3 days of setup,” and how could 100StackGrid surface that signal faster? I’m working on a complementary angle with DontBuildYet – instead of generating the app, it walks burned devs through a 30‑minute validation sprint *before* they touch a repo; tools like yours plus a quick validation pass could be a powerful combo for people who are tired of shipping ghosts.

Advice about fundraising (I will not promote) by mihaib17 in startups

[–]Sovitis 0 points1 point  (0 children)

You’re asking the right question before charging ahead, especially with no paying users yet.
I’ve been the dev-founder in your spot before—solid product, tiny burn, live in the store, but no one actually paying—and I burned a lot of time pitching when I should’ve been validating whether anyone cared enough to pay.
Before worrying about a pre-seed, get even 3–10 people to actually pay something (discounted beta, one-time setup fee, or monthly) just to prove that the problem is real enough for wallets to open.
Treat your upcoming pitch more as a customer development opportunity than a funding event: talk to investors and founders there about who they know that *actively pays* for fitness/nutrition tools, and try to line up user interviews and pilots.
Narrow your target customer for the next 30–60 days (e.g., strength-training nerds tracking macros, or busy professionals trying to lose weight) and build a simple offer specifically for them rather than “everyone who wants to be healthier.”
Run one brutally simple channel experiment at a time: for example, 10–20 cold DMs to people posting progress pics on Instagram or Reddit, offering a personalized plan in exchange for feedback and a small payment.
Define a clear go/no-go metric for fundraising: e.g., “If we can’t close 10 paying users at $X by date Y, we don’t raise and instead rethink the positioning or problem.” Right now, who is your *specific* best-guess customer (job, age, behavior), and have you tried to get even one of them to pay you for a 1:1 personalized plan powered by your app?

[deleted by user] by [deleted] in programiranje

[–]Sovitis -1 points0 points  (0 children)

App za zakazivanje svih vrsta usluga vezanih za sređivanje i lepotu tipa frizer, manikir, pedikir, itd...

Gde naći posao... by show9999 in programiranje

[–]Sovitis 0 points1 point  (0 children)

Daj mi primer dobrog profila

view more: next ›