标签：#showdev

I built JSON Utility Kit as a small browser-based toolkit for everyday JSON tasks. The CSV to JSON converter recently got an update for nested JSON structures. For example, headers like user.name, user.email, order.id can be converted into nested objects instead of flat keys. What it supports: CSV to JSON conversion Nested object output from dot notation headers Browser-side processing No signup JSON formatting and validation tools nearby Tool: https://jsonutilitykit.com/tools/csv-to-json/ GitHub: https://github.com/kejie1/json_utility_kit

Forty packages, one maintainer, and no ESLint config anywhere in the repo. That is not a boast - it is the direct result of a decision made early: every tool in the toolchain has to earn its place by governing all forty packages from one config file, not forty. The repo is flare-engine , a modular 2D engine for React Native + Web (animation, gamification, interactive UI, with games as showcases - not a game engine, not a Unity or Godot competitor). The stack behind it is Turborepo Bun Biome , and this post is the actual setup: the real turbo.json , the real biome.json , the real CI guardrail, straight from the repo (trimmed only where a config is long, and I say so where I trim), not a starter template's idealized version. Four binaries, four root configs - turbo.json , biome.json , tsconfig.base.json , and the Changesets config - each governing all forty packages at once (Bun's own "config" is just the workspaces array in the root package.json ). Plus a CI step that fails the build the moment a package imports something it shouldn't. That is the whole story, and I want to show you the files, not describe them. Four binaries, not twelve config files The thesis is narrow: a solo maintainer can keep forty packages honest only if there is exactly one config of each kind, and every package extends it rather than declaring its own variant. Twelve packages each with a slightly different ESLint config is not a monorepo, it is twelve monorepos wearing a workspace file as a costume. Here is the root package.json that runs all of it - Bun workspaces (not pnpm; that distinction matters and I will say it again below), the script table every package leans on, and the pinned package manager: // C:\_PROG\flare-engine-workspace\flare-engine\package.json { "name" : "flare-engine" , "version" : "0.0.0" , "private" : true , "workspaces" : [ "packages/*" , "benchmarks" , "apps/*" ], "scripts" : { "build" : "turbo build" , "test" : "turbo test" , "lint" : "turbo lint" , "typecheck" : "t

I came into this as a graphic designer, not a software engineer. I didn't have a computer science background, and a lot of what BrandStack needed — authentication, databases, payments, deployment — was new territory for me when I started. What made it possible wasn't some shortcut. It was breaking the problem down into pieces I could actually learn: how user accounts work, how a database should be structured so one person's data never leaks into another's, how to move from test payments to real ones without breaking checkout for actual customers. I made real mistakes along the way. Early on, every user shared the same underlying brand data because I hadn't scoped the database correctly to each account — a serious bug that I only caught by testing with two separate accounts myself. Finding and fixing that taught me more about proper application architecture than any tutorial could have. I don't think being a designer first is a disadvantage for building product. If anything, it means the interface and the experience get real attention, not just the backend logic. But it does mean being honest about what you don't know yet, and being willing to slow down and actually understand a problem instead of copying a fix you don't understand. BrandStack is still a work in progress. But it's a real, working product — built by someone who had to learn most of this from scratch, in public, one bug at a time.

Hi everyone, I'm Marc, the founder of ClaimMate AI. I've been building an AI software engineering platform that helps developers generate code, explain existing code, debug issues, create tests, review code, and build applications from simple prompts or voice. I'm still in the early stages and would really appreciate honest feedback from other developers. Why I Built It I wanted one workspace where developers could chat with AI, generate code, debug problems, and iterate on ideas without constantly switching between multiple tools. I'd Love Your Feedback If you have a few minutes, I'd appreciate any thoughts on: Is the interface easy to understand? Which feature would you use most? What would stop you from using it regularly? What feature is missing? You can try it here: https://ClaimMateAI.pro I'm not looking for praise—I genuinely want constructive feedback that will help improve the product. Thanks for your time!

A while back I wrote about 64% of our merged PRs being written by AI . A few people (reasonably) asked: "nice story, but can I verify any of that?" So we put it on a public, auto-updating dashboard: 👉 www.codens.ai/stats/en It shows, for our GitHub organization: What % of merged PRs are authored by AI agents (currently 65%) Median time from PR-open to merge (2 minutes) Who merged what — task-execution agents vs maintenance bots vs auto-fix vs humans Weekly AI-merge counts and a per-repository breakdown Every number is tallied straight from the GitHub API by a small collector script, and the page regenerates itself weekly. We can't inflate it — it's measured, and the down weeks show up too (that's kind of the point). Why bother making it public Two reasons. 1. "Trust me bro" doesn't scale. When you claim most of your code is AI-written, the only honest move is to expose the raw counts so anyone can sanity-check them. The dashboard is that receipt. 2. It's a live dogfooding test. The whole thing — the PRD, the implementation, the review, the auto-fix on production errors — runs on Codens , our own AI dev-automation suite. If our own numbers ever tanked, the dashboard would be the first place it'd show. Public accountability is a good forcing function. Funny footnote: the dashboard itself was code-reviewed by our own AI reviewer before it shipped, and it caught two real bugs — an OG-image percentage that had drifted out of sync with the live number, and a broken error-fallback that would have blanked the page on malformed data. The tool built to sell "AI reviews your PRs" reviewed the PR that announces it. We'll take it. If you want to see the same machinery on your repos, there's a 14-day free trial (no card): codens.ai . Japanese version of the dashboard is here .

We are two friends building Pageonaut , a collection of 126 free browser tools (converters, calculators, PDF and image utilities, dev helpers). Early on we committed to one constraint: everything runs client-side . No file uploads, no accounts, no server-side processing. That one decision shaped the whole architecture, and it broke things in ways I did not expect. Here are the lessons, including the one where our server filled up with 419 GB of cache and took the site down twice. Why client-side only Every time I needed a quick converter, the top search results wanted me to upload my file to their server, create an account, or pay to remove a watermark. For work that a browser can trivially do locally. So the rule became: drop a file into one of our converters and it never leaves your device. You can watch the network tab while using it. This is great for privacy and trust, and it has a nice side effect: our server does almost nothing per user, so hosting stays cheap even if a tool gets popular. The cost: some tools are genuinely harder to build. PDF manipulation in the browser (we use client-side libraries instead of a server queue), image processing on the main thread without freezing the UI, and no "just call an API" escape hatch. When a tool truly needs the network (say, fetching a URL you give it), the page says so explicitly. Lesson 1: Unbounded URL params + ISR = a full disk This is the expensive one. We built shareable challenge pages: beat my score, try this color, that kind of thing. The URLs look like /tools/<slug>/challenge/<value> , where <value> is user-generated. With Next.js ISR, every unique URL that renders gets persisted to the filesystem cache. You can see where this is going. The value space is infinite. Bots found the pattern and started enumerating it. .next/server/app grew to 419 GB . The disk filled up, the site went down, and because we did not understand the root cause immediately, it happened a second time a few days later. The fix was tw

I'm launching SmartTaxCalc.in on Product Hunt on Tuesday, 14 July 2026 . It's a 38-tool Blazor WebAssembly tax + finance calculator I've written about here before ( the SEO/schema saga , and dropping mobile LCP from 6-8s to under 2s ). The Product Hunt launch algorithm heavily rewards products that arrive with a real coming-soon follower base — day-of upvotes correlate strongly with pre-launch "Notify me" clicks. My PH page started with 1 follower . I had 9 days to get to 50+. The obvious answer: post on LinkedIn, ask friends, DM your network. All of that has ceilings (you can only ask a favor once). The non-obvious answer that has no ceiling: convert your own organic search traffic into PH followers automatically. This is the ~100 lines of Blazor code that does that, plus the design decisions I made along the way. It's also self-cleaning — after the launch date, the banner disappears with no manual work required. Steal the pattern for your own launch. The problem SmartTaxCalc gets modest but real organic traffic — mostly from Google Search Console impressions on tax-season queries. That traffic is the warmest possible audience for a PH launch (they already found the site, they're in the target demo). But how do you route them to a PH page without: Disrupting the tax content (they came for a tax calculator, not a marketing pitch) Cannibalizing the existing tax-season banner (which drives users to /tax-calendar/ — a real retention lever) Leaving code debt after 14 July (a dead PH banner still on the site in September) Losing the dismiss preference across page navigations (SPA reality — no page refresh) Those constraints ruled out a modal, a full-width interrupt, and a "hardcoded remove after launch" approach. The design Slim horizontal bar at the top of every page. Sits ABOVE the existing tax-season banner. PH-brand orange, different from the tax-season banner's yellow/red so both are visually distinguishable when stacked. Dismissible per-user via localStorage . Auto

I kept hearing about Kalshi. The commercials, the mentions, and then one morning CNN was talking about Kalshi prediction odds like they were a weather report. So I went and looked. And I had no idea what I was seeing. Kalshi is really hard to understand when you're new to it. You get markets, contracts, prices that are also probabilities, volume, movement, and none of it tells you what's actually worth paying attention to. I wanted something that would translate what I was looking at into something I could understand and, ideally, act on. That was the whole original goal: make the firehose legible. Then, of course, I kept adding to it, because once you can read the flow you start wanting an edge in it. Who doesn't. So Trade Hunter grew from a translation layer into a translation layer with detection on top. This is a writeup of what it became, why I made the design choices I made, and the parts I'm still not sure about. I'd rather you poke holes in it now than find the breakpoints the hard way. If you think a decision here is wrong, please let me know. The comments are the point of this post, not an afterthought. Where this came from Basically, I couldn't read Kalshi, and I wanted to. Trade Hunter is the original tool I built to fix that for myself, and it's the one I still run when I want a live view. So this isn't a polished sequel to anything. It's the thing I built because I wanted it to exist, flaws and design bets included, and I'd rather show you those directly. The core idea never changed even as I piled features on: watch live Kalshi WebSocket feeds and surface an unusual move while it's still moving, rather than reading about it after the fact, or on CNN the next morning. What it actually does Trade Hunter subscribes to live Kalshi feeds across every market you track. Multi-contract series like the Fed rate decisions or who will win Top Chef fan out automatically to all open contracts, so you point it at one thing and it watches the whole family. When some

I have a folder on my laptop called side-projects . Most of them are Dockerized. Most of them will never see more than a handful of users. And for years, every one of them hit the same wall: getting the thing onto a cheap VPS without losing a weekend — and copy-pasting my own past mistakes forward every single time. Here's the opinion that eventually turned into a project: the part of a PaaS you touch most often should hold the least power over your server. Think of a deploy tool as two planes. There's a read plane — dashboards, logs, container health, the stuff you stare at — where you spend most of your time and which is your most exposed surface. And there's a write plane — deploy, restart, the actions that actually change the system — which is rare and should be gated. My frustration was that the thing I looked at all day and the thing that could rewrite my box tended to sit on the same pile of privilege. So I built Mooring to keep those two planes apart. It's an early, solo project, and this post is me showing it and asking for eyes on it. The mental model The whole thing, end to end: Install it as an unprivileged systemd service (not root). Connect a git repo. Write one mooring.yaml . Click Deploy. That's the loop. Everything below is what's underneath it. What it is Mooring is a small, security-first, self-hosted control plane for Docker — a tiny PaaS. You point it at a git repo, describe your app once, and it deploys and runs your containers on your own server. Same territory as Coolify, Dokku, CapRover, and Kamal — all genuinely good work. The difference I care about is the posture underneath. It ships as one static, CGO-free Go binary . It runs as an unprivileged systemd service — not root. State lives in SQLite (the pure-Go modernc driver). Every asset is embedded with go:embed , so there's no node_modules , no asset pipeline, nothing to build on the box. To be honest about the neighborhood: setting up a self-hosted PaaS, these tools tend to want broad ac

This is the story of a for-fun project, Luka Fit Index that started with me typing "ai for fun?...

A tour of the stack behind mattstratton.com and speaking.mattstratton.com: a monorepo holding two Astro sites and a dev.to sync tool, twenty years of blog posts, and the pipeline that crossposts posts like this one.

I’m building Euro Toolhub , a German-first index of European software, SaaS, cloud and AI alternatives. The idea is simple: many companies, agencies, developers and privacy-conscious users want alternatives to common tools when they care about things like data residency, open source, self-hosting, European jurisdiction or reducing dependency on non-European providers. But most existing lists stop at listing tools. I want Euro Toolhub to go one step further. Each provider profile can include: country and jurisdiction category alternative-to mappings open source status self-hosting availability EU data residency DPA availability certifications where known target audience strengths and limitations a transparent sovereignty score embeddable badges for providers The project starts in German because the first target market is DACH, but the structure is prepared for more languages later. The long-term vision is to build a practical decision platform for digital sovereignty: not just “which European alternatives exist?”, but “which one fits my actual use case?” Current categories include web analytics, cloud and hosting, newsletter tools, CRM, email, password managers, AI APIs, project management, video conferencing and e-signatures. I’m looking for feedback from developers, SaaS founders, privacy people and self-hosting communities: Which European tools should be added? Which categories matter most? What would make a sovereignty score trustworthy? Should the provider dataset be opened through GitHub for corrections and submissions? Project: https://www.euro-toolhub.eu/de Provider submission: https://www.euro-toolhub.eu/de/anbieter-eintragen ``

There's a pattern playing out across indie hacker forums, engineering blogs, and Discord servers right now: a founder builds a product on GPT-4-class models, ships it, gets traction — and then opens a bill that makes them question the whole business model. LLM costs have a nasty habit of scaling linearly (or worse) with usage, right at the moment a product starts succeeding. In response, a growing body of developer tutorials is focused on one goal: keeping the intelligence, dropping the invoice. Think of it like the early days of cloud hosting. Companies over-provisioned expensive dedicated servers until autoscaling and cheaper commodity infrastructure made "pay for what you use, and use less of the expensive stuff" the default architecture. The LLM ecosystem is going through its own version of that shift right now, and DeepSeek has become the poster child for the "just as capable, dramatically cheaper" alternative to OpenAI's premium models. Migrating With Minimal Friction The first core question developers are wrestling with is deceptively simple: how do you swap out a model provider without rewriting your whole application? The answer that keeps surfacing is API compatibility layers . Many cost-effective providers, including DeepSeek, expose an API that mirrors OpenAI's own request/response format almost exactly. That means in a lot of codebases, migration isn't a rewrite — it's a find-and-replace of a base URL and an API key. # Before: pointed at OpenAI client = OpenAI ( api_key = " sk-openai-... " , ) # After: same SDK, same code, different provider client = OpenAI ( api_key = " sk-deepseek-... " , base_url = " https://api.deepseek.com/v1 " ) That's it, in the simplest case. Because the OpenAI Python SDK just talks HTTP under the hood, any provider that speaks the same "dialect" can slot in without touching your prompt logic, your function-calling schemas, or your downstream parsing code. The real friction shows up in the details: subtle differences in how mode

Sand bottle - WebGPU Remember those bottles filled with colored sand that you can find in many souvenir stores? Liam Egan created a digital version using JavaScript WebGPU API. Click to drop sand, use the arrows to tilt and shake the bottles, and relax while enjoying this sandy demo. Button State Builder Margarita shared this button builder that allows to customize a control with icons, text, color, shape... even all the behavior in the different states of the button. Then you can easily get the HTML, CSS, and JS code to put it on any website. Pretty cool. WebGL Switch Button In this demo, the whole page turns into a giant three-dimensional toggle switch that can be activated clicking anywhere on the viewport. Explore the component: mouse over to make the component tilt or scroll to zoom in and out. A nice job by Toc. Animated radial gradient mask over text This demo is exactly what the title says: a radial gradient applied as a mask to some text. Cassidy aligned it perfectly with the hole in the O from "Hello" that makes this effect chef's kiss . You will need to uncomment the animation property in CSS to see the demo in action. 221. ycw always creates impressive and original content. And this demo delivers. It's not only the effect in itself, but the use of light and shadows, and the perfecto choice of color that adds a timeless atmosphere. Beautiful. vRLbdoSAIsoSQvisac Mustafa Enes created different versions of this idea over the past month, all of them are great, but I picked this one as it is more interactive. Click on the screen to regenerate the pattern and move the mouse around to animate the colors. I don't know why, but there's a feeling of peace and joy while doing it. beach sunset I saw several demos by Vivi Tseng that caught my attention this month. Really enjoyed the general minimalistic style they all had and finally picked this animated one because it feels simple and pure, almost like a drawing a child would do during a vacation. I really enjoyed it

🧠 Building CogneeCode - AI Developer Memory Assistant The Problem Every developer faces the problem of lost context. "Why did I make this decision 3 months ago?" "How did I fix this bug last week?" Current AI tools forget everything between sessions. This is a real problem that wastes hours of developer time. My Solution CogneeCode is an AI developer memory assistant that builds a permanent knowledge graph using Cognee Cloud . It remembers every decision, bug fix, and code context you give it. What It Does ✅ Log architectural decisions with tags and context ✅ Log bug fixes with error messages and solutions ✅ Ask natural language questions about your codebase ✅ Get answers with evidence citations from the knowledge graph ✅ Semantic search across all memories ✅ Visual timeline of all decisions and bug fixes ✅ Analytics dashboard showing memory insights ✅ Knowledge graph visualization Tech Stack Backend: Flask (Python) Memory Layer: Cognee Cloud LLM: Groq Llama 3.3 Frontend: Vanilla HTML + CSS + JS Icons: Tabler Icons Cognee Cloud APIs Used remember() - Save decisions and bug fixes with metadata recall() - Natural language queries with evidence citations search() - Semantic search across memories visualize() - Knowledge graph visualization improve() - Memory graph enrichment forget() - Remove outdated memories Why This Matters When you return to a project after months, all your reasoning and solutions are still there, searchable in natural language. No more "Why did I do this?" or "How did I fix this bug?" Demo Watch the video: https://youtu.be/TNcBIBuPW7c Links 🔗 GitHub: https://github.com/JOSESAMUEL14/cogneecode 🔗 Live Demo: https://josesamuel.pythonanywhere.com AI Assistance Disclosure Built with assistance from Claude and Gemini AI. Built for WeMakeDevs x Cognee Hackathon 2026 Category: Best Use of Cognee Cloud ⭐ Star the repo if you find it useful!

wa.me/username doesn't work yet — I verified it two ways, here's what to use instead If you've tried to build a "share my WhatsApp" link using a @username instead of a phone number, you've probably assumed wa.me/username (or wa.me/u/username ) works the same way wa.me/15551234567 does. It doesn't — at least not yet, as of writing this. I wanted a definitive answer instead of trusting blog posts or AI chatbot answers (more on that below), so I tested it two independent ways. Test 1: server response curl -I https://wa.me/u/some_real_reserved_username Every username path I tried — including a certified-real, currently-reserved username — 302-redirects to: api.whatsapp.com/resolve/?deeplink=...&not_found=1 Compare that to the phone-number path, which redirects to: api.whatsapp.com/send/?phone=...&type=phone_number Different resolver, different outcome. The server-side route for usernames exists, but every lookup currently resolves as "not found" — even for real, live usernames. Test 2: real device Server response alone doesn't rule out Universal Links / App Links intercepting the URL client-side before it ever hits a server — curl can't see that. So I also opened all three link variants ( wa.me/username , wa.me/u/username , and a redirect through my own domain) on a real phone with WhatsApp installed. None of them opened a chat. Why this matters if you're building anything around WhatsApp usernames WhatsApp has rolled out @username handles as a real, user-facing feature — but it hasn't published a public deep-link spec for opening a chat from one, the way it has for phone numbers for years. If you're building a tool, a profile page, a business card generator, anything that assumes wa.me/username "just works," it doesn't, for anyone. One more data point: I asked Meta AI directly about this, with the counter-evidence above in hand. It kept asserting the link already works and didn't engage with the evidence when pushed. That's a useful reminder that chatbot answers about

Table of Contents Setting a New Benchmark for Myself My Most Productive Six Months Yet 2...

My wife tracks her meals, and I watched her type "buckwheat, boiled, 100 g" into a calorie app for the hundredth time. Search, scroll, pick the wrong entry, fix the grams. Every meal, every day. At some point it's easier to teach a vision model to look at the plate. So I built a Telegram bot. You send a photo of your food, it identifies the dishes, estimates portion weights, and replies with a card: calories, protein, fat, carbs. Text and voice work too ("2 eggs and a toast"). The borscht incident The first version was hilariously confident about wrong answers. Borscht — a red beet soup, if you've never met one — came back as "berry compote" (a sweet berry drink). Red liquid in a bowl, what else could it be? Adding more example dishes to the prompt made it worse : the model just got magnetized to whatever was on the list. A cod fillet became "syrniki" (cottage cheese pancakes) because syrniki were mentioned and both are pale and pan-fried. What actually fixed it was making the model read the serving context before naming anything: liquid served in a deep bowl with a spoon and sour cream is soup, not a drink. Flaky texture that separates in layers is fish, not pancakes. Fried items are never served floating in liquid. A short list of physical rules beat a long list of dishes. Portion estimation works the same way — the model reasons from plate size, cutlery, how full the bowl is. My wife has been checking its gram estimates against her kitchen scale for a week and it lands closer than either of us expected. Stack, briefly Python + aiogram, a vision LLM with structured JSON output (with a fallback parser for the days the model decides to wrap JSON in prose), Pillow for rendering the result cards. Photos are analyzed on the fly and never stored. Payments are Telegram Stars, so there's no app store, no signup, no card form — the whole onboarding is "send a photo". Yesterday I also wired up inline mode: type @SnapPlateBot in any chat, describe the food, and it counts rig

A cat astrologer, spec-driven and running on Amazon Bedrock A companion to A Builder in Paris: Do Devs Dream of Électrique Chats? Last month I wrote about the idea. Six rainy days in Paris, a closed laptop, and a hackathon I did not mean to enter, and somewhere between the Musée de l'Orangerie and a lot of walking, an idea arrived. Cats are inscrutable. The people who love them are obsessed with understanding them anyway. Astrology is an old framework for making the unknowable feel readable, and maybe, just maybe, it helps us understand them a little. Her name is Madame Minou , a French cat astrologer who reads your cat's stars from a café terrace. That first article was the idea . This one is the build. Vibe-coded, but on rails Was it vibe-coded? You know it! AI wrote the lines, and I said "no, not like that" more times than I can count. But it was vibe-coding on rails, and the rails were Kiro. Before a single line of app code, I wrote the requirements in EARS notation, a design doc, and a build-ordered task list, all living in .kiro/specs . Decide what "done" means before letting anyone, human or model, start building. The specs are what kept the vibes on track. Then the steering files. .kiro/steering held the enduring rules of the project: product principles, security guardrails, technical direction, and UI law. These were the thing that kept a long, multi-session build from drifting. When a new session opened, the steering files were already the shared context. "The café blue" was one token, not five guesses. Security was not optional. The garbled café sign was a deliberate easter egg, not a bug to fix. From there, the loop: Kiro implemented one approved block at a time, ran each task's PASS/FAIL QA gate on itself before moving to the next, and only stopped for my review on the two things that actually mattered. I directed and approved. Kiro proposed and built. Spec first, block by block, human in the loop. The facts are sacred Here is the part that looks like a

The Problem That Wouldn't Leave Me Alone Pakistan has 220 million people. A functioning legal system. Hundreds of Acts, ordinances, and constitutional provisions that technically protect every citizen. Almost nobody can use them. The median lawyer's consultation fee in Karachi is more than what many families earn in a week. Legal aid is understaffed and geographically concentrated in major cities. And the laws themselves? Written in English — a language most of the population reads functionally at best, and doesn't speak at home at all. So when a landlord illegally locks someone out. When a factory worker gets fired without severance. When a woman wants to know her inheritance rights. When a tenant needs to understand what "Section 16 of the Rent Restriction Ordinance" actually means for their specific situation — they either find a lawyer they can't afford, ask someone who doesn't really know, or quietly give up. This isn't a knowledge problem. It's an access problem. I'm a CS student at Sukkur IBA University in interior Sindh — not Karachi, not Islamabad. The kind of city where you feel the gap between what the law says and what people actually know it says every single day. That gap is where HAQ started. HAQ is an Arabic and Urdu word. It means right — as in, what is rightfully yours. The name felt important. The Core Idea: Ask the Law, Get the Law There's a specific failure mode with AI and legal questions that drove every design decision I made, and it's worth naming clearly. Standard LLMs — any of them — will answer legal questions confidently. They'll cite "Section 144" or "the Transfer of Property Act" with total authority. They are often wrong. Sometimes subtly: the section exists but doesn't say what the model claims. Sometimes obviously: the Act doesn't apply in that province. Always uncitable: the user has no way to verify without finding the source themselves. For an accessibility tool, a confidently wrong answer isn't neutral. It's actively dangerous.