Show HN: I built a 1‑dollar feedback tool as a Sunday side project https://ift.tt/Ojy4N12

Show HN: I built a 1‑dollar feedback tool as a Sunday side project I’ve always found it funny how simple feedback widgets end up as $20–$30/month products. The tech is dead simple, infra is cheap, and most of us here could rebuild one in a weekend. So as a “principle experiment” I built my own today as a side project and priced it at 1 dollar. Just because if something is cheap to run and easy to replicate, it should be priced accordingly, and it’s also fun marketing. 1$ feedback tool. Shipped today, got the first users/moneys today, writing this post today. Side Sunday project, then back to the main product tomorrow. https://ift.tt/paSdOWb December 22, 2025 at 03:22AM

Show HN: Chart Preview – Preview environments for Helm charts on every PR https://ift.tt/C7lp9uo

Show HN: Chart Preview – Preview environments for Helm charts on every PR I’m a software engineer who accidentally became my team’s Kubernetes person — and eventually the bottleneck for every Helm chart PR. I built Chart Preview so reviewers could see Helm chart changes running without waiting on me. A few years ago, my team needed to implement HA for an existing product, which meant deploying on Kubernetes and OpenShift. I spent months learning Kubernetes, Helm, and the surrounding ecosystem. After that, Kubernetes largely became “my thing” on the team. We later published public Helm charts for the product, and customers started submitting PRs. Those PRs would often sit for months — not because the changes were bad, but because testing them meant manually spinning up a Kubernetes cluster, deploying the chart with the proposed changes, running through test scenarios, and coordinating verification with product and QA. Since I was the only one who could reliably set up those environments, everything waited on me. I kept thinking: what if the PR itself showed the changes working? What if reviewers could just click a link and see it deployed? That idea became Chart Preview. Chart Preview deploys your Helm chart to a real Kubernetes cluster when you open a PR, provides a unique preview URL for that PR, and cleans everything up automatically when the PR closes. I started by solving a problem I was personally hitting, rather than surveying the whole market upfront. As I built more of it, I looked at existing preview tools and noticed that while there are solid solutions for previewing container-based applications, Helm-specific workflows introduce different challenges — chart dependencies, layered values files, and opinionated chart structures. That pushed me to focus Chart Preview on being Helm-native first, rather than adapting a container preview workflow to fit Helm. Under the hood, it’s built in Go using the Helm v3 SDK. The architecture is an API server with workers pulling jobs from a PostgreSQL queue — no Kubernetes operator, just services talking directly to the Kubernetes API. Each preview runs in its own namespace with deny-all NetworkPolicies, ResourceQuotas, and LimitRanges. GitHub integration is done via a GitHub App for check runs and webhooks, with GitLab supported via the REST API. There were a few interesting challenges along the way. Injecting preview hostnames into Ingress resources without corrupting manifests took several iterations. Helm uninstall doesn’t always clean everything up, so deleting the entire namespace turned out to be the safest fallback. Handling rapid pushes to the same PR required build numbering so the latest push always wins. And while the Helm SDK is powerful, it’s under-documented — I spent a lot of time reading Helm’s source code. I’ve been building and testing this for a few months using real charts like Grafana, podinfo, and WordPress to validate the workflow. It’s early, but it works, and now I’m trying to understand whether other teams have the same pain point I did. You can try it by installing the GitHub App here: https://ift.tt/4YqCJP5 I’d love feedback on a few things: Does this solve a real problem for your team, or is shared staging “good enough”? What’s missing that would make you actually use it? Are there Helm charts this wouldn’t work for? (Cluster-scoped resources are intentionally blocked.) Happy to answer questions about the implementation. December 20, 2025 at 10:53PM

Show HN: HN Wrapped 2025 - an LLM reviews your year on HN https://ift.tt/mQ9JLWP

Show HN: HN Wrapped 2025 - an LLM reviews your year on HN I was looking for some fun project to play around with the latest Gemini models and ended up building this :) Enter your username and get: - Generated roasts and stats based on your HN activity 2025 - Your personalized HN front page from 2035 (inspired by a recent Show HN [0]) - An xkcd-style comic of your HN persona It uses the latest gemini-3-flash and gemini-3-pro-image (nano banana pro) models, which deliver pretty impressive and funny results. Give it a try and let me know what you think :) [0] https://ift.tt/S1vfE6M https://ift.tt/dkZ0RgC December 20, 2025 at 07:09PM

Show HN: Music player for big local collections with mpd support https://ift.tt/OAmXupe

Show HN: Music player for big local collections with mpd support mpz is a C++/Qt music player focused on UX, with derectory tree and playlists management. Version 2 got experimental https://musicpd.org support. https://ift.tt/nXyU37J December 20, 2025 at 02:25AM

Show HN: MCPShark Viewer (VS Code/Cursor extension)- view MCP traffic in-editor https://ift.tt/Rx2LK7X

Show HN: MCPShark Viewer (VS Code/Cursor extension)- view MCP traffic in-editor A few days ago I posted MCPShark (a traffic inspector for the Model Context Protocol). I just shipped a VS Code / Cursor extension that lets you view MCP traffic directly in the editor, so you’re not jumping between terminals, logs, and "I think this is what got sent". VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=MCPShark... Main repo: https://ift.tt/GRbfe97 Feature requests / issues: https://ift.tt/53vOdM6 Site: https://mcpshark.sh/ If you’re building MCP agents/tools: what would make MCP debugging actually easy—timeline view, session grouping, diffing tool args, exporting traces, something else? I’d be thankful if you could open a feature request here: https://ift.tt/53vOdM6 December 17, 2025 at 11:49PM

Show HN: Stickerbox, a kid-safe, AI-powered voice to sticker printer https://ift.tt/5AOwj8Z

Show HN: Stickerbox, a kid-safe, AI-powered voice to sticker printer Bob and Arun here, creators of Stickerbox. If AI were built for kids, what would it look like? Asking that question led us to creativity, and more specifically, the power of kids’ imaginations. We wanted to let kids combine the power of their ideas with AI tools but we needed to make sure we did it safely and in the right way. Enter Stickerbox, a voice powered sticker printer. By combining AI image generation with thermal sticker printing, we instantly turn kids' wildest ideas into real stickers they can color, stick, and share. What surprised us most is how the “AI” disappears behind the magic of the device. The moment that consistently amazes kids is when the printer finishes and they are holding their own idea as a real sticker. A ghost on a skateboard, a dragon doing its taxes, their dog as a superhero, anything they can dream of, they can hold in their hand. Their reactions are what pushed us to keep building, even though hardware can be really hard. Along the way the scope of the project grew more than we expected: navigating supply chains, sourcing safe BPA/BPS free thermal paper, passing safety testing for a children’s product, and designing an interface simple enough that a five year old can walk up and just talk to it. We also spent a lot of time thinking about kids’ data and privacy so that parents would feel comfortable having this in their home. Stickerbox is our attempt to make modern AI kid-safe, playful, and tangible. We’d love to hear what you think! P.S. If you’re interested in buying one for yourself or as a gift, use code FREE3PACK to get an extra free pack of paper refills. https://stickerbox.com/ December 20, 2025 at 01:14AM

Show HN: Linggen – A local-first memory layer for your AI (Cursor, Zed, Claude) https://ift.tt/uIb37Xq

Show HN: Linggen – A local-first memory layer for your AI (Cursor, Zed, Claude) Hi HN, Working with multiple projects, I got tired of re-explaining our complex multi-node system to LLMs. Documentation helped, but plain text is hard to search without indexing and doesn't work across projects. I built Linggen to solve this. My Workflow: I use the Linggen VS Code extension to "init my day." It calls the Linggen MCP to load memory instantly. Linggen indexes all my docs like it’s remembering them—it is awesome. One click loads the full architectural context, removing the "cold start" problem. The Tech: Local-First: Rust + LanceDB. Code and embeddings stay on your machine. No accounts required. Team Memory: Index knowledge so teammates' LLMs get context automatically. Visual Map: See file dependencies and refactor "blast radius." MCP-Native: Supports Cursor, Zed, and Claude Desktop. Linggen saves me hours. I’d love to hear how you manage complex system context! Repo: https://ift.tt/KOI3Fmp Website: https://linggen.dev https://ift.tt/KOI3Fmp December 19, 2025 at 11:24PM