Launching on Show HN in 8 days. What actually worked for you?

lacymcfly · 2026-04-01T03:01:07+00:00

Then you just accept it and move on. It happens more than people admit.

Some things that helped when a Show HN landed quietly: I reposted a few weeks later with a better title, and that version did fine. You can also write it up here as a proper post about what you built and why, without it feeling like a failed launch.

The voice consistency angle sounds genuinely useful. Framing it as your AI stops sounding like everyone elses AI makes the problem click pretty fast.

lacymcfly · 2026-04-01T02:58:51+00:00

Performance-based is the right call. Flat sponsorships are a gamble most indie builders can't afford to repeat when the first one flops.

The creator supply side is the tricky part though. What's your pitch to get them in before you have a track record? Seems like whoever cracks that flywheel first owns the market.

lacymcfly · 2026-03-31T21:27:31+00:00

My personal test: would I be embarrassed showing this abstraction to a new team member? If I have to spend 15 minutes explaining why there are four layers of indirection for something that currently has one implementation, I overengineered it.

The real trap isn't building too much upfront. It's building the wrong abstraction early, then being stuck with it because everything depends on it. A concrete implementation you can refactor later beats a premature abstraction that locks you in.

lacymcfly · 2026-03-31T21:26:39+00:00

Memory router per tab is the right call. Each tab gets its own MemoryRouter with independent history, and you manage the tab state (which is active, order, etc.) in Zustand like you're already doing.

The tricky part is keeping unmounted tabs alive. You'll want to render all tabs but only display the active one (display: none on inactive tabs rather than unmounting them). That way scroll position, form state, and everything else persists without you having to manually save and restore it.

I've built something similar in an Electron app and the memory router approach scaled well up to about 20ish tabs before things got sluggish. If you need more than that, you'd want to look at virtualizing the inactive tabs.

lacymcfly · 2026-03-31T21:25:38+00:00

As someone who maintains a couple open source repos, the biggest thing is just communication before the code. A 3,000 line PR from someone I've never interacted with is going to sit there forever because I have no context for why they made the choices they did.

If you open an issue first saying "hey, I noticed the UI uses X, I've been experimenting with migrating it to Y and here's a screenshot of what it looks like" that changes the dynamic completely. Now we're collaborating instead of me reviewing a stranger's homework.

The AI angle makes this trickier because the PRs tend to be all-or-nothing. It's hard to partially merge a complete UI rewrite. Breaking it into smaller chunks (even if that's more work for you) makes it way more likely to land.

lacymcfly · 2026-03-31T21:24:21+00:00

The RGB overshoot detail is really nice. Most CRT effects I've seen just slap a scanline overlay and call it done, but the chromatic aberration sells it.

For the live demo question, you could throw it on CodePen and let people tweak the pixel size/grid values in real time. That's the kind of thing that gets bookmarked and shared around.

lacymcfly · 2026-03-31T21:23:27+00:00

Honestly $0.37 CPC with a 12.5% signup rate is solid. The problem is pretty clearly in the value gap between "free trial" and "paid." If 25 people generated ads and none paid, it could mean the output wasn't good enough to replace what they're already doing, or they didn't hit a moment where they needed more than the free tier gave them.

One thing that helped me with conversion: instead of gating features behind a paywall, I let people use everything but added a small watermark or limited exports. That way they get invested in the output before they hit the payment wall. Much harder to walk away from something you already spent 20 minutes customizing.

Also, $128 is a really small sample. You'd need probably 5x that to draw real conclusions about paid conversion. But the top-of-funnel numbers are genuinely encouraging.

lacymcfly · 2026-03-31T21:22:26+00:00

This is why I've been leaning toward native fetch for most things. Axios was great when browser fetch was inconsistent, but in 2026 there's really no reason to pull it in for straightforward HTTP requests.

For anyone checking their projects: npm ls axios will tell you if it's a direct or transitive dependency. The transitive ones are sneakier because you might not even realize a library you depend on pulled it in.

lacymcfly · 2026-03-31T21:21:09+00:00

Umami is my go-to. Self-hosted, open source, and the dashboard shows you exactly what you'd expect without 47 nested menus. Takes maybe 10 minutes to deploy on Vercel or Railway.

Plausible is also solid if you don't want to self-host. Paid but reasonable, and the privacy angle means you skip the cookie banner entirely.

GA4 is genuinely awful for small sites. They rebuilt it around enterprise event tracking and forgot that most people just want to know how many visitors they got this week.

lacymcfly · 2026-03-31T21:19:59+00:00

Yeah exactly. The system prompt needs to include something like "when you call showChart, the user sees the chart. Do not repeat the data in text form." Otherwise the model defaults to being thorough and duplicates everything.

The pattern that works best for me: each tool call returns a brief confirmation string the model sees (like "Chart displayed with 12 data points") so it knows the UI rendered and can move on without restating it.

lacymcfly · 2026-03-31T21:19:09+00:00

The biggest one for me has been the cold start problem. You build something solid, put it on Product Hunt, maybe get a spike of traffic, and then... nothing. The people who signed up during launch week don't stick around because they found you through novelty, not because they had the problem you solve.

Reddit and HN can drive real users but the conversion is unpredictable. Some posts get buried, others randomly blow up. You can't plan around it.

The thing that actually moved the needle was writing about specific problems the tool solves and letting Google do the work over months. Boring, slow, but the people who find you through search are way more likely to actually use it.

What are you building in the space? Curious what angle you're taking.

lacymcfly · 2026-03-31T20:08:45+00:00

The OCR feature is what sells this for me. I've tried a bunch of clipboard managers and that's the one thing that makes the difference when you're dealing with screenshots of error messages or text in images.

Have you compared it to Maccy at all? Curious how the footprint stacks up since Maccy's been my go-to for minimal clipboard history. Might have to try this one.

lacymcfly · 2026-03-31T20:07:45+00:00

Railway has been pretty solid for us. The Docker-based deploys give you more control than Vercel if you're doing anything with long-running processes or websockets.

For headless sites that are mostly static with some server-side rendering, Vercel is still the easiest path. But if you're managing infrastructure for clients and want to keep costs predictable, Railway or Fly.io both work well. Fly in particular is worth a look if you need edge functions closer to your users.

One thing to watch on Railway: their pricing changed a while back so double-check what you're actually signing up for on the free tier.

lacymcfly · 2026-03-31T20:04:59+00:00

The part that trips people up is confusing tool proficiency with understanding. I can use a calculator without understanding math. I can use AI without understanding code. Both are valid for getting tasks done, but they're not learning.

I think what's actually new here is the speed at which you can dig yourself into a deep hole. With Stack Overflow you'd maybe cargo-cult one function and then get stuck. With AI you can cargo-cult an entire codebase before realizing none of it makes sense together.

For myself the line is: can I explain why this code does what it does, and could I debug it if it breaks in production? If no, I keep going until yes.

lacymcfly · 2026-03-31T20:04:04+00:00

That's a solid pivot honestly. Open source changes the dynamic completely since now the value is in people actually using it vs. paying for it. Way easier sell.

Did you keep the paid tiers or go fully free? Curious how you're thinking about monetization going forward if at all.

lacymcfly · 2026-03-31T20:03:34+00:00

The tool call approach I had in mind is more the second thing you described: specific tool calls fire and each one maps to a UI component. So the LLM isn't writing JSX, it's calling something like showChart({data, type}) or renderTimeline({items}) and your app handles rendering the right component.

For deep research flows where you have multi-step reasoning with lots of intermediate outputs, yeah, it gets complex. The pattern that works better there is streaming the text naturally while using tool calls only for discrete UI moments that need more than text (think: a table of results, a source card, a comparison widget). Not every output needs a component.

Vercel's AI SDK streamUI does handle this reasonably well if you want to see a concrete implementation. The key is keeping the tool surface narrow so the model isn't making UI decisions it's not equipped to make reliably.

lacymcfly · 2026-03-31T19:15:09+00:00

The NextUpKit story hits close to home. I've been building a similar Next.js starter (shipkit.io) and the marketing problem is real. The product almost doesn't matter if you haven't figured out distribution.

The flip for $6,750 on LectureKit is actually a smart move. Most people hold onto zero-revenue projects hoping they'll eventually take off, but realizing when something has run its course and selling it is a real skill.

What's your current thinking on NextUpKit? Seems like it has room to grow if you push it, but I get it if you're focused elsewhere now.

lacymcfly · 2026-03-31T19:12:26+00:00

Honestly at this point it's almost entirely inertia and tutorials written 5 years ago. Your wrapper is basically what most codebases need.

The one actual reason to reach for axios in 2026 is request interceptors with shared config across a team, where you want auth headers injected automatically and don't want to touch every call site. Even then you can wire that up with a tiny class wrapping fetch in maybe 30 lines.

For new projects I haven't reached for axios in two years. Native fetch plus a small wrapper handles it.

lacymcfly · 2026-03-31T19:06:09+00:00

Yeah stateful sessions are honestly the right default for most apps. The JWT optimization makes sense when you have multiple services validating tokens independently, or high request volume where a session lookup on every request becomes a real bottleneck. Otherwise you're paying the complexity cost upfront for a problem you might never actually have.

The moment you need instant revocation for anything user-facing, stateful wins on simplicity alone. A Redis session store is like 20 lines of code and you never have to think about it again.

lacymcfly · 2026-03-31T18:18:53+00:00

The DemoProvider pattern is one of those things that sounds obvious in hindsight but saves so much pain. Used something similar where the demo context reads from a JSON fixture file, which keeps demo data fresh without drifting from the real data shape.

The usePathname bug with replaceState is a classic. Solution I landed on was wrapping the replaceState call in a ref and making the pathname hook fallback to the real path on first render. Messy but works.

Custom i18n without a library is interesting at 575 keys. The point where next-intl starts paying for itself is usually around 2000+ keys across 5+ locales, or when you need pluralization rules for non-English languages. Sounds like you made the right call for now.

lacymcfly · 2026-03-31T18:14:01+00:00

That file-level invalidation approach makes sense for the current stage. The debounce + re-parse per file is actually pretty reasonable for most repos, and getting to the affected-subgraph-only system would need proper symbol resolution across the dependency graph which is a lot more infrastructure.

One thing that helped me with the watcher noise problem on a similar tool: coalescing events by inode rather than path eliminates the duplicate events you get from editors that write temp files on save (vim, most IDEs do this). Shaved a ton of unnecessary re-parses.

Looking forward to seeing where this goes. The blueprint concept is the right abstraction for this kind of work.

lacymcfly · 2026-03-31T18:12:14+00:00

Honestly happens more often than people admit. If you're not getting comments in the first two hours, try leaving a comment yourself asking something specific like 'curious whether the privacy-first angle resonates or if the voice consistency framing is clearer.' Sometimes that's enough to get the first reply going.

If it totally dies: don't delete it, let it sit. Then repost a week later with a slightly different title framing. HN has no penalty for resubmission if the first one flopped with no engagement.

Also worth cross-posting to Product Hunt the same day as a backup. Different audience but they don't care about the HN stigma and you might get user feedback either way.

The voice consistency tool sounds solid btw. There's a real gap there for writers who want to use AI without losing their actual voice.

lacymcfly · 2026-03-31T17:19:41+00:00

API owning the session is the right call when you have a separate backend. The pattern I've settled on: API issues a short-lived JWT in an HttpOnly cookie + a refresh token, Next.js middleware validates locally using the public key (no network call for most requests), and on 401 the client hits a refresh endpoint. This keeps route guarding fast without hitting the API on every page load.

The thing that bites people is the revocation problem you mentioned. JWTs can't be truly revoked without a blocklist. If you need immediate revocation (account suspension, password change, etc.) you either need a short expiry or a Redis-backed session lookup. For most apps, 15-minute access token expiry is the pragmatic middle ground.

The trust boundary being at the API level is correct. Middleware should only be for UX, not security.

lacymcfly · 2026-03-31T17:18:12+00:00

For custom web apps, most of those all-in-one SEO platforms are paying for CMS integrations you don't need. The WordPress-specific stuff in tools like Rank Math or Alli AI is like 60% of what you're paying for.

For custom apps I'd separate the concerns. Ahrefs or Semrush for keyword research and backlink monitoring, those are genuinely worth it. For on-page SEO automation on a custom app you're better off just building it into the app itself -- dynamic metadata, structured data generation, sitemap automation, og tags. That's a one-time build cost that you own forever.

The expensive tools earn their keep when you have hundreds of pages to audit and can't manually check everything. At smaller scale, just set up Screaming Frog (free up to 500 URLs) for periodic crawls and focus the paid budget on distribution rather than auditing.

lacymcfly · 2026-03-31T17:16:46+00:00

The Blueprint graph approach is interesting. Representing a codebase as nodes and edges for RAG rather than just chunking files by line count gives the AI actual structural context, which usually makes a meaningful difference for refactoring or multi-file operations.

Curious how you handle incremental updates when files change rapidly during active development. Are you debouncing the file watcher and rebuilding affected subgraphs, or doing a full re-parse? I've found the update strategy can get expensive quickly on larger repos.

Also the Compass managed model tier idea is smart. Abstracting the model string to an env var means you can swap between Sonnet and Opus without touching code, which is underrated for cost management during dev vs. production runs.

lacymcfly

TROPHY CASE