标签：#showdev

I 've been using Cursor on non-trivial repos and kept hitting the same issue: the agent finds a file but misses routes, shared modules, and tests that should run after a change. I built FlowIndex — a local CLI + MCP server that scans a repo and builds a behavior graph in SQLite (entrypoints, imports/calls, tests, git co-change). No embeddings, no SaaS, no LLM calls in the index itself. Setup: pip install "flowindex[mcp]" In your project: flowindex init flowindex scan Add to ~/.cursor/mcp.json (use your repo' s absolute path for cwd ) : { "mcpServers" : { "flowindex" : { "command" : "flowindex" , "args" : [ "mcp" ] , "cwd" : "/absolute/path/to/your/repo" } } } 4. Restart Cursor — you get tools like get_change_impact, suggest_tests, make_context_pack, explain_entrypoint, get_repo_overview. Example workflow: before editing payments/ledger code, ask the agent to use make_context_pack or get_change_impact on that file — it pulls from the local graph, not a generic file search. Honest limits: static analysis + git heuristics only. Call paths resolve via imports but aren 't compiler-grade. TS/JS is heuristic. Documented in the README. MIT · pip install flowindex · https://github.com/adu3110/flowIndex Curious if others use MCP for repo context and what tools you wish existed. Happy to fix setup issues if anyone tries it.

Part 4 of the Building Enterprise AI Automation Systems Series Introduction Most Named Entity Recognition (NER) tutorials end with a prediction. The model successfully extracts: COMPANY INVOICE CONTRACT PURCHASE_ORDER The article ends. The notebook prints a beautiful JSON response. Mission accomplished. Or so it seems. In real enterprise systems, extracting entities is only the beginning. Consider the following prediction: { "COMPANY" : "ALPHABRIDGE" , "INVOICE" : "MFG-INV-000157" } At first glance, everything looks correct. But from a business perspective, the system still knows almost nothing. Questions remain unanswered. Which ALPHABRIDGE? Which customer record? Which contract? Which invoice? Which business relationship? These questions belong to a completely different problem known as Entity Resolution. Entity Resolution transforms extracted text into business knowledge. Without it, AI understands words but not businesses. NER Finds Text Named Entity Recognition answers one question: "What pieces of text represent meaningful entities?" For example: PAYMENT FROM ALPHABRIDGE SOLUTIONS MFG-INV-000157 becomes { "COMPANY" : "ALPHABRIDGE SOLUTIONS" , "INVOICE" : "MFG-INV-000157" } This is extraction. Nothing more. The model has no idea whether: the company exists, the invoice exists, the invoice belongs to the company, the invoice has already been paid, the contract is still active. Extraction is syntax. Enterprise automation requires semantics. The Hidden Problem Imagine the following customer master. CUS-00001 ALPHABRIDGE SOLUTIONS Now imagine receiving these transaction narratives. PAYMENT FROM ALPHABRIDGE PAYMENT FROM ALPHABRIDGE LTD PAYMENT FROM ABS PAYMENT FROM ALPHA BRIDGE Humans immediately recognize these as the same customer. Machines do not. To a computer, every string is different. Without resolution, automation immediately breaks. What Entity Resolution Actually Does Entity Resolution answers a different question. Instead of asking: "What entity is this?"

Part 3 of the Building Enterprise AI Automation Systems Series Introduction Named Entity Recognition (NER) is one of the oldest problems in Natural Language Processing. Most tutorials introduce NER using examples like: Person Organization Location Date A sentence such as: Elon Musk founded SpaceX in California. becomes PERSON ORGANIZATION LOCATION While this is useful for learning NLP fundamentals, it has very little relevance to enterprise software. Businesses do not automate biographies. They automate operations. Enterprise documents contain an entirely different language. Invoices. Contracts. Purchase Orders. Bank Statements. Remittance Advice. Payment Narratives. ERP Exports. The entities that matter inside these documents are not "PERSON" or "LOCATION". Instead, they are business concepts such as: Customer Contract Invoice Purchase Order Payment Type Understanding these entities is the first step toward intelligent automation. In this article, we'll build a Financial Named Entity Recognition pipeline capable of transforming raw enterprise transaction narratives into structured business knowledge. The Difference Between Generic NER and Enterprise NER Traditional NER focuses on linguistic entities. Enterprise NER focuses on operational entities. Consider the following sentence. PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157 A generic language model may identify: Organization and ignore everything else. From a business perspective, this is almost useless. What we actually need is: PAYMENT_TYPE COMPANY INVOICE The objective is not language understanding. The objective is business understanding. Step 1 — Designing the Business Taxonomy Before training any model, define what the model should learn. This is one of the most overlooked stages in machine learning projects. Many teams immediately begin annotation without first defining a taxonomy. As a result, annotations become inconsistent. Models become confused. Evaluation becomes unreliable. For our transaction intell

Part 2 of the Building Enterprise AI Automation Systems Series Introduction One of the biggest obstacles in enterprise AI is not choosing a model. It is finding data. Most tutorials assume that training data already exists. Reality is very different. Large organizations rarely share operational datasets. Financial transactions contain confidential information. Contracts contain sensitive agreements. Invoices reveal commercial relationships. Bank statements expose customer activity. For legal, regulatory, and competitive reasons, these datasets almost never become public. This creates a difficult problem for AI engineers. How do you build intelligent systems when the data you need cannot be accessed? The answer is synthetic data. Unfortunately, most synthetic datasets found online are little more than randomly generated CSV files. They contain names. Numbers. Dates. But they completely ignore something far more important: Business relationships. In this article, we'll explore how to design synthetic enterprise datasets that preserve real business logic and can be used for machine learning, automation, benchmarking, and AI engineering. Random Data Is Not Synthetic Data Many developers believe synthetic data simply means generating fake values. For example: Customer,Invoice,Amount John,INV001,500 Alice,INV002,1200 Bob,INV003,900 Technically, this is synthetic. Practically, it is useless. Why? Because enterprise systems are built around relationships. Invoices belong to contracts. Contracts belong to customers. Payments reference invoices. Purchase orders authorize invoices. Bank transactions settle invoices. Without these relationships, there is nothing meaningful to learn. A machine learning model trained on isolated records learns isolated patterns. Real enterprise automation requires connected data. Thinking Like an Enterprise System Before writing a single line of Python, ask one question: "How does the business actually operate?" Imagine a manufacturing company. A

got annoyed that pastebin and similar sites log everything and keep your text forever, so i built one where the server literally cant read what you paste. heres how the encryption actually works and what i learned building it the problem most paste sites work like this: you type something, it goes to their server as plain text, and it sits in their database. they can read it. their employees can read it. anyone who breaches them can read it. and a lot of them keep it forever even after you think its gone. i didnt want to just promise not to look at your stuff. i wanted it so that i cant look even if i wanted to. the idea: encrypt before it leaves the browser the trick is that all the encryption happens on your side, in the browser, before anything gets sent. the server only ever sees scrambled bytes. the key never touches the server at all, it lives in the part of the url after the # , which browsers dont send in requests. so the flow is basically: you paste text browser generates a random key text gets encrypted with that key only the encrypted blob goes to the server the key gets stuck in the link after a # whoever opens the link decrypts it locally the actual code modern browsers have the Web Crypto API built in, so you dont need any library for this. heres the encrypt part, stripped down: \ `js async function encrypt(text) { const key = await crypto.subtle.generateKey( { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"] ); const iv = crypto.getRandomValues(new Uint8Array(12)); const encoded = new TextEncoder().encode(text); const ciphertext = await crypto.subtle.encrypt( { name: "AES-GCM", iv }, key, encoded ); // export the key so we can put it in the url const rawKey = await crypto.subtle.exportKey("raw", key); return { ciphertext, iv, rawKey }; } ` \ the ciphertext and iv go to the server. the rawKey gets base64'd and dropped into the link after the # . decrypting is just the same thing in reverse with crypto.subtle.decrypt . the thing that tripped

There's a specific kind of bad documentation that I think we've all suffered through. You search for "what is a goroutine" or "how do database transactions work" and you get one of two things: either a six-page academic paper that assumes you already know the answer, or a tutorial so watered-down it covers nothing real. What you actually want is someone like that senior engineer at your company the one who, when you finally work up the nerve to ask a dumb question, sits down and actually explains the thing. Not just the what, but the why. Not just the happy path, but the part where you'll get confused at 2am and what to do about it. I've been building that resource. It's called The Missing Manual. Here's the pitch in one sentence: it's a free, growing library of developer guides written like advice from a battle-hardened friend who genuinely wants you to understand the thing, not just copy the code. Some examples of what's in there right now: Reading a Stack Trace at 2am — starts with "that wall of text is not an attack, it's a map," then teaches you the four-step method that works in Python, JavaScript, Java, or whatever you're using. Includes the site-packages/ vs your-own-code trick that turns 40-line traces into 2-line ones. Go From Zero - covers the basics, but also the deep stuff that most Go tutorials skip: what the GMP scheduler actually does, how escape analysis decides what lives on the heap, why goroutines are cheap in a way OS threads aren't. Mental-model-first, the whole way through. Docker Without the Magic - doesn't just show you docker run. Explains what a namespace and a cgroup actually are, so when Docker does something weird, you have somewhere to start. Why Is My Query Slow? - the real answer, including EXPLAIN, index cardinality, the N+1 problem, and what "using index" in a query plan actually means vs what you want it to mean. There are 160+ guides across debugging, databases, infrastructure, networking, APIs, AI/ML, performance, and programmin

Introduction With the World Cup 2026 group stage reaching its climax, football fans worldwide are speculating about who will make it to the finals. To make this experience interactive, I built a fully dynamic World Cup 2026 Bracket Simulator. Instead of just letting users click and choose winners, this app dynamically calculates ELO win probabilities and probabilistically generates realistic match scores (including extra time and penalties) based on team ratings. It also syncs with live match data in real-time. Live URL: https://worldcup-predict2026.github.io/champion/ Tech Stack: Vanilla JS, CSS3 (3D parallax), GitHub Actions, Python, football-data.org API Core Features & Technical Implementation ELO-Based Win Probability & Score Simulation Each team in the database is assigned an ELO-based strength rating. When a user runs the AI auto-prediction, the script calculates win probability and generates a realistic scoreline. Here is the goal roll algorithm (Poisson-like simulation) implemented in Vanilla JS: javascript function generateMatchScore(team1, team2, winner) { if (team1 === "TBD" || team2 === "TBD" || !winner) return null; const s1 = teamStrengths[team1] || 70; const s2 = teamStrengths[team2] || 70; const winnerIsTeam1 = (winner === team1); const strengthDiff = Math.abs(s1 - s2); const baseGoalExpected = 1.1; const bonusGoal = Math.min(1.8, strengthDiff / 12.0); // Goal weight based on ELO difference const rollGoals = (lambda) => { let L = Math.exp(-lambda); let k = 0; let p = 1.0; do { k++; p *= Math.random(); } while (p > L && k < 10); return k - 1; }; let gWin = 0; let gLose = 0; const r = Math.random(); if (r < 0.75) { // Regular time win (90 mins) gLose = rollGoals(baseGoalExpected); gWin = gLose + 1 + rollGoals(0.7 + bonusGoal); return winnerIsTeam1 ? ${gWin} - ${gLose} : ${gLose} - ${gWin} ; } else if (r < 0.92) { // Extra time win (AET) const normalGoals = rollGoals(baseGoalExpected); gLose = normalGoals; gWin = normalGoals + 1; return winnerIsTeam1 ?

If you've shipped anything to the browser, you've used localStorage . And if you've used it for more than five minutes, you've also written this exact line more times than you'd like to admit: const user = JSON . parse ( localStorage . getItem ( ' user ' ) || ' null ' ) The Web Storage API has aged remarkably well for something so small, but it carries three persistent pain points that every frontend codebase ends up papering over by hand. Pain point #1: everything is a string. localStorage.setItem('count', 0) doesn't store the number 0 — it stores the string "0" . Read it back and typeof is "string" . Booleans become "true" / "false" , Date objects collapse into ISO strings (if you're lucky) or "[object Object]" (if you're not), and undefined becomes the literal string "undefined" . So every project grows a thin serialization layer of JSON.parse / JSON.stringify wrappers, plus a pile of defensive try/catch blocks for the day a malformed value sneaks in. Pain point #2: the API is verbose and stringly-typed. getItem , setItem , removeItem — three method calls and a string key for what is conceptually just reading and writing a property. It reads nothing like the rest of your code. Pain point #3: reactivity is broken in the tab you actually care about. The native storage event only fires in other tabs of the same origin. The tab that performed the write never hears about it. So if you want to react to your own storage changes — the overwhelmingly common case — the platform gives you nothing. Stokado is a small, zero-dependency library that addresses all three by wrapping any storage object in a Proxy . It's framework-agnostic, TypeScript-friendly, and works equally well with localStorage , sessionStorage , cookies, async backends like localForage, and a handful of mini-program runtimes. This article walks through what it actually does, feature by feature, with runnable code. Quick start npm install stokado import { createProxyStorage } from ' stokado ' const storage =

AI can generate unit tests in seconds. But how do you know whether those tests are actually useful? Most teams still rely on code coverage and pass rates to evaluate their test suites. The problem is that a test can pass, increase coverage, and still provide little or no additional confidence. We've been seeing examples where AI-generated tests: Duplicate existing coverage Depend on system time or GUID generation Access files, network resources, or environment variables Use ineffective or unnecessary mocking Add maintenance cost without improving quality Today we launched Typemock Test Review, a tool that analyzes tests during execution and identifies duplicate, fragile, ineffective, and high-maintenance tests. Instead of looking only at source code, it combines runtime behavior, code coverage, dependency analysis, assertions, and mocking patterns to determine whether a test is actually contributing value. Some of the issues it can detect: Duplicate tests Hidden external dependencies Flaky test risks Unused or stale fakes Ineffective mocking Tests that increase maintenance without increasing confidence I'm curious how other teams are dealing with the explosion of AI-generated tests. Are you reviewing AI-generated tests differently from manually written tests? Have you found good ways to measure test quality beyond coverage and pass/fail metrics?

Every World Cup there's a moment. Some player nobody outside their domestic league had heard of scores an absolute screamer in a knockout match, and by the time they've finished celebrating, their follower count is climbing like a rocket. I always found that fascinating, but I could never see it happening in real time. By the time the "X gained 3 million followers!" tweets show up, the surge is already over. So this tournament I built a little tracker that snapshots player follower counts on a schedule and shows me the growth curve as it happens. Here's how it works. Why the official APIs were a dead end My first instinct was to do this "properly" with official APIs. That died fast: Instagram's Graph API won't give you follower counts for accounts you don't own. TikTok's research API is academics-only and takes weeks of applications. X's API now starts at $100/month. I just wanted public follower counts — numbers anyone can see by opening the app. I didn't want a data partnership and a legal review. I ended up using SociaVault , which wraps the public profile data from each platform behind one API and one key. One request, one credit, JSON back. The shared client Everything runs through one tiny helper: // Node 18+ has fetch built in const API_KEY = process . env . SOCIAVAULT_API_KEY ; const BASE = " https://api.sociavault.com " ; async function sv ( path , params ) { const url = new URL ( BASE + path ); Object . entries ( params ). forEach (([ k , v ]) => url . searchParams . set ( k , v )); const res = await fetch ( url , { headers : { " X-API-Key " : API_KEY } }); if ( ! res . ok ) throw new Error ( ` ${ res . status } ${ await res . text ()} ` ); return res . json (); } Grabbing follower counts across platforms Each platform nests the count slightly differently, so I use fallback chains to stay defensive: async function instagramFollowers ( username ) { const data = await sv ( " /v1/scrape/instagram/profile " , { username }); const p = data . data ?. user ?? dat

The Idea Like a lot of people, I sometimes struggle with time. Not in an "I'm just bad at planning" way — more like my brain genuinely has a hard time feeling how long things take. Twenty minutes can feel like five. I'll think "I have time" right up until I definitely don't. So I built Ready. Ready is a PWA (a web app you can install on your phone like a native app) that counts down to your next event — but not just to the event itself. It counts down to when you need to leave, factoring in both how long it takes you to get ready and how long the journey takes. It sends you push notifications before it's time to move. So you don't accidentally forget about time, run out the door ..late again! The app was designed with time blindness in mind — a challenge many people experience. The tone is always encouraging, never stressful. No red warnings. No "you're late." Just a gentle nudge that has your back. It's also my portfolio project. I'm a junior developer learning in public, and this is me documenting the whole messy, rewarding process. (Which also happens to be great for recalling what you learned) The Stack — and Why I Chose It Before writing a single line of code, I had to decide what to build with. Here's what I landed on and why: Next.js — a framework built on top of React (a popular way to build web interfaces). I chose it because it handles both the frontend (what you see and click) and the backend (the logic running behind the scenes) in one project. Less setup, more building. Supabase — think of it as a database with superpowers. It handles storing your data and user authentication (logging in and out) out of the box. It has a generous free tier, which is great when you're learning. Tailwind CSS — instead of writing traditional CSS in separate files, Tailwind lets you style things directly in your code using short class names like rounded-full or text-teal-600 . Web Push API + Service Workers — A service worker is a small script that runs in the background of

Spent the week breathing new life into DevNotion—59 commits and over 10,000 lines of code later,...

As a systems engineering student and frontend dev, I wanted a portfolio that looked professional without spending days fighting with design. So I built one — and ended up turning it into a reusable template. Here's what I focused on while building it: 1. Customization from a single file The biggest pain with most templates is digging through components to change your info. I put everything — name, bio, projects, skills, social links — into ONE config file. Edit that, and the whole site updates. 2. Light & dark mode Developers love dark mode, so I made it the default, with a smooth toggle for light mode. Both are fully themed. 3. Mobile-first & responsive Most people will view a portfolio on their phone, so I built it mobile-first and tested it down to small screens. 4. Easy deployment It works out of the box with Vercel or any static host, with a beginner-friendly setup guide in the README. The stack React + Vite Tailwind CSS Formspree-ready contact form You can see the live demo here: devfolio-template-vercel-app.vercel.app I also made it available as a template if it's useful to anyone: https://payhip.com/b/t1VUk Would love to hear your feedback — what do you look for in a developer portfolio? react #webdev #tailwindcss #showdev

I kept running eslint and thinking my codebase was fine — then someone opened a PR and the first comment was "this function needs JSDoc." The problem: linters check your syntax . Nobody checks whether your exported API is actually documented. Those are two very different things. So I built jsdocscan — a zero-dependency CLI that walks your JS/TS files and flags every exported function or class that is missing JSDoc, or has undocumented parameters. What it catches Errors — exported function or class with no /** … */ block at all: ✗ src/api.js:12 fetchUser missing JSDoc ✗ src/utils.js:34 formatDate missing JSDoc Warnings — JSDoc exists but a parameter has no @param tag: ! src/render.js:7 renderCard undocumented params: opts Exit codes are 0 (all clean), 1 (issues found), 2 (usage error) — pipe-friendly. How to use it # scan a directory npx jsdocscan src/ # Python version pip install jsdocscan jsdocscan src/ # skip @param checks — just verify JSDoc exists npx jsdocscan --no-params src/ # machine-readable output npx jsdocscan --json src/ | jq '.[].findings' # summary line only npx jsdocscan --quiet src/ # custom extensions npx jsdocscan --ext .js,.ts src/ What it skips (intentionally) Non-exported functions and internal helpers — these are implementation details Destructured params ({ a, b }) — too many valid @param opts patterns TypeScript type annotations on params — name: string is stripped, @param name is still required Zero dependencies No parsers, no AST, no require("typescript") . It uses a line-by-line scanner that: Detects export function/const/class patterns via regexes Walks backwards to find a preceding /** */ block Compares @param names in the JSDoc against the actual parameter list npx jsdocscan works with zero install time. pip install jsdocscan brings in nothing extra. Links npm: npmjs.com/package/jsdocscan PyPI: pypi.org/project/jsdocscan GitHub (Node): jjdoor/jsdocscan GitHub (Python): jjdoor/jsdocscan-py Both versions pass the same 38-test suite. Same

It launches tomorrow — Wednesday June 24. FocusKit — the ADHD focus app built by an autonomous AI agent from r/ADHD community feedback — goes live on Google Play tomorrow. Free to start. No account required. No ads. (Play Store link will be added here Wednesday when the listing goes live.) Landing page: costder.github.io/FocusKit · Source: github.com/Costder/FocusKit What an AI agent built in ~24 hours pre-launch This is post 4 in the nyx_software build-in-public series. The previous posts covered the build and the pre-launch marketing sprint. This one covers what the marketing agent actually shipped before launch day. In the 24 hours before launch, the marketing agent: Assets shipped: A Nyx-branded landing page with an animated visual timer mockup 3 SEO articles: body doubling for ADHD, time blindness for ADHD, and a genuine comparison against Focusmate, Forest, and Tiimo An ASO-optimized Play Store listing — including switching the title from "ADHD Focus Timer" to "Body Doubling Timer" (the more differentiated, lower-competition keyword) 3 Play Store screenshots and 2 feature graphic options at the exact 1024x500 Play Console spec A LAUNCH.md in the repo with the Show HN draft, r/ADHD post copy, and a submission checklist An optimized GitHub README with hero image and structured feature sections Distribution established: 2 dofollow directory listings: backlinks.fyi (#1226) and LaunchFree.io (pending review) 4 build-in-public posts on this account A 4-page ADHD content hub in the GitHub Pages docs folder What the agent couldn't do The honest accounting: Every revenue-critical last step required a human: bank account for Play Store payout, the Google Play developer account itself, the r/ADHD post (established Reddit account needed), the Show HN post (established HN account needed). The agent also couldn't enable GitHub Pages — one toggle in repo Settings, 30 seconds, but only a human can flip it. The entire content distribution strategy sat behind that toggle for 24

I'm 16, from Pune, India. For the past couple of years I've been building O-AI — a fully local AI desktop assistant. No cloud. No API keys. No data leaving your machine. Everything runs on your own GPU. Why I built it Every AI assistant I tried sent data somewhere. ChatGPT, Copilot, Gemini — all cloud. I wanted something that felt like JARVIS from Iron Man: smart, fast, personal, and private. So I built it from scratch. What O-AI can do Core engine: Runs LLMs fully on-device via llama.cpp / Ollama (zero internet required) Self-learning core — extracts facts from every conversation and stores them permanently Fine-tuning pipeline — train the model on your own data, locally Voice & language: Voice control in English, Hindi, and Marathi via Whisper (running locally) Responds in whatever language you speak Modes: JARVIS mode — arc-reactor HUD, 4 reactive states, British-male voice, "sir" persona Take Over PC mode — full desktop automation Animated floating desktop pet (4 types, draggable, reacts to voice) 30+ automation fast-paths: open apps, search the web, control media, screen vision, run code, edit files, cursor control, social media steps, clipboard ops... Multi-step agent system: plan → execute → verify loop with 14+ step types (web_search, fetch_url, read_screen, run_code, edit_file, open_social, and more) Stack Backend: Python (Flask IPC + agent core) Frontend: Electron + vanilla JS LLM: llama.cpp / Ollama Voice: Whisper (local) + Edge TTS / neural voice Vision: PIL + screen capture The hardest bugs "Says done but isn't" — Early versions reported success even when an agent step failed. Fixed by building a proper outcome verifier that reads the actual result, not the plan. The "opens a random video" bug — Asking the agent to play something would open random YouTube videos. Root cause: the plan validator wasn't catching placeholder URLs like [video_url] . Fixed with a universal content guard on all plans. GPU offloading on Windows — Getting all 32 layers onto the

csv-pipe: read and write CSV in TypeScript, several times faster than papaparse Myroslav Martsin Myroslav Martsin Myroslav Martsin Follow Jun 22 csv-pipe: read and write CSV in TypeScript, several times faster than papaparse # javascript # typescript # webdev # node 1 reaction Add Comment 2 min read

Built a small tool for Claude Code that tracks whether “agent memory” rules actually pay for themselves in token usage. The idea is simple: every persistent instruction should justify itself by reducing future token cost. If it doesn’t, it gets flagged for removal. Over time, a surprising amount of memory ends up being neutral or negative ROI once measured. Check it out, would mean a lot :) Repo: https://github.com/vukkt/token-warden

Every World Cup there's a moment. Some player nobody outside their domestic league had heard of scores an absolute screamer in a knockout match, and by the time they've finished celebrating, their follower count is climbing like a rocket. I always found that fascinating, but I could never see it happening. By the time the "X gained 3M followers!" tweets show up, the surge is already over. So this tournament I built a little tracker that snapshots player follower counts on a schedule and shows me the growth curve in near real-time. Here's how it works. The problem with doing this "properly" My first instinct was the official APIs. That died fast. Instagram's Graph API won't give you follower counts for accounts you don't own. TikTok's Research API is academics-only and takes weeks of applications. X's API now starts at $100/month and climbs steeply from there. I just wanted public follower counts — numbers anyone can see by opening the app. I didn't want a data partnership and a legal review. I ended up using the SociaVault API , which wraps public profile data from each platform behind one key. One request, one credit, JSON back. The shared client Everything runs through one tiny helper: // Node 18+ has fetch built in const API_KEY = process . env . SOCIAVAULT_API_KEY ; const BASE = " https://api.sociavault.com " ; async function sv ( path , params ) { const url = new URL ( BASE + path ); Object . entries ( params ). forEach (([ k , v ]) => url . searchParams . set ( k , v )); const res = await fetch ( url , { headers : { " X-API-Key " : API_KEY } }); if ( ! res . ok ) throw new Error ( ` ${ res . status } ${ await res . text ()} ` ); return res . json (); } Grabbing follower counts across platforms Each platform nests the count slightly differently, so I use fallback chains to stay defensive: async function instagramFollowers ( username ) { const data = await sv ( " /v1/scrape/instagram/profile " , { username }); const p = data . data ?. user ?? data . data ?? data

I did not choose DeepSeek because I think GPT-4 is bad. I chose it because I was building a free app, and free apps teach you what actually matters pretty fast. The question was simple: how do I keep sessions cheap enough that people can practice a lot without me lighting money on fire? The answer pushed me toward DeepSeek-V3 (and later R1 for specific tasks). The real constraint was volume The app is a conversation practice tool. People come in to rehearse hard talks, not to admire the model. A single practice session runs 8-15 turns. Each turn is roughly 300-600 tokens in, 100-300 out. Multiply that by five sessions a week per active user and the costs start compounding. Here is what the math looked like when I was choosing (mid-2026 pricing): Model Input cost (per 1M tokens) Output cost (per 1M tokens) Cost per 10-turn session (est.) GPT-4o $2.50 $10.00 ~$0.04-0.06 GPT-4 Turbo $10.00 $30.00 ~$0.12-0.18 DeepSeek-V3 $0.27 $1.10 ~$0.004-0.007 DeepSeek-R1 $0.55 $2.19 ~$0.008-0.012 At scale, the difference between $0.005 and $0.05 per session is the difference between running a free product and needing a paywall after three conversations. I wanted people to come back daily without hitting a wall. What DeepSeek handled well It stayed in character for 10-15 turns. It pushed back when the user got vague. It followed persona heuristics (numbered if/then rules in the system prompt) about as reliably as GPT-4o did for our use case. For salary negotiation rehearsal, the model needs to say "that's not in the budget" and hold that position for three more turns while the user tries different approaches. DeepSeek-V3 did this. Not perfectly, but reliably enough that sessions felt real. It also made the app easier to run as a free product. People can try, fail, reset, and try again without me worrying about per-session cost. Where GPT-4 was still better GPT-4 (and 4o) is smoother with nuanced emotional wording. When a conversation gets subtle, loaded with subtext, or requires pick