u/Khavel_dev

10K installs with zero ad spend is a signal worth paying attention to. The $250 is almost irrelevant at this stage. What matters is whether people keep using it or uninstall after a week.

If retention is decent, the monetization problem is solvable. If it's not, no pricing model fixes that.

tbh the waitlist number doesn't matter until you know what happens when you ask for money. I sat on a similar situation for months and the longer I waited the scarier it got. Just pick your 50 most engaged signups and email them a founding member deal, something like a locked-in rate forever. You'll know within a week if this is real.

The worst outcome isn't that nobody pays. The worst outcome is spending another 6 months building for a list that was never going to convert.

First impression was skepticism but the bookshelf rendering is actually smooth. The hover-to-slide-out feels more polished than I expected from a weekend project.

What's the stack under the hood, Three.js? And how did you pull the real dimensions for 618 books? I'd expect Kindle to make that painful to get at.

Distribution for client mods is brutal because the platform itself works against you. Not just obscurity, actual distrust.

What I'd try: find the Discord servers where the modding community already hangs out and become a regular there before linking anything. And short demo videos showing it working in a real multilingual conversation. People need to see it working before they'll install something that touches their client.

The product itself makes sense though. I'm in a few multilingual servers and the copy-paste-translate loop gets old fast.

The attack surface you're covering is real and it's growing fast. I use Claude Code every day and most people just click through the .claude/settings.json permissions without reading them. MCP servers that spawn shell processes are the worst because the config looks harmless until you realize it grants arbitrary code execution.

On the money question, imo the GitHub Action is where you should focus. Individual devs won't pay for a scanner, but a team lead who needs to vet MCP configs before they land in a shared repo might. The CI gate that blocks the PR fits into an existing decision point. Keep the rules and core scanner open source, charge for the managed layer (hosted dashboard, policy templates across an org).

I've been building MCP servers for a while and health data is interesting but tricky. The big question is what you're pulling from. If it's Apple Health or Google Fit, the export formats are a pain to parse and timestamps are inconsistent across devices.

One thing I'd think about early: keep the tool responses small. Claude and ChatGPT both have context limits and if your MCP dumps a full year of heart rate data into the conversation it eats the whole window. Paginate aggressively or pre-aggregate on the server side before returning anything.

The problem is definitely real. We started asking candidates to share their Claude Code session during interviews and it was night and day compared to a plain coding exercise. You see how they prompt, whether they actually read the output or just accept it, how they recover when the agent goes sideways. Way more signal than "did they write a working solution."

The tricky part is going to be convincing companies this isn't "cheating." Most hiring managers are still stuck on the "no AI in interviews" train.

The parallel-machine trick is solid. I've done something similar when database provisioning hangs during deploys. Fire a second attempt after a short timeout, take whichever comes up first, kill the other. Works great as long as cleanup is reliable.

Starting the server before lint is the right call for live preview. In CI I still gate on lint, but making a user stare at a blank screen because of a config issue is just wasted goodwill.

That bit about the paid review lands hard. One stranger who actually used the thing found more actionable stuff than you'd get from a dozen "looks cool" replies. I've started asking early testers to screen-record their first 5 minutes instead of asking what they think. People tell you it's fine, but the recording shows them clicking the wrong button three times.

C# has gotten stupid fast for this kind of work. Span<T>, stackalloc, and System.Runtime.Intrinsics let you get within spitting distance of C without dropping to unsafe.

What people still miss is how much TieredPGO changed things in .NET 8+. Hot methods get recompiled with profile data at runtime. I've seen inner loops get 2x faster just from upgrading the runtime, zero code changes.

The real cost of C here isn't speed, it's development time. Writing correct SIMD in C with manual memory management takes way longer than hardware intrinsics in C# and the gap keeps closing every release.

Yeah the trust issue is real. I use Claude Code daily on a multi-service .NET codebase and the pattern that helped me the most was stopping trying to hand it a whole feature at once. Small, scoped prompts with the relevant files already open. If it starts going off the rails you catch it in 30 seconds instead of after it's rewritten half your project.

The other thing nobody tells you is that reviewing agent output is MORE tiring than writing it yourself sometimes. You're doing constant context-switching between "what did I ask for" and "what did it actually do". Takes a few weeks before you build the muscle for it.

fwiw the stress does go down once you stop expecting it to be autopilot and start treating it like a fast junior who needs clear instructions.

The BYO-key approach is underrated for side projects. You skip the billing headache entirely and users who already have an API key get going in seconds. How are you handling the API calls, client-side directly or through some proxy? I've seen some devs get burned when browser CORS blocks the provider's endpoint.

Hacker News Show HN is the single best shot if you don't have an audience. One good post there can drive thousands of visits in a day. The catch is you basically get one attempt, so make the landing page clear before you submit.

Beyond that, honestly being active in subreddits where your target users already hang out is more effective than any listing site. Not posting your link, but answering questions and being useful. When you naturally mention what you built and it's relevant, people actually click.

Product Hunt still exists but it's turned into a popularity contest. Indie Hackers is decent for feedback. But the brutal truth is marketing without social media is playing on hard mode. The projects that get traction without it are almost always solving a problem the builder found by being deep in a community first.

Polars was a good call for this. We had a similar batch classification pipeline (different domain) and switching from pandas cut our processing time by about 5x on the same hardware. The columnar approach just handles millions of rows better.

How are you managing the Claude API costs at 2.1M rows? Even with Haiku that adds up fast. We ended up batching aggressively and caching results so we didn't re-classify records we'd already seen.

Yeah this is probably my biggest gripe with the current crop of AI coding tools. They'll generate something that compiles fine but silently breaks an invariant or misses an edge case, then report success.

What helped me was adding a verification step where the agent runs the existing test suite before claiming it's done. Not foolproof but catches the obvious stuff. The harder problem is when it generates code that passes tests but doesn't actually do what you asked because the tests don't cover the new behavior yet.

imo the stack choice is solid, local-first with Docker self-hosting covers the two groups that care most about financial privacy.

The one UX thing that jumped out from the feature list: recurring transaction detection alongside manual budgeting can get confusing if they disagree. Like if someone budgets $50/mo for a subscription but the detection picks up $52.99, does the budget category show over or does the recurring rule override? YNAB handles this by making you reconcile manually which is annoying but at least predictable.

100+ stars in 3 weeks for a budgeting app is a good signal fwiw. The Enable Banking integration for EU banks is the kind of feature that'd make me look at this over Actual Budget.

The "no matching finding = inconclusive" framing is the right call. A rewrite can hide the symptom while making the underlying problem worse, and treating silence as proof of a fix is how false confidence builds up.

The regression detection is probably the highest value behavior there. In practice, security regressions come from refactors weeks later that reopen something nobody remembers, not from someone deliberately reintroducing a vuln. Making that signal impossible to miss matters more than the initial scan imo.

imo the answer depends entirely on whether you've found product-market fit yet. Before PMF, every feature request is a signal but not necessarily a directive. After PMF, requests from paying customers who match your ICP are gold.

The rule I follow: if three separate people ask for the same thing unprompted, build it. If one person asks for something complex, ask them what they're actually trying to accomplish. Half the time the real problem is simpler than the feature they proposed.

You've hit the classic evaluation gap problem. The code works, the tests pass, but you can't tell if the actual output is good because the domain isn't yours.

I had something similar with a data pipeline where the business rules came from a field I didn't fully get. What worked: finding one person who knew the domain and paying them a few hours to validate a test set. Not the whole app, just enough reference examples that I could build automated checks around them.

For fingerings specifically, I'd grab a handful of the trickiest ones and post them on a guitar forum asking if they're playable. Five expert opinions on ten examples will tell you more than a month of guessing.

This would save me a lot of the back and forth where I'm trying to describe a visual bug to Claude Code by typing. Does it work with terminal output too or just rendered UI? Because half my bugs are "this spacing looks wrong in the console output" and describing that in text is painful.

The MCP server mode is the most interesting part imo. Right now when I ask Claude Code why something is slow it just guesses based on what processes are running. Having it query actual memory pressure and disk stats instead of estimating would cut out a lot of wrong turns.

How's the startup time? For something that runs inside an AI assistant's tool loop, anything over ~500ms per call starts to feel sluggish.

When someone opens a GitHub issue that starts with "I tried to use it for X and..." where X is something I never designed for. That means they cared enough to push the thing past what the readme says, which is worth more than a star.

The other one for me is when my CI breaks on a dependency update. Sounds backwards but it means the ecosystem around the project is still moving and my thing is connected to it. A project nobody depends on never breaks.

118 parts is wild. The scrubbing and click-on-a-part workflow reminds me of how I debug UI layouts, except for physical things.

Honest question though: how does the agent handle tolerances? Like if I say "make a bracket that clips onto a 20mm rail," does it make a 20mm slot, or does it know to add clearance? Every 3D print I've done fails because the model is dimensionally perfect and reality isn't.

Been wanting something like this. I run multiple Claude Code sessions across projects and my mental model of how much budget I have left is basically vibes. Having it in the menu bar instead of hunting through the settings page would save me from those "oh wait I'm at 90%" moments.

The double-circle gesture is a clever way to trigger it. Every other magnifier I've tried either steals a keyboard shortcut I already use or parks itself in the system tray where I forget it exists.

Going with raw Win32 calls in Go is bold. How's the input latency? I'd worry about the circle detection being too sensitive or not sensitive enough but from the video it seems to track well.

The seeded randomness from the icon name is a nice trick. Deterministic output means you can SSR these without hydration mismatches, and since the paths are baked at build time there's zero runtime cost. Not easy to pull off with anything that involves visual randomness.

At 16px though, you're fighting anti-aliasing. Any overshoot on a rect corner that's even half a pixel off could look like a rendering bug instead of a pencil effect. Does the wobble cap scale down with the target size or is it a fixed constraint?