标签：#webdev

My upload CLI looked restart-safe until I tested two failures together: the process crashed at 63%, and the signed resume URL expired before restart. The checkpoint needs identity, not credentials: { "file" : "release.tar.gz" , "fingerprint" : "sha256:..." , "uploadId" : "up_123" , "localOffset" : 66060288 , "updatedAt" : "2026-07-19T12:00:00Z" } Do not persist the signed URL. On restart, exchange the durable upload ID for fresh authorization, query the server offset, then reconcile: const remote = await headUpload ( freshUrl ); if ( remote > file . size ) throw new Error ( " invalid remote offset " ); if ( remote !== checkpoint . localOffset ) { await saveCheckpoint ({ ... checkpoint , localOffset : remote }); } await sendFrom ( file , remote , freshUrl ); The server offset wins because a crash can occur after bytes are accepted but before the local checkpoint is renamed. Save checkpoints through write-to-temp plus atomic rename so a partial JSON file cannot destroy recovery. My fixture matrix includes: Failure Expected behavior crash after remote commit rewind/advance to remote offset expired URL refresh without creating a second upload changed local file stop on fingerprint mismatch missing remote upload ask before starting over checkpoint write interrupted retain previous valid checkpoint The tus resumable upload protocol specifies offset discovery and conflict handling that are useful even if the service uses a smaller custom protocol. The key idea is explicit reconciliation, not assuming client memory is authoritative. I also shipped upload status , upload forget , and an exportable checkpoint directory. Recovery is a user-facing feature; if users cannot inspect or remove state, “resumable” becomes hidden lock-in.

Multipart finalization is not the only retry boundary. Abort can succeed in object storage while the HTTP response is lost, leaving your database convinced the upload is active. Model abort as a state transition, not a button wired directly to an SDK call: active → aborting → aborted └──→ cleanup_pending The endpoint should own an idempotency key and durable intent: await db . transaction ( async tx => { const upload = await tx . lockUpload ( uploadId ); if ( upload . state === " aborted " ) return ; await tx . markAborting ( uploadId , idempotencyKey ); await outbox . enqueue ( " abort-multipart " , { uploadId , storageKey }); }); A worker calls storage. If a retry receives NoSuchUpload , do not blindly fail: reconcile whether the upload was already completed, already aborted, or expired. Only the “already absent because abort succeeded” path may converge to aborted ; completion requires a separate terminal state. Test this sequence: Step Fault Required invariant persist abort intent process dies outbox resumes work storage abort succeeds response is lost retry does not reactivate upload duplicate message delivered twice one terminal state client retries same key same operation result cleanup scan stale active row reconcile before deleting Amazon S3’s AbortMultipartUpload API notes that in-progress part uploads may still succeed around an abort and recommends verifying that parts are gone. That makes a post-abort verification pass part of correctness, not optional housekeeping. Expose abort_requested_at , attempt count, last storage result, and remaining-part count. Alert on age in aborting , then run a lifecycle cleanup policy as a backstop—not as a substitute for application reconciliation.

Removing EXIF GPS protects one privacy boundary. It does not prove that an uploaded JPEG contains only a JPEG. A useful hostile fixture is a valid image followed by bytes for another format. Many decoders stop at JPEG’s end marker and display the picture successfully, while downstream scanners, content sniffers, or accidental downloads may interpret the trailing payload differently. Build a fixture set rather than trusting extensions: clean.jpg valid JPEG exif-gps.jpg valid JPEG with location jpeg-plus-zip.jpg JPEG followed by ZIP bytes jpeg-plus-html.jpg JPEG followed by HTML truncated.jpg missing end marker oversized-dimensions.jpg small file, dangerous decode cost My upload gate has independent layers: Store the original in a non-public quarantine location. Enforce byte-size and decoded-dimension limits. Decode with a maintained image library. Re-encode pixels into a new file, discarding metadata and trailing bytes. Verify the output’s signature, dimensions, and complete parse. Publish only the derived object under a server-generated name. A boundary check can detect bytes after the end marker, but re-encoding is the stronger transformation because it creates a new representation from decoded pixels. Keep the original inaccessible and delete it according to a tested lifecycle. assert ( outputSize <= limit ); assert ( decoded . width * decoded . height <= pixelBudget ); assert ( parseConsumesEntireFile ( output )); assert ( noLocationMetadata ( output )); The OWASP File Upload Cheat Sheet recommends defense in depth: allowlisted types, generated filenames, size limits, storage separation, and content validation. No single MIME header or metadata scrubber replaces that chain. The important privacy lesson is broader than EXIF: inspect every representation that survives the upload pipeline, and publish only a constrained derivative.

An accessible combobox can follow the correct ARIA pattern and still become unusable when two search responses arrive in the wrong order. Reproduce this sequence: Type ca , then quickly type cat . The cat response arrives first and highlights cat facts . The slower ca response arrives and replaces the list. aria-activedescendant now points to an option that no longer exists. IME input adds another boundary: searching during composition can send partial text the user has not committed. I would model the request generation explicitly: let generation = 0 ; let composing = false ; async function search ( query : string ) { const mine = ++ generation ; const options = await fetchOptions ( query ); if ( mine !== generation || composing ) return ; render ( options ); restoreActiveOptionByKey (); } The stable key matters. An array index cannot preserve the active option when ranking changes. Regression matrix Input Injected failure Expected evidence ca → cat first request delayed only cat results render Arrow Down result refresh active key survives or resets visibly Escape response arrives afterward popup stays closed IME composition network is fast no request until compositionend A Playwright test should assert focus remains on the input, every aria-activedescendant resolves to a live element, and Escape invalidates outstanding generations. A manual screen-reader pass should confirm result-count announcements are not emitted for discarded responses. The WAI-ARIA Authoring Practices combobox pattern defines the keyboard contract. The missing production step is testing that contract under asynchronous replacement, not only against static example data. Which stale-response failure has been hardest to reproduce in your search UI?

Installation traceless-style is published to npm. It has no required dependencies at runtime and one optional dependency ( @swc/core ) that the SWC-backed extractor uses for large codebases. 1. Install the package npm install traceless-style # or pnpm add traceless-style # or yarn add traceless-style The package ships pre-built. There is no postinstall step. Peer dependency Required? What for react ≥ 18 Optional Only needed for the React components in traceless-style/dark and traceless-style/rtl ( <TracelessRoot /> , <ThemeToggle /> , <RtlToggle /> ). next ≥ 14 Optional Only needed if you use traceless-style/nextjs . webpack ≥ 5 Optional Only needed if you wire up the raw webpack plugin. vite Optional Only needed for traceless-style/vite . @swc/core Optional Auto-loaded for projects ≥ 100 source files. Falls back to the legacy parser if installation failed. 2. Pick an integration You're using… Install one of Next.js (App Router or Pages) traceless-style/nextjs Webpack directly (CRA-style or Rspack) traceless-style/webpack Vite traceless-style/vite Rollup traceless-style/rollup esbuild traceless-style/esbuild Just Node + a build script The CLI: npx traceless-style Each integration page contains a copy-paste config snippet. 3. Run init (recommended) npx traceless-style init This zero-config scaffolder: Detects your framework (Next, Vite, Remix, Astro). Adds the bundler plugin to your config file. Adds <TracelessRoot /> to your root layout (anti-flash dark + RTL script). Creates traceless-style.config.js if missing. Adds dev / build scripts to package.json if missing. Suggests installing the VS Code extension via .vscode/extensions.json . The scaffolder is idempotent — re-running it will not duplicate edits. 4. Verify the install Create a tiny component: // app/test-install.tsx import { tl } from " traceless-style " ; const $ = tl . create ({ hello : { color : " tomato " , padding : " 1rem " , fontSize : " 1.25rem " }, }); export default function Test () { return < div

I run several AI coding agents at once and never really knew what they were doing — what it cost, which one was stuck, what they just changed. So I built agentglass : real-time mission control and a workspace for AI coding agents, across every provider and every project on your machine. ▶ Live demo (no install) · ⭐ GitHub What it does Point any agent at it — Claude Code hooks or any OpenTelemetry exporter (Codex, Gemini, Bedrock…) — and watch everything move live: 💰 Cost per event / session / model ⏱️ Tool latency (real p50 / p95) 🔴 Error timelines + a "what needs you" alert center 💾 Persists (SQLite) — history's there the moment you open it More than a viewer — a workspace All one keystroke away, same cockpit: 🔬 Diff & review — every Edit/Write, syntax-highlighted 🌿 Source control — lazygit in the browser 🐳 Docker — lazydocker in the browser ▶ Real terminal — an actual PTY shell, not an emulation 💬 Chat — drive local Claude sessions Open source (MIT), local-first Built solo. Small stack: Bun + SQLite, React/Vite, Tauri desktop, a stdlib-only Python hook forwarder. If you run more than one agent at a time, I'd love your feedback 👇 ⭐ https://github.com/SirAllap/agentglass

Я заглянул туда. Там дохуя документации. Дикий геморой мусорки. Бесконечный склад, который вгоняет меня в панику. Но как инструмент это незаменимая часть Web. Я беру нужный мне чертёж и строю то, что мне нужно. window глобальный объект. Подключение к API старого браузера. Это Мозг, который даёт мне инструменты: Скелет HTML: (document) Память Хранилище: (localStorage) Сеть API: подключение к контрактам других серверов для сбора информации (fetch) Но главное, что я заценил это обработчик событий onload. Это и есть чудо архитектуры. Связь CSS, JS, HTML в корневой папке предка HTML. Я скидываю в него свой модуль, и он гарантирует, что всё запустится, когда скелет будет готов.

Last week I was reviewing the staking engine of a protocol before its mainnet launch. Deep in a 1,400-line contract, I found what looked like a serious bug. The reward math multiplied three values before dividing: uint256 delta = (lot.amount * rBase * midpointRate) / (RAY * RAY); Multiply-before-divide. If that intermediate product overflows uint256 , the whole epoch settlement reverts — and since every stake , withdraw , and setStake runs it, the post's funds get permanently frozen . That's a High-severity, fund-locking DoS. I had the finding half-written. lot.amount can reach 10M tokens ( 1e25 ). rBase grows with elapsed time. midpointRate can hit RAY . Multiply those and you blow past 2^256 ... I was ready to send it. Then I did the one thing that separates a real audit from false-positive spam: I checked the actual constants before writing the claim. uint256 private constant RAY = 1e18; // I'd assumed 1e27 RAY was 1e18 , not the 1e27 I'd been carrying in my head. And the interest rate had a hard cap — MAX_RATE_MAX_RAY = 5e18 , enforced even against a fully-captured timelock. I ran the numbers with the real values: For that multiplication to overflow, the protocol would need to go 2.3 × 10¹⁵ years without a single state update. Not reachable. The bug didn't exist. I deleted the finding. Why this matters more than the bug would have If I'd sent that report, here's what happens: the team's engineer clones the repo, plugs in the real constants, and realizes in ten minutes that I flagged an overflow that can't happen. Every other finding in my report now gets read with a raised eyebrow. My credibility — the entire product — is gone. This is the dirty secret of automated smart-contract auditing: the bottleneck isn't finding issues. It's not drowning the real ones in false positives. Anyone can run a scanner and paste 40 "criticals." A team that has to triage 40 flags to find the 2 that matter will — correctly — stop trusting you. The bar I hold: zero false positives o

Modern web applications demand responsive, non-blocking user flows. This tutorial demonstrates a production-grade implementation for handling form submissions without full-page reloads using the native Fetch API and clean async/await syntax. The Complete Source Code Create a file named app.js and drop in the following event-driven architecture: JavaScript document.getElementById('registrationForm').addEventListener('submit', async (event) => { event.preventDefault(); // 1. Stop full page reload const form = event.target; const formData = new FormData(form); const submitBtn = form.querySelector('button[type="submit"]'); const responseMessage = document.getElementById('responseMessage'); // 2. UI Feedback: Disable button during network request submitBtn.disabled = true; submitBtn.textContent = 'Processing...'; responseMessage.textContent = ''; try { // 3. Asynchronous Fetch Request const response = await fetch(form.action, { method: 'POST', body: formData, headers: { 'X-Requested-With': 'XMLHttpRequest' } }); // 4. Status Code Validation if (!response.ok) { throw new Error(`HTTP error! Status: ${response.status}`); } const result = await response.json(); // 5. Dynamic UI State Handling if (result.success) { responseMessage.style.color = '#155724'; responseMessage.textContent = result.message; form.reset(); // Clear form on success } else { responseMessage.style.color = '#721c24'; responseMessage.textContent = result.error || 'Submission failed.'; } } catch (error) { // 6. Global Error Catching responseMessage.style.color = '#721c24'; responseMessage.textContent = 'A network error occurred. Please try again.'; console.error('Submission tracking error:', error); } finally { // 7. Reset UI State Guaranteed submitBtn.disabled = false; submitBtn.textContent = 'Submit Data Securely'; } }); The Problem with Synchronous Form Lifecycles Traditional submissions trigger a synchronous navigation cycle: the browser constructs a payload, issues a full HTTP request, and replaces the

Tres semanas después de publicar un sitemap dinámico que orgullosamente listaba cada perfil de miembro, Google Search Console me dijo que esos perfiles eran un error. No con un error de plano, sino con dos veredictos más callados: Soft 404 y Duplicada sin canónica seleccionada por el usuario . Esta es la historia de leer ese reporte, separar el ruido de la única señal real, y el arreglo, que fue quitar páginas del índice, no agregarlas. TL;DR El reporte "Por qué las páginas no se indexan" de Google es ~80% benigno por diseño. Aprende a triarlo o vas a perseguir fantasmas. Mis perfiles de miembros salieron marcados como Soft 404 (uno) y Duplicada sin canónica seleccionada por el usuario (otro). La misma causa raíz: el perfil público anónimo es deliberadamente flaco, un esqueleto con el username, todo lo demás es PII oculta a quien no ha iniciado sesión. Flaco + casi idéntico entre usuarios se lee como "página vacía" y "clúster de duplicados". No puedes arreglar un Soft 404 enriqueciendo una página que por contrato no tienes permitido enriquecer. Así que el arreglo es noindex,follow en la captura, más sacar las URLs del sitemap (un sitemap que lista una URL noindex es una autocontradicción que Google va a señalar). El modelo mental en una línea: una página que a propósito no tiene contenido para los visitantes anónimos no tiene nada que hacer en un índice construido para visitantes anónimos. El reporte que lo empezó todo El reporte de cobertura del índice, ordenado por número de páginas: Razón Fuente Páginas Descubierta, actualmente sin indexar Sistemas de Google 55 Duplicada sin canónica seleccionada por el usuario Sitio web 9 Página alternativa con etiqueta canónica correcta Sitio web 3 Página con redirección Sitio web 2 Rastreada, actualmente sin indexar Sistemas de Google 2 Soft 404 Sitio web 1 Excluida por etiqueta 'noindex' Sitio web 1 No encontrada (404) Sitio web 1 Bloqueada por acceso prohibido (403) Sitio web 1 Noventa y tantas URLs "sin indexar". El instint

Web Accessibility for Startups: 5 Small Wins That Scale Palak jain Palak jain Palak jain Follow Oct 7 '25 Web Accessibility for Startups: 5 Small Wins That Scale # webaccessibility # webdev # frontend # startup 21 reactions 4 comments 4 min read

My Zero to Blockchain Engineer journey — Week 2 update Last week I announced I was teaching myself blockchain engineering from zero. This week I went deep into Cyfrin Updraft — and I have to be honest, it changed how I think about learning Web3. Here's everything I covered, what surprised me, and why I think this platform is the best free resource for anyone serious about becoming a blockchain developer. What I covered this week I'm currently 45% through the Blockchain Basics course on Cyfrin Updraft. Here's exactly what the lessons covered: Section 1 — What Is A Blockchain? This section answered the question properly — not in a surface-level way, but by starting with the problem blockchain solves. The lesson on centralized control hit differently. Think about it in a Nigerian context — banks freezing accounts, payment processors blocking transactions, elections where results can't be independently verified. These aren't hypothetical problems. They're things we live with. Blockchain's answer: a shared ledger where truth is verified by math, not by a middleman. That framing made everything click for me. Key lessons I completed: What Is A Blockchain — centralized problems vs decentralized solutions History Of Blockchain — from the double-spend problem to Bitcoin to Ethereum Benefits Of Blockchain — permissionless, immutable, credibly neutral Use Cases — DeFi, cross-border payments, DAOs, digital ownership Many Many Chains — L1s, L2s, Mainnets vs Testnets The Oracle Problem — why smart contracts can't access real-world data alone The Purpose Of Smart Contracts — math-based promises vs trust-based agreements What Is The EVM — Ethereum's computation engine explained simply Benefits Of Smart Contracts — decentralization, immutability, transparency Section 2 — Sending Transactions This is where things got hands-on — and where Cyfrin pulled ahead of every other platform I've tried. Key lessons: What Is A Wallet — your public address as a digital mailbox Setting Up A Wallet

You've got a Next.js app on one domain and your API on another. The login works, the dashboard fills up, everything looks fine. Then one day you open the Network tab and there it is: your access token, in plain text, in a request header the browser sent all by itself. At that point every line of JavaScript on the page can read it. Not just your code. The analytics snippet you added last week, the twelve transitive dependencies you've never opened, whatever an XSS bug manages to slip in. And you never really decided this. It just happened, because calling the API straight from the component was the path of least resistance, and nothing complained. The browser is not a trusted client The version that gets you here looks completely reasonable: // ❌ a Client Component talking to your API ' use client ' ; export function Profile () { useEffect (() => { fetch ( ' https://api.example.com/me ' , { headers : { authorization : `Bearer ${ token } ` }, }) . then (( r ) => r . json ()) . then ( setProfile ); }, []); } Look at what that actually signed you up for. The token is in JavaScript, so the protection an HttpOnly cookie would have given you is simply gone. The call is cross-origin, so you're now on the hook for CORS: preflight requests, an allowed-origins list to maintain, Access-Control-Allow-Credentials , and the quiet worry that you've opened it wider than you should. And because the request leaves from the browser, anyone with devtools can read your API's base URL, its routes, and how it expects to be authenticated. That's a decent map of your backend, handed out to every visitor. What makes this hard to catch is that none of it breaks. It works in the demo, it works in production, it reviews clean. It just sits there as a liability until the day it stops being quiet. The browser talks to your server. Your server talks to your API. The Backend-for-Frontend pattern draws one line: the browser only ever talks to your Next.js server. The Next.js server talks to your API.

This report analyzes pricing shifts across 35 developer tools tracked over a seven-week period from 2026-W19 to 2026-W29. We have identified 37 total pricing changes during this window, providing a clear snapshot of how platform tiers are evolving for engineering teams. GitHub Copilot’s Tier Expansion GitHub Copilot has seen significant activity in its subscription structure over the last two months. On May 25, the platform solidified its existing pricing, maintaining the Free tier at $0, Pro at $10/mo, and Pro+ at $39/mo. By June 15, the service introduced a "Max" tier priced at $100/mo. This was followed on July 12 by the addition of two enterprise-focused options: Business at $19/mo and Enterprise at $39/mo. Cursor’s Rapid Plan Iterations Cursor has undergone a series of rapid adjustments to its tiering model since late May. On May 25, the platform introduced a Free Hobby plan and a $20/mo Pro plan while removing the Individual tier. This structure was short-lived; on June 15, the platform removed both the Hobby and Pro tiers, replacing them with a single $20/mo Individual plan. As of the latest tracking, the current price for the Cursor Pro plan is listed at $20/mo. Netlify and Windsurf Pricing Shifts Infrastructure and IDE-integrated tools are also shifting their cost models. On July 12, Netlify moved its Enterprise tier from a "contact sales" model to a defined starting price of $500/month. Windsurf also saw a notable change on June 15 regarding its Teams offering. The price shifted from a flat $40/user/month to a base of $80/mo plus an additional $40/mo per seat. This follows Windsurf's earlier introduction of a Free ($0/month) tier on May 25. Vercel and Firebase Updates Platform-as-a-Service providers have focused on refining their entry-level and usage-based offerings. On May 25, Vercel added a Free Hobby plan and updated its Pro tier to $20/mo (plus additional usage). During that same week, Firebase added a Spark plan ($0) and a usage-based Blaze plan, whi

TypeScript Generic Constraints in Depth: extends , keyof , and the Patterns That Prevent Runtime Errors This article was written with the assistance of AI, under human supervision and review. Most TypeScript runtime errors stem from unconstrained generics that accept anything and crash on nothing. Teams write function get<T>(obj: T, key: string) and ship code that compiles cleanly but throws Cannot read property 'undefined' of undefined in production. The compiler stays silent because the generic accepts any type and the key accepts any string—no constraint exists to prove the key belongs to the object. Generic constraints solve this by restricting what types a generic parameter can accept. The extends keyword establishes a boundary—the generic must satisfy a specific shape. The keyof operator extracts valid keys from that shape. Together they form a type-level contract that makes illegal property access unrepresentable. The corrected signature function get<T, K extends keyof T>(obj: T, key: K): T[K] proves at compile time that key exists on obj , eliminating the entire class of property-access errors. This distinction is critical. Unconstrained generics provide no safety beyond what any offers. Constrained generics encode domain rules directly into the type system, shifting entire categories of bugs left from runtime to compile time. The patterns that follow demonstrate how production codebases use extends and keyof to build type-safe APIs that fail fast during development instead of silently in production. Key Takeaways Generic constraints with extends restrict type parameters to specific shapes, preventing the compiler from accepting types that would cause runtime failures. The keyof operator extracts object keys as a union type, enabling type-safe property access when combined with extends keyof constraints. Combining T extends SomeType with K extends keyof T creates a compile-time proof that a key exists on an object, eliminating property-access errors. Conditi

Most portfolios have a boring "About Me" paragraph. I replaced mine with something you can talk to — an AI terminal that answers questions about me, pulls my live GitHub activity, and remembers the conversation. You can try it right now on my portfolio: rehbarkhan.in . I'm Rehbar Khan , a Full Stack & Gen-AI developer, and in this post I'll break down exactly how it works — the RAG pipeline, the LangGraph agent, the memory layer, and how I wired in real GitHub data with MCP. No fluff, just the architecture. The problem I wanted a portfolio assistant that could: Answer questions about my background accurately — no hallucinated jobs or fake projects. Fetch live data (my latest GitHub activity), not a stale snapshot. Remember the conversation across messages. Stream responses token-by-token like a real terminal. That rules out "just prompt an LLM." You need retrieval for grounding, tools for live data, and state for memory. Here's the stack I landed on. Architecture at a glance Next.js 16 chat UI ──► FastAPI (streaming) ──► LangGraph agent ├── RAG retriever → pgvector (Neon Postgres) ├── GitHub MCP tool → live GitHub data └── Redis checkpointer → conversation memory Frontend: Next.js 16 (App Router, TypeScript) — a streaming terminal UI. Backend: FastAPI with streaming responses. Orchestration: LangGraph ( StateGraph , ToolNode , tools_condition ). LLM: OpenAI gpt-4o-mini . Retrieval: text-embedding-3-small → pgvector on Neon Postgres. Memory: Redis checkpointer for per-session history. Live data: GitHub via the Model Context Protocol (MCP) . 1. The RAG pipeline Everything the bot knows about me lives in a single reference.txt . I chunk it, embed it, and store it in Postgres with pgvector: from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_postgres import PGVector splitter = RecursiveCharacterTextSplitter ( chunk_size = 500 , chunk_overlap = 80 ) chunks = splitter . split_text ( open ( " refe

Originally published at htpbe.tech . The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text. A fraud reviewer opens a PDF bank statement. The first thing many manual checks look at is the document’s Producer field — the line of metadata that records which software last wrote the file. This one says Adobe PDF Library 23.1 . To a human, and to most lightweight metadata checks, that reads as reassuring: Adobe is professional software, the kind a bank’s back office or a law firm would use. The reviewer moves on. That is exactly the reaction the forger was counting on. The document was not produced by Adobe. It was edited in a free browser-based PDF editor, then passed through a step that overwrote the Producer string to say Adobe . The metadata now lies about the file’s own origin — and it lies in the most credibility-laundering direction available, because “Adobe” is the producer string people trust most. This is producer identity forgery, and it is one of the most common ways a tampered PDF tries to talk its way past a metadata-only review. This is a case study in how that attack works at a conceptual level, why a metadata-only check waves it through, and how a structural approach — the one behind the public marker HTPBE_PRODUCER_IDENTITY_FORGED — catches the contradiction the forger left behind. If you want to see the Producer string for yourself, the free PDF metadata viewer reads it — along with every other field — straight out of any PDF. Why the Producer field is the obvious thing to forge Every PDF carries internal records about how it was made. Two fields matter most to a reviewer: producer — the software that wrote the final bytes of the file. creator — the application the content originated in. Fraud-detection lore, repeated in countless “how to spot a fake bank statement” guides, says the same thing: a real institutional document is generated by an automated back-end system, so if the producer says Mi

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . There is a version of this story where I walk you through the technical challenges in a clean, detached voice. Structured. Professional. Composed. This is not that version. Seven months. A hundred pages of documentation written alongside the code, not after it. A live system serving rural clinics in Delta State, Nigeria. And three bugs so specific and so cruel that each one felt designed to find the exact gap between what I thought I knew and what I actually knew. The Delta Health Information and Appointment Booking System was my final year project at the University of Port Harcourt. That sentence makes it sound smaller than it was. This was a real system for real clinics, serving patients who travel for hours to reach a healthcare facility only to find the clinic is full, the doctor is not in, or nobody told them their appointment was cancelled. These are not hypothetical users. These are people whose access to healthcare depends on whether the software works. That is a different kind of pressure than getting a good grade. And it did not start at deployment. Before a single line of code was written, I had to pitch the entire concept to my university supervisor, the Head of Department, the Faculty Dean, and an external examiner. The system had to be defensible not just technically but practically. It had to demonstrate that it solved a real problem that real people in Delta State were actually facing. I was presenting to people with decades of experience who would ask questions I had not thought of yet. That kind of scrutiny either sharpens you or breaks you. I chose to let it sharpen me. The stack was React.js, Node.js, PHP with Laravel, MySQL, AWS, and Docker. Communication channels included SMS gateways, WhatsApp Business API, and USSD because not every patient in rural Delta State has a smartphone. The system had to run on 2G connections, on entry-level Android phones with 2GB RAM

Over the past few months I’ve been building Radar, an open-source media intelligence and social listening platform that anyone can self-host. The project started with a simple observation: most media monitoring platforms are incredibly powerful—but they’re also expensive, closed, and often lock users into proprietary AI services. I wanted to explore a different approach. What is Radar? Radar is a self-hostable platform for monitoring news and public media sources using AI. Instead of relying on proprietary datasets, it works with free public RSS and Atom feeds, allowing anyone to build their own monitoring environment. One of the core design decisions is that Radar is AI-agnostic. Rather than forcing a single provider, you can choose between: Anthropic Claude OpenAI Grok Current Features 📰 News aggregation from free RSS and Atom feeds 🤖 AI-powered summaries 😊 Sentiment analysis 🔍 Keyword and topic monitoring 📊 Searchable dashboard 🏠 Self-hosted deployment 🔓 Fully open source Why Build Another Media Intelligence Tool? Enterprise platforms such as Talkwalker and Brandwatch are excellent products, but they aren’t accessible to everyone. Radar is aimed at: developers startups journalists researchers agencies open-source enthusiasts The goal isn’t to replicate every enterprise feature, but to build a transparent, extensible, and self-hosted alternative that anyone can inspect, modify, and improve. Looking for Feedback The project is still under active development, and I’d really appreciate feedback on: architecture user experience deployment scalability AI abstraction features that would make the platform more useful If you’re interested in open-source AI, media monitoring, or self-hosted software, I’d love to hear your thoughts. GitHub Demo Contributions, suggestions, feature requests, and bug reports are all welcome.

AI coding agents have dramatically shortened the distance between an idea and working software. They can inspect a project, create files, run commands, write tests, and help diagnose failures. What they have not eliminated is judgment. A polished screen is not proof that data survives a reload. A passing unit test is not proof that keyboard users can complete the core task. A successful deployment is not proof that the intended commit reached production. This is why I use proof gates : observable conditions that must be satisfied before a product claim becomes stronger. A proof gate is not a meeting, a long document, or an excuse to slow down. It is a compact question: What evidence would let another person verify that this claim is true? Here are five gates that separate a persuasive AI demo from a small MVP you can responsibly ship. Gate 1: Prove One Valuable User Loop AI makes feature generation cheap, which makes uncontrolled scope especially dangerous. Before requesting code, define one primary user in one specific situation. Then describe: Their observable before-state The smallest useful action they can take The immediate result The reason they might return This becomes the product’s core loop. For example, “build a productivity platform” is too broad. A more testable loop might be: A freelancer remembers a useful client outcome. They record the outcome and supporting evidence. The record appears in a searchable library. They can retrieve it later for a proposal or review. The gate is not passed because a form exists. It is passed when a new user can complete the entire loop and explain what changed without coaching. Write a Not Today list alongside the required capabilities. Authentication, dashboards, collaboration, billing, and AI-generated summaries may all be reasonable later. They should not compete with proof of the first useful loop. The goal is not the fewest possible features. It is the smallest complete behavior that tests whether the product creat