标签：#showdev

Over the past few years, AI has fundamentally changed how software gets built. Teams can go from an idea to a working application in a fraction of the time it used to take, and founders can create products with resources that would have been unimaginable just a few years ago. That's an incredible shift, and I think it's one of the most exciting changes our industry has seen. What hasn't changed, though, is the question that comes after the application is built: Is it actually ready? Throughout my career, I've been involved in delivering enterprise software across many different industries and organizations. One thing I've learned is that there isn't a single definition of what makes an application "ready." If you ask six different stakeholders whether a system is ready, you'll probably get six different answers—and they're all likely to be valid. That's because each person is looking at the software through the lens of the outcome they're responsible for: A founder may be wondering whether the application can handle the growth they're hoping for over the next year. A CTO is often focused on where the biggest technical risks are and what should be improved first. An engineering leader is thinking about production readiness, security, reliability, and operational support. An agency inheriting a client application wants to understand what they're taking ownership of before making commitments. An acquirer is trying to estimate the cost of technical debt An Investor wants confidence that the technology is creating long-term value rather than future expense. Those perspectives are different because the questions they're trying to answer are different. The challenge is that we often evaluate all software the same way. Traditional assessments tend to focus on the health of the codebase. They look at architecture, security, maintainability, testing, complexity, and technical debt. Those are all important, and they should absolutely be part of any technical review. But they'r

Introducing vernLLM: A Resilience Layer for LLM Applications Building production-ready LLM applications is not just about sending prompts and receiving responses. Real-world AI systems need to handle timeouts, provider failures, rate limits, inconsistent outputs, and reliability issues. That is where vernLLM comes in. vernLLM is a lightweight resilience layer for OpenAI-compatible chat completion APIs , providing a single interface with built-in retries, timeouts, circuit breaking, caching, structured output, and usage tracking. Instead of rebuilding the same reliability features for every LLM project, vernLLM gives you the tools needed to make your AI integrations more robust from the start. Features Automatic retries with backoff Transient failures happen. vernLLM automatically retries recoverable errors while failing fast on validation errors and non-retryable responses. Timeouts & cancellation Prevent hanging requests with configurable timeouts and cancellation support. Circuit breaker protection Automatically stop sending requests to failing providers and recover when the service becomes healthy again. Structured output with type safety Pass a Zod schema and receive validated, typed results back. const result = await llm . call ({ systemPrompt : ' Return JSON: { "skills": string[] } ' , userContent : ' Extract skills from: ... ' , schema : SkillsSchema // zod schema }); Provider-native JSON Schema support Constrain model generation itself instead of only validating responses afterward. Built-in caching support Cache LLM responses using your own cache adapter with cachedCall and cachedLLMCall . One interface across providers Use the same API across multiple providers: OpenAI Groq Mistral DeepSeek Cerebras Together AI Fireworks AI Ollama Anthropic Gemini AWS Bedrock Any HTTP-compatible provider through fromFetch Why vernLLM? Many LLM applications end up creating their own wrappers around provider SDKs to handle: retry logic API failures provider switching respons

Every distributor we spoke to has the same quiet bottleneck, and none of them call it a problem. They call it Tuesday. A request for quote lands in a shared inbox. Sometimes it is a tidy bulleted list. More often it is three lines of text from someone's phone, or a PDF that was scanned at an angle. Someone on the sales desk reads it, works out which catalog part each line actually refers to, checks pricing, and types up a quote. A busy desk does this thirty or forty times a day. It is slow, it is boring, and it is exactly the kind of work where a tired person on a Friday afternoon quotes the wrong bolt and nobody notices until the shipment arrives. We spent three weeks building Distill.ai to do that job. This is what we learned, including the parts that went badly. What we actually built You paste an email or upload a PDF. From there a seven stage pipeline runs: parse -> extract -> classify -> match -> price -> policy -> score Parse cleans the document into text. Extract pulls out the individual line items, quantities, and specs. Classify works out what kind of request this is. Match maps each line to a real catalog SKU. Price applies the pricing rules. Policy runs the business checks. Score attaches a confidence value to every match. The interesting part is not the happy path. It is what happens when the model is unsure. Any line that scores below a 0.70 match threshold does not get quoted. It gets flagged with a reason and routed to a human review queue. A person confirms or corrects it, and the quote goes out clean. That one decision is the difference between a demo and something a sales desk would actually put its name on. An agent that is confidently wrong 5% of the time is worse than useless in procurement, because someone has to check all 100% of the output anyway. An agent that says "I got 47 of these 50 lines, here are the 3 I could not resolve" saves real hours. Why Qwen, and how we wired it up We used two models from Alibaba Cloud Model Studio: Qwen-Plus

I'm excited to share a project I've been building: Letras Personalizadas — a free Unicode text styling tool that helps you create creative copy-and-paste text for social media, gaming, and messaging apps. Here's how it works: • Type your text • Instantly preview dozens of Unicode text styles • Copy your favorite with one click • Use it on Instagram, WhatsApp, TikTok, Discord, Free Fire, and more Although the website is designed primarily for Spanish-speaking users targetting Brazil, it works with any standard Latin text. One thing I've learned while building this project is that these tools are about much more than "fancy fonts." The real challenge is creating a smooth user experience—fast previews, mobile-friendly design, reliable copy buttons, platform compatibility, useful categories, favorites, and making the styled text effortless to use across different apps. I'm continuously improving the interface, expanding the style categories, and refining the mobile experience. If you have a few minutes to try it out, I'd love to hear your feedback and suggestions. Every comment helps make the tool better.

Online file converters are one of those categories where the market leaders have gotten steadily worse. Signup walls, daily conversion caps, "premium" file size limits, upsell banners between you and your download. So when I found digiutil.com, I ran it against the usual suspects for the conversions I actually do. Here's how it stacks up. Where the incumbents lose you If you've used the big converter sites recently, you know the pattern: Account required before you can download your file, or after your first couple of conversions Daily limits on the free tier — often 1–2 files per day File size ceilings low enough that any real video file pushes you to a paid plan Ad-heavy pages where the actual convert button is the fifth-most-prominent thing on screen None of this is about the cost of conversion — it's funnel design. The product is deliberately inconvenient so you'll pay to make it convenient. What digiutil does differently No signup, period. Not "free account required," not "sign up to download." You drag a file in, it auto-detects the format, routes you to the right converter, and you get your file. That alone puts it ahead of most of the category for one-off conversions. No logs, per their policy. Most converter sites are vague about retention. digiutil's stated policy is no logs. Standard caveat still applies — anything you upload to any third-party service is a trust decision — but an explicit no-logs stance is more than most competitors offer. Broad format coverage in one place. Video, audio, images, PDFs, documents, data files, archives, fonts, and subtitles. With most alternatives you end up on a different site for each category (one for HEIC → JPG, another for subtitles, another for fonts), each with its own limits. Here it's one tool: MP4 → MP3, MOV → MP4, HEIC → JPG, DOCX → PDF, and the long tail. Compression too. Video, image, audio, and PDF compression alongside conversion — a task the dedicated compressor sites usually gate hardest behind paid tiers.

Over the weekend, I participated in the OpenAI Build Week Hackathon with a simple goal: Build something I would actually use as a developer. By Friday evening, I had an idea. By Sunday, that idea became an open source project called Arcovia . It wasn't just another AI coding experiment. I wanted to solve a problem I've faced while working on large React applications for years. The Problem We have excellent tools for code quality. ESLint catches code smells. Prettier formats code. SonarQube reports issues. AI reviews code and suggests improvements. But none of them answer questions like: Is my architecture healthy? Which modules are becoming bottlenecks? Where is technical debt accumulating? Which files should I refactor first? Why did my project receive this score? Architecture is often something we discuss during code reviews or realize too late when the codebase becomes difficult to maintain. I wanted a tool that could measure architecture health before it became a problem. Introducing Arcovia Arcovia is an Architecture Intelligence tool for React and Next.js projects. Instead of generating hundreds of isolated warnings, it analyzes the project as a whole and produces an interactive HTML report. It includes: 📊 Architecture Health Score 🕸️ Dependency Graph 🎯 Architecture Hotspots 📈 Explainable Score Breakdown 🛠️ Rule-based Findings 📉 Maintenance Burden ✅ Actionable Recommendations The goal isn't to replace linting. The goal is to help developers understand the bigger picture. How It Works Internally, Arcovia follows a deterministic analysis pipeline. Project │ ▼ Scanner │ ▼ AST Parser │ ▼ Project Model │ ▼ Dependency Graph │ ▼ Rule Engine │ ▼ Score Engine │ ▼ Interactive HTML Report The analyzer currently detects things like: God Modules High Fan-In High Fan-Out Orphan Modules Large Components Deep JSX Nesting Oversized Modules Duplicate Imports Unused Exports Instead of simply reporting findings, Arcovia combines them into an explainable architecture score. Determ

🚀 400 Downloads. $0 Spent. Here's the Exact Breakdown. TL;DR — No ads, no PR agency, no paid promotion. Just specific, honest, cross-platform posting, one external "100% Clean" certification, and a refusal to oversell. Here's exactly what moved the needle, in order of impact. Akhouri Systems started with nothing — no audience, no mailing list, no existing following. Just a GitHub account, a Windows security suite called ATLOCK, and enough confidence in the product to put it in front of strangers. Here's what actually happened. 📊 The Starting Point Day 1Audience0Ad budget $0 Team1 (me)Funding ₹0Product ATLOCK — a Windows security suite, single .exe, offline-first 🎯 What Actually Moved the Needle 1️⃣ Specificity beats enthusiasm, every time Every post that worked wasn't "check out my app" — it was a verifiable technical claim: NTFS ACL-level file locking that even admin can't bypass. AES + PBKDF2 vault encryption, 200,000 iterations. Developers can smell vague marketing copy from a mile away. Real numbers and real mechanisms are the entire trick. 2️⃣ Same product, three different posts The same copy-pasted paragraph across every platform reads as spam — even when it's not. So: Platform Angle dev.to Technical breakdown, deep detail Peerlist Short, personal, punchy LinkedIn Credibility-first, professional tone 3️⃣ Admitting weaknesses on purpose One of the highest-engagement posts I wrote was a direct ATLOCK vs. commercial security software comparison — including an honest section on where commercial tools still win (malware detection, official support, code-signing). Nobody trusts a post that claims to be perfect. Naming the weaknesses bought more credibility than it cost. 4️⃣ Independent validation compounds differently Getting listed on Softpedia mattered more than expected — not for raw traffic, but because a "100% Clean" certification and an independent 3.5/5 review from a party with zero stake in the outcome hits differently than another self-posted announcement.

AxonASP is a high-performance Classic ASP engine written in Go — but here's the twist: it runs JavaScript (JScript) natively on the server side. You get a synchronous, predictable execution model, full ECMAScript 5/6+ support, and zero dependency on Node.js or any third-party JavaScript runtime. And yes — you can build an entire production website with it. Why AxonASP Changes the Game for Server-Side JS Most developers associate server-side JavaScript exclusively with Node.js. And Node.js is great — until you're drowning in async/await chains, package.json conflicts, and the 47th minor version bump of a dependency that broke your build. AxonASP takes a fundamentally different approach. Instead of wrapping everything in an event loop and forcing asynchronous patterns everywhere, AxonASP's JavaScript engine executes code synchronously by default . You write your server logic the same way you write your frontend logic — line by line, top to bottom. It compiles through a high-performance AST parser and runs directly on a custom Go-based virtual machine. The result? Cleaner code, simpler debugging, and a massive reduction in cognitive overhead. What You Get Out of the Box Full ES5 + ES6 support (classes, arrow functions, template literals, destructuring, proxies, for...of , Map , Set , Symbol , typed arrays — 37+ modern features documented) Synchronous execution — no callback pyramid, no promise chains for basic I/O ASP intrinsic objects — Request , Response , Session , Application , Server — all accessible directly from your JS code No npm install required — just write .asp or .js files and point the server at them CLI execution — run JavaScript files from the command line for automation, batch processing, or testing The Philosophy: Simplicity Over Complexity Here's a hard truth: most web applications don't need 2,000 npm modules. They need to read a database, render HTML, handle form submissions, and maybe serve a JSON API. That's it. The modern JavaScript ecosystem ha

If you are like me, then you have also tried to change a specific thing in your workout plan that your app of choice didn't support. Well I'm trying to fix that issue with a workout app in which you'll be able to customize pretty much everything (WIP). Building the thing in Flutter to have mobile (starting with Android) and web. The web app is live! If you work out and have tried similar apps before, your feedback would be gold. But really any feedback is appreciated. I also found that finding the required 12 people with an Android phone for closed testing on Google Play Console was more difficult than anticipated. So if you'd be interested in that, hit me up at dev@notes.fitness ! Gym Notes — A Customizable Workout Logbook for Strength Training A free, customizable workout logbook that tracks exercises, sets, reps, and weights. Built-in training plans with automatic progression. gym.notes.fitness

I Built a Crew of AI Agents That Review Code Like a Real Team — Then Watched Them Argue With SigNoz My submission for the Agents of SigNoz Hackathon (Track: AI & Agent Observability) The idea Most "AI code review" demos are one LLM call with a clever prompt. That's fine, but it doesn't reflect how review actually works on a real team — different people care about different things. Someone obsesses over edge cases. Someone else nitpicks naming. Someone else only cares if it's going to be slow in production. And then someone has to actually make the call on whether the PR merges. So I built that as a crew: a Logic Reviewer , a Style Reviewer , and a Performance Reviewer — three independent agents, each with a narrow system prompt that tells them to only look at their lane — followed by a Moderator agent that reads all three opinions and produces one final verdict, calling out disagreement when it happens. The interesting engineering problem wasn't the prompting. It was: once you have four chained LLM calls, how do you actually know what's happening inside your own system? Why observability, not just another agent demo Once I had the crew working, I had zero visibility into it. Four sequential API calls, each with its own latency and token cost, and all I had was print() statements. If the moderator gave a weird verdict, I had no fast way to tell whether the logic reviewer hallucinated an issue, or the moderator just summarized badly. If a run felt slow, I couldn't tell which of the four agents was the bottleneck. This is exactly the gap SigNoz is built for, so I instrumented every agent call with OpenTelemetry: Each specialist agent and the moderator run inside their own span ( agent.logic_reviewer , agent.style_reviewer , agent.performance_reviewer , agent.moderator ) All four are nested under one parent span, code_review_session , so a single review run shows up as one trace with four child spans Every span carries the attributes that actually matter for debugging a

Every team doc tool promises "search everything." Ours did too — and it still didn't answer the question new hires actually ask: not "where is this doc," but "why does this decision look the way it does, and what else does it touch?" We spent the last few months trying to solve that by treating team docs less like a filing cabinet and more like a graph. Here's what we tried, what broke, and what we'd do differently.

Why We Built This As developers and builders at Smart Tech Devs , we love analyzing data trends. But when it comes to trading charts—whether it's crypto, stocks, or forex—reading technical signals manually requires hours of screen time. Beginners struggle with complex patterns, and experienced traders often want a quick sanity check on their thesis. We asked ourselves: Can we leverage Vision LLMs to turn static chart screenshots into professional-grade technical analysis reports in seconds? That question led us to build and launch Realtime Chart Analyzer (ChartAI Pro) , now live on the Google Play Store! ⚡ Key Architectural Features We designed ChartAI Pro to act as a seamless, secure second pair of eyes for market charting. Here is a breakdown of what the application delivers right out of the box: 🧠 1. Multi-Modal AI Chart Analysis Instant Processing: Upload or snap a screenshot from platforms like TradingView, Binance, Zerodha, Groww, Upstox, or MT4/MT5. Signal Detection: The core engine evaluates market structures to return clear Bullish or Bearish indicators alongside an AI confidence score. Plain-English Summaries: No overly dense academic jargon—you receive an intelligible breakdown of current market conditions. 🎯 2. Automated Key Price Levels & Patterns Support & Resistance: The system instantly flags primary macro price horizons. Risk Mitigation: Calculates approximate entry zones, mathematical target price targets, and clear Risk/Reward ratios. Geometric Processing: Detects complex shapes including Head & Shoulders, Double Tops/Bottoms, Triangles, Wedges, Flags, and specialized candlesticks (Doji, Engulfing lines). 📊 3. Native Live Market Infrastructure Live Scanners: Includes a built-in terminal tracking real-time crypto, forex, and stock prices (NSE & BSE). Interactive Tooling: Features built-in interactive TradingView frames directly in the layout, allowing you to scan Top Gainers and Losers without hopping between apps. 🔒 Privacy & Security First When d

I was tired of studying security tools from static cheatsheets, so I built ShellStack When I started prepping for CEH and doing more CTFs, I ran into the same wall over and over: every resource for learning offensive security tools was either a wall of text in a PDF, a GitHub gist with no context, or a cheatsheet that assumed you already knew what half the flags did. I didn't want notes. I wanted something that felt like sitting at an actual terminal — where I could browse tools, see real commands with context, and build the exact command I needed without digging through five tabs. So I built ShellStack . 🔗 Live: https://shell-stack.vercel.app/ 💻 Code: https://github.com/shlokkokk/ShellStack What it actually does ShellStack is a cybersecurity study platform built around one idea: learning security tools should feel operational, not passive. 280+ curated offensive security tools , organized into 19 categories, each with deep-dive docs — commands, common flags, when to use it, installation notes, and real examples Interactive command builders — instead of memorizing flag combos, you fill in a form and get a ready-to-copy command generated live 20 CEH-aligned learning modules , built for structured study instead of flipping through slides 1,000+ command cheat sheet with fast search and one-click copy A terminal-inspired UI that actually feels like a cyber-ops console instead of another docs site The build Stack: React 19, TypeScript, Vite, Tailwind CSS, GSAP, React Router, Radix UI primitives A few things I focused on: Search that actually ranks results. Early on, tool search was just naive string matching, which meant typing "nmap" could bury the actual Nmap entry under ten unrelated tools that happened to mention it in a description. I rebuilt it to weight exact and prefix matches higher, so the tool you're looking for shows up first, not buried on page 3. Command builders that don't feel like a form. The tricky part wasn't the UI, it was designing a data model that

Over the last few months I’ve noticed a pattern emerging across AI tools. Whether it’s Claude Skills, Cursor, Codex, or custom agent frameworks, we’re increasingly giving AI agents “skills”—packages containing instructions, documentation, and sometimes scripts. The problem is… A skill is usually just a Markdown file (plus some assets). Nothing tells you: Who created it. Whether it has been modified. Whether the version your AI is executing is the same one you reviewed yesterday. Whether someone quietly injected new instructions into it. As AI agents become capable of executing increasingly powerful workflows, that becomes a real supply-chain problem. So I built Skillerr. ⸻ What is Skillerr? Skillerr is an open-source protocol and CLI that adds trust and verification to AI skills before they’re executed. Instead of treating a skill as “just another folder,” Skillerr treats it as a verifiable package. It focuses on three things. Package Integrity Every packaged skill receives a unique content-derived identifier along with cryptographic SHA-256 hashes. If any file changes after packaging—even a single character—Skillerr detects it immediately. No silent modifications. ⸻ Structured Contracts Instead of relying on long paragraphs that an AI has to interpret, a Skill contains a structured contract describing: required inputs permissions forbidden actions expected outputs whether a human has actually reviewed it This makes skills easier for both humans and AI agents to reason about. ⸻ Optional Public Provenance Authors can cryptographically sign their skills. Optionally, the package digest can also be anchored into Sigstore’s transparency log, making it independently verifiable without trusting Skillerr itself. Importantly: Only cryptographic identifiers are published. No prompts. No documentation. No knowledge base. No proprietary content. ⸻ I tried to break my own tool Before releasing it, I intentionally attacked it. First I packaged and signed a simple CSV processing s

I'm not an engineer. I built a prompt-structuring tool anyway, using Claude Code — here's what actually went wrong 🤔 The problem I don't write code. I'm not an engineer, day to day — but I use AI chatbots constantly, and I kept running into the same annoying pattern. I'd type something lazy into ChatGPT or Claude — half a sentence, no context, whatever came to mind first — and get back a mediocre answer. Then, later, I'd realize: if I'd just written a slightly better prompt, I probably would've gotten a much better answer on the first try. Instead I'd burned a chunk of my monthly quota (sometimes on a paid plan) on something forgettable. I figured other people had to be doing the same thing. So I built something for it. 💡 What I built It's called Deep Prompt Studio . You paste in a rough, unpolished prompt — the kind you'd type without thinking too hard — and it hands back a detailed version that pulls in whichever pieces actually matter for that request: role, task, constraints, output format, and more. It's not tuned for one specific chatbot; it's meant to work well whether you're pasting the result into ChatGPT, Claude, Gemini, or something else. https://deep-prompt-studio.vercel.app 🛠 Tech stack Next.js (App Router, Turbopack) + TypeScript Tailwind CSS Anthropic Claude API for the actual prompt enhancement Stripe for payments Upstash Redis for storage Deployed on Vercel ⚙️ How it works Tone selector — Default, Professional, Casual & friendly, Concise, Direct Target-model optimization — Generic, ChatGPT, Claude, Gemini, Midjourney Snippets — save reusable context/tone/role info and toggle them on or off per enhance (free: up to 3, Pro: unlimited) Variable fill-in — template placeholders like {{product name}} you can reuse Refine mode — if your prompt is too vague, it asks a couple of follow-up questions before enhancing, instead of guessing Template gallery — writing, coding, business, learning, SEO, customer support Library — saved enhanced prompts (Pro) Free ti

footnote-mcp is a Python MCP server installable via pip, Docker, or pipx. No API keys required — it falls back to scraped Bing + DuckDuckGo search and automatic headless Chromium for JavaScript-heavy pages. The Verification Pipeline The core tool is evidence_entailment . It takes a claim and a source text, and returns whether the claim is supported, unsupported, or contradicted. The heuristic backend extracts numeric and named-entity tokens from both the claim and source, then checks for exact matches and contradictions. On its design domain — numeric and factual data claims — it achieves 100% accuracy on a labeled benchmark set. For semantic cases (negation, paraphrase), the ollama backend uses a local LLM as a judge. Three tools build on this: corroborate_claim triangulates a claim across multiple sources, locate_claim_span finds the exact supporting sentence with character offsets, and build_research_debug_report produces a compact report of queries, URLs, and verification gaps. The Fetch Ladder web_read fetches pages through a 5-tier escalation ladder: HTTP (curl_cffi) to rotating proxy to headless Chromium to Chromium through proxy to hosted scrape API (Firecrawl/ScrapingBee). A block/quality detector decides when to escalate, and per-domain rate limiting, circuit breakers, and negative cache keep it polite. Search Backends web_search supports Tavily, Brave, Google, or scraped Bing + DuckDuckGo as fallback. Pass semantic: true to reorder results by meaning using local Ollama embeddings. Structured Data and Browser Tools Beyond text, the server handles tables, CSV/XLSX/PDF/JSON, date validation, unit resolution, and time series reconciliation. For JavaScript-heavy pages, 10 browser tools let you drive a headless Chromium session. When generic parsers fail, the server can synthesize sandboxed extraction code through a controlled recipe system. Benchmark Results The heuristic backend achieves 100% accuracy on numeric and factual data claims (n=15). Overall accurac

variant-confidence v0.1.0: a calibrated confidence layer for variant-effect pathogenicity scores State-of-the-art variant-effect models are accurate in cross-validation but their scores are poorly calibrated on temporal data. variant-confidence adds an auditable calibration layer on top of existing predictors — it does not train a new model. The problem: accuracy is not trust Protein variant-effect predictors (AlphaMissense, ESM-1v, EVE) report pathogenicity scores, but a clinician or researcher needs to know how much to trust the number , not just its rank. The gap is calibration, not accuracy: AnnotateMissense (2026) reports MCC 0.94 in cross-validation, dropping to 0.76 on temporal ClinVar, accuracy 0.8798. A raw score near 0.9 may not mean 90% probability. Acting on an uncalibrated score is a risk. What it does variant-confidence wraps an existing predictor's score and produces a calibrated, uncertainty-aware output: Probability calibration (AC1): Platt scaling or isotonic regression over a separate holdout. Selectable, not hardcoded. Conformal prediction (AC1b): coverage 1−α intervals, split or Mondrian by gene. ECE (AC2, AC9): Expected Calibration Error reported before/after calibration, with bootstrap CI and per-bin counts. Bins with too few samples are flagged as low-reliability. Leakage-free split (AC3): temporal split by ClinVar release date with gene isolation — the same gene never appears in both train and test. This is unit-tested. Missing-score handling (AC4): works with AlphaMissense or ESM-1v alone; emits an explicit warning instead of failing silently. Non-deceptive reporting (AC7): every result includes interval/ECE + method + threshold, never a bare calibrated score. Verification (clean clone, no network) Built under a three-party governance loop: implement → independent audit in a clean clone → merge approval. ruff check . → All checks passed. pytest tests/ → 28 passed in 8.90s (offline fixture). An honest bug we caught in audit The first ECE tes

I put together a small, unofficial public ledger that records dated snapshots of the public pricing, usage limits, and rate limits of a few AI coding tools — currently Cursor, GitHub Copilot, and Claude Code — and keeps the history so you can see what changed over time. Why: pricing and quota pages change in place. The old value disappears from the live page and there is usually no public diff. If you are budgeting a team or comparing tools, the history is the useful part, and it is the part the live pages do not keep. What it is / isn't: - It records only factual public values (a price, a numeric limit) plus a short source attribution and capture date. It does not reproduce vendor pages. - "silent" / "quiet" here means only that a change was not paired with a prominent announcement when it was recorded. It makes no claim about any vendor's intent. - Unofficial. Not affiliated with any vendor. The vendor's official page is always authoritative. No affiliate links, no "best tool" ranking. - Early stage: this is an initial snapshot; a daily automated capture is planned but not yet running. Repo: https://github.com/pricing-ledger-lab/ai-coding-tool-pricing-ledger Corrections welcome — open an issue with a source URL and the date you observed the value.

As a developer, I regularly find myself searching for small online utilities. Format some JSON. Decode a JWT. Test a regex. Generate a UUID. Convert a timestamp. Format an SQL query. Calculate a CIDR subnet. None of these tasks individually justify installing another application. But over time, I ended up with a collection of bookmarks to different websites, each solving one small problem. There was also another issue: privacy. Sometimes the data I'm working with isn't something I necessarily want to paste into an unknown third-party website. So I decided to build an alternative. The constraint: one HTML file I wanted the entire application to exist as a single file. No backend. No npm install. No CDN dependencies. No external API calls. No account. No telemetry. You download the HTML file, open it in a modern browser, and everything runs locally. The final file ended up at approximately 133 KB and contains 31 developer tools. What's inside? The tools are organized into six categories. Encode / Decode JSON Formatter & Validator Base64 Encode / Decode URL Encode / Decode HTML Escape / Unescape JWT Decoder Number Base Converter Generators UUID Generator Password Generator with entropy estimation Hash Generator Slug Generator Lorem Ipsum Generator Random Data Generator Converters Timestamp Converter CSV ↔ JSON JSON ↔ YAML CSS Unit Converter Case Converter Cron Expression Parser CSS Tools Color Picker & Converter Gradient Generator Box Shadow Generator Border Radius Generator CSS Filter Generator Text Tools Regex Tester Markdown Preview Text Diff Character Counter Text Sort & Dedupe String Inspector SQL Formatter Network Tools IPv4 Address and CIDR/Subnet Calculator Everything happens inside the browser. Making a single HTML file feel like an application I didn't want the result to feel like 31 unrelated forms dumped onto one page. So I added some application-level functionality. There's a Ctrl+K / Cmd+K command palette for quickly jumping between tools. The sidebar org

a local, Claude-powered brain-assistant for solopreneurs I kept losing good ideas — not because I forgot to write them down, but because nothing ever went back and connected them. A task on Monday, an idea on Wednesday that was secretly the same problem, a question on Friday that contradicted something I'd decided two weeks earlier. All of it just... sat there. So I built Dot Connector : a small local app where every capture is a "dot," and every few captures, Claude reviews the stream against a standing memory and surfaces three things — non-obvious connections between notes, contradictions with what you said before, and open loops you haven't closed yet. The architecture is deliberately simple. It's Express + vanilla JS, no build step, no account system. Every capture gets a cheap, fast Claude call for auto-tagging. Every 3rd capture triggers a deeper "sweep" — a second Claude call that looks at recent captures alongside standing memory and open loops, and returns structured updates: new memory facts, dot-connects, contradictions, and open-loop resolutions. Why local-first. no server of my own, notes never leave your machine except the direct calls to Anthropic's API, bring-your-own API key so there's no subscription — you pay Anthropic directly, typically well under $1/month for personal use.] Its just a steal one-time $29 download All info and download get it here: https://dot-connector.eu