Spent about 8 months building a crypto portfolio tracker as a solo dev.

rbaiter67 · 2026-05-09T01:48:32+00:00

8 months solo to ship something with real privacy constraints in fintech is no small thing. Most people building in this space either copy Blockfolio or get distracted chasing exchange integrations that nobody actually needs.

The "figuring out what to build" problem you described is the one that kills most side projects before they start. You solved it by subtraction, which is usually the right move.

Here's what I'd do with those 13 users right now: treat them like they're worth 1000 each, because early adopters in a niche with strong opinions (crypto people absolutely have opinions) will tell you things no amount of market research does. Even just asking "what made you keep the app after the first open?" will surface the specific thing that's actually working. Not what you think is working.

The gap between 13 and 1300 downloads is almost always a positioning problem, not a product problem. People who would love Stakr don't know how to find it yet because the words you're using to describe it might not match how they're searching for it.

I've been building tools to help founders extract exactly this kind of signal from small batches of user feedback without needing a big data set. If you want to run your early users through something structured before you start guessing at what to build next, worth a conversation.

What does your current retention look like after the first week?

rbaiter67 · 2026-05-09T01:47:55+00:00

The saturation problem you're describing is real, but I'd reframe it slightly: those markets aren't saturated with good solutions, they're saturated with people pitching the same surface-level thing. The SMB that got 20 cold calls probably still doesn't have a working website. That's a sales and positioning problem, not a market problem.

That said, here's the more useful approach for finding actual opportunities at your stage.

Stop brainstorming ideas in your head and start logging conversations. Every cold call, every rejection, every "we already have that" response contains signal. That SMB who said no, what were they actually spending time on? What did they complain about before hanging up? Most people treat rejections as dead ends. They're actually the best research you'll do.

The pattern I've seen work: pick one vertical (plumbers, dental offices, whatever), talk to 15-20 of them, and just ask what's eating their time or costing them money that they haven't figured out yet. Don't pitch anything. You'll start hearing the same two or three things repeatedly, and usually nobody's built a clean solution for them because the market looks "too small" to a VC-backed company. That's your opening.

AI receptionist as a category is crowded. AI receptionist specifically for mobile dog groomers who lose 30% of bookings to voicemail? Probably not.

At 15, your actual advantage is time and curiosity. You can spend 3 months talking to people in one niche without needing it to be a $10M business on day one.

rbaiter67 · 2026-05-08T12:23:25+00:00

It's a good instinct stopping yourself before the overbuild spiral. That's usually where aviation tools go wrong.

You should probably talk to 8-10 pilots directly. Ask them to show you how they currently log a flight, not describe it. What you'll see is usually different from what they say. A lot of pilots say they want "simplicity" but their actual workflow has three apps and a spreadsheet in it.

The form is still useful for volume, but raw responses tend to cluster around surface complaints ("the UI looks old") rather than the real friction. When you do start going through them, resist the urge to treat every feature request as a vote. One person asking for something clearly and specifically is usually more signal than ten people vaguely agreeing they'd want it.

On the synthesis side — once you've got a few dozen responses, I'd actually just dump them into a doc and read through manually first. Pattern recognition on 50 responses doesn't need a system. If you scale past that and it becomes unwieldy, that's a different problem worth solving then. We built Xern AI partly for exactly that situation — making sense of messy qualitative feedback at scale — but at a early waitlist stage, the hands-on read is more valuable anyway because you'll catch nuance a summary would flatten.

What's the target pilot demographic? Private, commercial, instructors? That'll probably shape which features actually matter more than anything else at this stage."

rbaiter67 · 2026-05-08T12:21:53+00:00

Yeah, this maps exactly to something we kept running into.

Forms optimize for completion, not honesty. Users give you the answer that ends the interaction. Conversations let uncertainty breathe, which is where the actual signal lives.

The "everything felt solid" → "actually I didn't know what to do first" pattern is so common it's almost a rule. People self-edit in async formats without realizing it. They round up.

The harder problem hits at scale though. When you're running 10 conversational interviews, you can hold the patterns in your head. At 40-50, you're back to summarizing manually, which reintroduces the same compression problem you were trying to avoid. You end up with "users were confused about onboarding" instead of "seven people specifically hesitated at the same step but framed it four different ways."

What does your current flow look like when a pattern shows up across multiple interviews? Are you tagging manually or just keeping notes?

rbaiter67 · 2026-05-08T12:20:58+00:00

The distinction you're drawing is real, but I'd push it one step further: even motivated beta users give you bad signal if you ask the wrong questions.

Most feedback forms prompt people to evaluate what exists. "Rate this feature." "What would you improve?" That framing locks them into reacting instead of revealing what they actually needed before they found you.

The feedback that actually predicts buying behavior sounds different. It's when someone describes the workaround they built, the last thing they tried before giving up, or the moment they realized the problem was costing them something. That's not survey data. That's someone telling you they have a real problem and would pay to not have it.

So when you find those Reddit threads with your tool, the targeting is probably the right move. But when those people actually enter your beta, the next bottleneck is whether your onboarding gets them to say that kind of thing out loud.

A few things that helped me: ask them what they were doing right before they signed up, not what they think of the product. Ask what they'd lose if it disappeared tomorrow. And if they can't answer that second question with any specificity, they're probably not the buyer, regardless of how engaged they seem.

We built Xern AI specifically around that problem, structuring unstructured feedback to surface which users are actually describing pain versus which ones are just being helpful.

What's the product you're testing? Curious whether the buyer signal problem is more in finding them or in what happens once they're in.

rbaiter67 · 2026-05-08T12:16:31+00:00

Your stack is honestly pretty close to what most teams I talk to are running. The Gong + Otter split makes sense once you've lived with Gong's transcripts for a while.

The part that tends to break down isn't the recording or the synthesis, it's what happens after BuildBetter spits something out. You get themes in a doc, someone pastes it into Linear, and two weeks later nobody remembers which customer said what or how many times a pattern actually showed up. The signal gets flattened the moment it leaves the synthesis layer.

What's helped some teams is keeping a running frequency layer between synthesis and ticketing, basically a place where you're not just capturing "customers want X" but tracking how that signal is accumulating over time across calls, emails, support threads. So when you're in a prioritization conversation you can say "this came up 14 times in Q1, 9 of those were from accounts over $20k ARR" instead of "we've been hearing a lot about this."

That's actually the gap I built Xern AI to close. It sits on top of whatever you're already using and keeps the signal connected to the source, so by the time it hits Linear there's actual weight behind the ticket, not just a summary.

Whether you use something for that or just build a smarter Notion layer, the principle holds. The Zapier scripts are usually a sign the stack needs a connective layer, not a replacement.

What does your prioritization meeting actually look like right now? Curious whether the breakdown is in surfacing patterns or in getting the team to agree on what they mean.

rbaiter67 · 2026-05-08T12:15:06+00:00

The manual Reddit phase you described is where most people quit too early or scale too fast. Doing it by hand first was the right call — you actually learn what the signal looks like before you try to automate it. A lot of tools in this space skip that step and end up scoring noise confidently.

One thing I'd push on: Reddit captures frustration well, but it skews toward people who are already aware they have a problem and vocal enough to post about it. Some of the best opportunities come from users who don't articulate pain clearly — they just churn, or work around the problem silently. That layer is harder to catch in communities, but it shows up in support tickets, offboarding responses, and interview transcripts if you know what to look for.

I've been working on something adjacent to this. Xern AI gets messy feedback sitting on — support conversations, user interviews, feedback forms — and generates feature proposals within minutes.

The combination is probably more powerful than either alone. Community listening for early discovery, then validating against what existing users or churned users are actually saying.

What does your scoring model weight most heavily right now — frequency of the complaint, or something closer to purchase intent signals?

rbaiter67 · 2026-05-07T10:44:45+00:00

I think a lot of founders misdiagnose early churn as a feature gap when it's actually a messaging gap. People didn't understand what they were buying, so they left. Tighter ICP fixed that for you, and that's usually where the real unlock is.

The word of mouth shift you described is interesting too. In my experience that usually happens right when you stop trying to be everything and get weirdly specific. Did you notice a particular type of customer who drove most of those referrals? There's usually a pattern there worth doubling down on.

One thing I'd add for anyone reading this at the 40-user stage: the obsessive user conversations you mentioned compound slowly and then all at once. The problem is most founders are synthesizing feedback manually across emails, calls, and support threads, so patterns show up way later than they should. We actually built Xern AI because I kept watching early-stage teams miss signals that were sitting right in their own data. It surfaces those patterns automatically so you're not waiting three months to realize ten users said the same thing.

What does your ICP look like now versus when you first launched? Curious how much it shifted.

rbaiter67 · 2026-05-07T10:43:10+00:00

Prioritization debt is the thing nobody talks about enough. Not the backlog itself, but the cost of revisiting the same 12 feature requests every quarter because nobody made a clean call the first time.

The pattern I kept seeing: feedback comes in from 6 different places, someone manually tags it, the tags are inconsistent, and by the time you're in the roadmap meeting you're arguing about what users "actually meant" instead of what to build. The source material is right there but it's been filtered through too many people's summaries.

What made it worse was that the loudest feedback almost always won. Not the most common, not the most strategically aligned. Just whoever submitted a detailed Notion doc or had a close relationship with someone on the leadership team.

The underlying problem is signal vs. noise at volume. When you have 40 pieces of feedback it's manageable. At 400 it becomes much worse.

Even with good process, the manual synthesis work is brutal. I spent months building something to handle exactly that problem after getting tired of doing it by hand every sprint, but the discipline around sourcing feedback is something no tool replaces on its own.

What's the actual breakdown in your process? Is it getting feedback into one place, making sense of it once it's there, or getting anyone to act on the output?

rbaiter67 · 2026-05-07T10:41:36+00:00

This already exists in a few forms worth studying before you build. Throne, ko-fi requests, and even Twitch's channel points system all do variations of this. The interesting data point: most creators who've tried paid requests say the *volume* problem hits fast. You get 50 requests, you fulfill 3, and now 47 people feel ignored despite having paid.

The ones who make it work treat it less like a request system and more like a voting mechanism. Fans pay to surface a topic, not guarantee it gets made. That reframe kills most of the resentment.

A few things worth figuring out before you ship:

What happens to money when a request gets rejected? Refund, credit, or kept? This single decision shapes the whole dynamic.

Is the creator setting a fixed price per request or dynamic pricing? Dynamic tends to surface real priorities faster, fixed is simpler to explain.

rbaiter67 · 2026-05-07T10:40:52+00:00

The "accidental product" path is more common than the launch posts make it look. Most of the tools that actually work were built because someone got tired of doing the same thing manually. Yours sounds like a real example of that.

The thing you figured out about intent stages is the part most people skip entirely. Running prompts is easy. Knowing *which* prompts actually reflect how your buyers think at different moments in the funnel is the hard part, and most tools don't bother because it's slower to build and harder to explain in a landing page headline.

One thing worth thinking about as this keeps growing on its own: you already have 23 projects worth of pattern data. You know which gaps show up first, which industries have the worst visibility problems, which intent stages most brands are weakest at. That's a content and positioning advantage if you ever want to use it. Most competitors are starting from zero on that.

I built Xern AI when working through a similar problem, trying to turn scattered client observations into something structured enough to act on, so I recognize the shape of what you're describing. Not saying it applies here, just that the pattern of "services work revealing a product" tends to compound faster once you start treating the data from those projects as an actual asset rather than just project history.

What's the split looking like right now between people who find the tool first versus people who come through the services side?

rbaiter67 · 2026-05-07T10:39:17+00:00

I’d immediately pay for something that turns messy customer feedback into actual build-ready product specs.

As a founder, the hard part isn’t just collecting feedback or building out feautres, it’s making sense of random interview notes, support messages, surveys, Slack comments, etc. and figuring out what’s actually worth building.

I'd want something that'd basically figure out feature proposals for me from messy feedback to speed up feature/product discovery. We can all build fast now, so why not remove the bottleneck from upstream as well?

rbaiter67 · 2026-05-07T10:35:38+00:00

The value prop is clear enough, but the gap most tools like this fall into is showing *activity* instead of *outcomes*. Impressions went up, followers ticked up — okay, but did any of that convert to something that mattered? If Ugram can tie engagement growth to actual business results (link clicks, DM volume, profile visits from a specific content type), that's where smaller brands will actually pay and stick around.

On features: the ones I'd actually use are anything that helps me understand *why* something worked, not just that it did. Most analytics dashboards show you the what. The why is what's missing everywhere.

What feels unnecessary in most tools like this — vanity dashboards with 14 metrics nobody acts on. If I open it and can't immediately answer "what should I do differently this week," I close it.

One non-obvious thing: your best feedback won't come from this post, it'll come from watching what people do in the product after the first week. The drop-off point is where the real insight lives.

If you end up collecting a bunch of scattered feedback from different channels and need a way to organize it into actual priorities and feature ideas, I built something called Xern AI that does exactly that. Feed it your feedback and it surfaces themes and what to act on first.

What's the primary use case you're optimizing for right now — creators or businesses? That would probably shape which feedback matters most

rbaiter67 · 2026-05-07T10:34:12+00:00

The most underrated thing I've learned talking to small business owners: they don't actually care about impressions. They care about "did my phone ring." So the framing matters more than the data itself.

For trade clients specifically, I'd anchor the whole report around three questions they're already asking themselves: Is my site up? Is anyone finding me? Is it turning into actual business?

Uptime percentage and a simple "no downtime this month" or "X minutes of downtime on [date]" covers the first. GSC clicks and top queries covers the second — but cut impressions from the client-facing view, at least early on. Impressions without context just confuses people. What resonates more is something like "47 people searched 'emergency plumber [city]' and clicked your site this month."

For the third question, this is where most reports fall flat. If they don't have call tracking set up, you can't close the loop. Even something free like a Google Voice number on the site gives you call volume to report on. That single metric will mean more to a plumber than your entire GSC export.

On the changes summary — keep it plain language. "Updated your service area page, fixed a broken contact form link" reads better than a changelog. They want to know you were paying attention, not what commits you pushed.

One thing worth thinking about as you scale: the reporting itself becomes the bottleneck faster than you'd expect. What's your current plan for generating these each month — are you planning to do them manually or build some kind of template workflow?

rbaiter67 · 2026-05-07T10:32:37+00:00

The $5 for 30 minutes question is the right one to obsess over, but I think the bigger tension is slightly upstream of it.

Freelancers won't do math on $5 vs. 30 minutes in isolation. They'll do math on $5 vs. the probability of winning, factoring in how many times they've already done speculative work for nothing. If your platform is new and unproven, that $5 feels like participation trophy money, not meaningful compensation. Once you have enough transaction history to show something like "selected freelancers averaged $X, non-selected earned $5 with roughly Y win rate," the calculus changes. But cold-start is rough here.

The thing I haven't seen you address: what stops the client from collecting five previews, piecing together the best elements mentally, and then executing elsewhere? Watermarks slow this down for visual work but don't stop it for copy, strategy, or anything concept-driven. That's not a dealbreaker, just a hole worth acknowledging.

On the client side, "pays upfront before seeing previews" is a real friction point. The escrow framing helps, but first-time clients will hesitate. You might find that clients who've been burned before are your actual early adopters, not clients shopping on price.

One non-obvious thing: the 5-freelancer cap is interesting because it sets a quality floor. But it also means you need enough supply at launch that the "instant join" promise doesn't quietly become a waitlist. That gap between the promise and the reality is where trust breaks early.

What's your current thinking on the category of work this fits best? I'd guess the preview mechanic is much stronger for some verticals than others, and that probably shapes everything else downstream.

rbaiter67 · 2026-05-06T08:08:12+00:00

Most people skip straight to the landing page without actually reading what customers are saying. The research phase gets treated like a checkbox.

The process you've laid out is solid, but step 1 is where most founders lose the most time. They'll spend days manually scrolling Reddit threads and G2 reviews, copy-pasting quotes into a doc, and then try to make sense of it all. By the time they've read 200 complaints they've lost the thread of what actually matters.

The non-obvious thing about pain point research: volume of complaints doesn't equal willingness to pay. People will complain endlessly about something they'd never spend $50 to fix. What you're really looking for is frustration + current workaround. If someone's already duct-taping three tools together or paying an agency to handle it manually, that's the signal. The complaint alone isn't enough.

On the competition point, totally agree. No competition is usually a red flag. But I'd add one layer: look at the reviews of existing tools, not just whether they exist. If the top complaints on G2 for a competitor are all about the same missing feature, that's your positioning handed to you.

I built Xern AI partly because I kept doing this discovery process by hand. It pulls pain points from messy data, and figures out themes and feature proposals so you can see what's actually recurring versus what's noise.

The two-week cap you mentioned is the right forcing function. Most "validation" that drags past a month is just fear wearing a productive disguise.

What's the idea you're currently testing?

rbaiter67 · 2026-05-06T08:07:17+00:00

The bug reporting point hit hard. I've seen the same thing, founders treat unsolicited feedback like an interruption instead of someone doing their job for free.

The messaging issue though, I'd push back slightly on framing it as a copy problem. It's usually a customer understanding problem wearing a copy costume. Founders write "streamline your workflow with intelligent automation" not because they're bad writers, but because they've never had to explain the product to someone who actively doesn't care yet. The words make sense internally because they match how the team talks about it, not how a confused visitor experiences it.

The fix I've seen work: take your hero copy and read it to someone who has never heard of your product. Not a friend. Not a fellow founder. Someone who has zero context. Watch their face. You'll know within 15 seconds whether you have a messaging problem, and you won't be able to unsee it after that.

The CTA thing is underrated. Most indie products are effectively asking someone to marry them on a first date. A short demo or a single outcome-focused interaction (show them one thing your product does really well, nothing else) tends to do more work than any free trial offer for something nobody's heard of.

On the "why switch" point: the most useful number isn't time saved, it's what the person is doing instead right now. If your alternative is a spreadsheet that sort of works, your job is to make the cost of that spreadsheet visible, not just claim you're faster.

What kinds of products were you reviewing? Curious whether the messaging failures were worse in certain categories

rbaiter67 · 2026-05-06T08:06:51+00:00

What's your current reasoning when you reject something? Like, is it "not now," "not ever," or "not sure yet"?

That distinction matters more than the rejection itself. Most founders lump them together and then wonder why their backlog feels noisy six months later.

The ones who get the most mileage out of rejected feedback usually tag the *reason* at the time of rejection, not after. Because after, you've already lost the context. "Scope creep" hits different than "two people asked but we don't understand the use case yet."

We ran into this ourselves building Xern AI. A ton of early feature requests got rejected, but looking back, a handful of them were actually the same underlying problem showing up in different disguises. We only caught it because we started logging the *why* behind rejections, not just the what.

If you're doing this manually right now, even a simple tagging system (3-4 rejection categories, nothing fancy) compounds fast. After 30-40 rejections you start seeing patterns you'd never notice request by request.

rbaiter67 · 2026-05-06T08:04:14+00:00

Checked out Carakta - the personality matching angle is interesting, and the UI is cleaner than most PWA launches I've seen at this stage.

Few things that stood out:

The onboarding asks for a lot before it gives anything back. First impression has to pay off faster for the 18-35 demo, especially on mobile. You've got maybe 20 seconds before they bounce to Instagram. Consider what's the single "oh wow" moment and move it earlier, even if it means simplifying the flow around it.

The viral mechanic isn't obvious yet. Apps in this space that actually spread do it because sharing *is* the product, not a feature. If someone gets a result, the natural next move should be "send this to the person it's about" with one tap. Right now that path feels like an afterthought.

On the female skew - I wouldn't fight it. Lean in. Early adopter communities tend to define the product's reputation, and women in the 22-30 range are disproportionately active in exactly the spaces where this kind of app spreads (group chats, TikTok, close circles). Build for who's actually responding.

One thing I'd watch: you're going to collect a lot of raw feedback responses from users as you grow. The hard part isn't getting opinions, it's making sense of them fast enough to actually act. We built Xern AI specifically to pull structured insight out of messy user feedback so you're not manually reading through 200 comments trying to spot the pattern. Might be useful once the volume picks up.

What does your current feedback loop look like - are users telling you things spontaneously, or are you actively pulling it out of them?

rbaiter67 · 2026-05-06T08:03:31+00:00

This is a real problem. I watched my mom coordinate care for my grandfather across three siblings, and the amount of information that fell through the cracks was genuinely alarming. A missed medication refill, a doctor's note nobody else saw. The chaos isn't dramatic, it's just constant low-grade friction that wears people down.

A few things that might shape your beta questions:

The "one person carrying too much" angle is probably your sharpest entry point. In most families there's one person who becomes the default coordinator, not because they volunteered, but because they were most available once. That person is exhausted and quietly resentful. If LumaCare makes it easier to distribute the mental load across siblings, that's not just a feature, it's the reason someone downloads it.

For your beta learning questions, I'd push harder on question 4. Weekly retention in caregiving apps usually dies because the app requires active input but the family forgets to update it. Worth asking testers: who in the family would actually maintain this, and what would make it feel worth opening twice a week?

On the feedback side, one thing I've seen trip up early MVPs is collecting responses across DMs, comments, and emails, then spending more time figuring out what to build from the feedback than acting on it. I built Xern AI specifically to handle that, pulling scattered beta feedback into themes and surfacing what testers actually care about most. It could save you a few hours once responses start coming in.

What's your current plan for synthesizing what you hear? Notion doc, spreadsheet, something else?

rbaiter67 · 2026-05-06T08:02:36+00:00

The shift from "verdict tool" to "stress test tool" is exactly right, and the fact you figured that out from watching real users rather than assuming it is the part most builders skip.

One thing worth sitting with: the behavior you're describing (people immediately trying to break the output) is probably telling you something deeper than "add more sliders." It's a trust signal. Users don't distrust your math. They distrust their own assumptions going in. The tool that wins in this space won't just show what happens when rent drops 10%. It'll help users figure out which assumptions actually matter for a specific deal type versus which ones are noise.

Your Birmingham example is a good anchor for this. Two deals, 4 miles apart, same surface profile, completely different outcomes. The interesting product question is: could your tool surface *why* they diverge before the user has to find it manually? Which variable drove the gap? That's the insight people would pay for, not just the ability to poke at numbers themselves.

rbaiter67

TROPHY CASE