DEV Community: AI Predictions Dev

Building a Private, On-Device AI Dungeon Master in the Browser

AI Predictions Dev — Mon, 20 Jul 2026 13:00:02 +0000

I’ve been spending the last few months wrestling with a specific constraint: how do you bring the generative power of large language models into a real-time game loop without turning the experience into a slideshow of API calls?

The industry standard answer right now is "cloud inference." You send a prompt, wait for the stream, render the text, and hope the latency doesn’t break immersion. For a text-based adventure, that’s tolerable. For a dungeon crawl where you’re clicking every two seconds, it’s a friction point that kills the flow.

So I built Grimhollow. It’s an infinite dark-fantasy dungeon crawler, but the hook isn’t the art or the combat mechanics. The hook is that the entire narrative engine runs locally on your machine using WebGPU. There is no server-side AI processing. Your prompts never leave your browser. And because it’s on-device, it works entirely offline once the model is cached.

The Wedge: Latency vs. Privacy

Most indie devs looking to integrate AI are forced to choose between speed and privacy. If you want speed, you use a small, quantized model hosted on a fast edge server, but you’re trusting that server with your context window. If you want privacy, you run a model locally, but you’re often stuck waiting 3-5 seconds for a response on a mid-tier laptop.

I wanted to prove that with WebGPU acceleration, we can get the best of both. By offloading the matrix multiplications to the GPU, we can achieve token generation speeds that feel native to the UI, not like a chat interface bolted onto a game.

Under the Hood

The architecture is surprisingly simple, which is part of the appeal for anyone looking to replicate this pattern.

The Runtime: The game is a standard web app, but it leverages the WebGPU API to load a quantized language model directly into the browser’s memory.
The Context Window: Unlike a chat app where history grows indefinitely, a dungeon crawl has a natural "scene" boundary. When you enter a new room or encounter a new enemy, the context resets. This keeps the memory footprint low and the inference speed high.
The Prompt Structure: The AI doesn’t just generate prose; it generates structured JSON alongside the narrative. This allows the game engine to parse HP changes, inventory updates, and state flags without post-processing the text.

Here is a simplified look at how the inference call is structured in the code. Note that we never specify a model name in the user-facing code because the model is bundled as a binary blob loaded by the WebGPU runtime:

// The inference loop runs on the main thread but delegates to GPU
async function generateNextStep(currentState) {
  const prompt = buildPrompt(currentState);

  // 'localModel' is the compiled WebGPU graph
  const response = await localModel.generate(prompt, {
    maxTokens: 64,
    temperature: 0.7
  });

  return parseResponse(response);
}

The "Infinite" Problem

The biggest challenge wasn’t technical; it was design. When you have an AI GM, the world is theoretically infinite. But infinite choices lead to player paralysis. To solve this, Grimhollow uses a "constrained randomness" approach. The AI is given strict genre tags (dark fantasy, gothic horror) and a limited vocabulary of items and enemies. This ensures that while every dungeon is unique, the feel remains consistent. You don’t get a sci-fi spaceship in a medieval crypt because the system prompt explicitly forbids it.

Performance Realities

I want to be honest about the hardware requirements. This isn’t magic. It’s heavy lifting.

On a modern MacBook Pro or a Windows laptop with a dedicated GPU, the experience is seamless. The model loads in a few seconds, and narration appears almost instantly as you explore. On older hardware or integrated graphics, there is a noticeable delay—about 1-2 seconds per turn. It’s not "real-time" in the sense of an action game, but it’s fast enough for a tactical dungeon crawler.

Also, because the model is running locally, the initial download is substantial. We’re talking about a 2-4GB download for the model weights depending on the quantization level. This is a trade-off for the privacy and offline capability. If you’re on a metered connection, you’ll feel that upfront cost.

Trying It Out

If you want to see what this feels like in practice, you can check out the game here: Grimhollow.

It’s a paid tool, but there is a 7-day trial period. For those who prefer to test before committing, the games included in the trial offer free turns so you can experience the local AI generation without a credit card.

Why This Matters for Devs

I’m sharing this because I think we’re at an inflection point for browser-based AI. We’ve spent the last two years treating the browser as a thin client for cloud APIs. WebGPU changes that equation. It allows us to treat

I built a product-rankings site that writes itself on a local LLM — the stack

AI Predictions Dev — Fri, 17 Jul 2026 13:00:01 +0000

Most "best X tools" sites are a content treadmill: someone has to keep researching, writing and refreshing dozens of roundups. I wanted to see how much of that could run itself, on hardware I already own, with zero cloud-AI cost. The result is live at topratingshub.com — independent, data-driven rankings of software, apps, AI tools, devices and finance products. Here's the architecture and the lessons.

The stack

Astro (SSG) — every page is static HTML, 0 KB of JS shipped. Fast, cheap to host, great Core Web Vitals.
A local LLM as the writer, served with vLLM on an ARM64 box. The pipeline is ground → extract facts → write → quality-gate → revise. The quality gate is another local model call that scores the draft; anything under threshold gets one revision pass or is dropped.
Real grounding: before writing, it fetches and extracts current pricing/specs from primary sources and feeds the top sources (big context budget) to the writer, so the output has actual numbers instead of vibes.
systemd timers, not a babysitter: one nightly content run, a monthly topic-discovery job, health checks every 15 minutes, daily backups, a weekly digest.
IndexNow + JSON-LD (Article, ItemList, Breadcrumb, FAQ) so search engines pick up changes fast.

Topic discovery for free

Instead of guessing what to write, a monthly job pulls Google Autocomplete suggestions for seed terms per category. Those are real, popularity-ordered queries ("best crm for small business", "notion vs airtable"), so the content targets things people actually search — no paid keyword tool required.

The lesson that mattered most: never let a transient outage mutate durable state

The shared LLM crashed under load a few times. The first version of the nightly job kept running anyway and marked ~200 topics as permanently error (they hit the retry cap while the model was down). A transient infra blip had quietly burned real work.

The fix was two lines of principle:

Gate on the dependency. The nightly job now checks the model's health first; if it's down, it skips the whole run and burns nothing.
Self-heal + alert. A watcher restarts the model container after sustained downtime and pings me, instead of failing silently for days.

# nightly content job, simplified
if ! curl -sf http://localhost:8000/v1/models >/dev/null; then
  echo "writer down — skipping run, no topics burned"; exit 0
fi
run_batch && build && indexnow_ping

If you're building anything autonomous: monitor your linchpin dependency, not just your own web endpoints, and make outages harmless rather than destructive.

Takeaways

You can run a genuinely useful, self-updating content site on local hardware for the cost of electricity + a domain.
Grounding + a quality gate is the difference between "AI slop" and something worth reading.
The hard part isn't generation — it's the operational safety net around it.

The live result is topratingshub.com. If you run a product in one of those categories and want a clearly-labeled placement, that's on the advertise page — the editorial ranking itself is never for sale, which is the whole point of it being trustworthy.

Happy to answer stack questions in the comments.

Building an Offline AI Note-Taking App with WebGPU

AI Predictions Dev — Mon, 13 Jul 2026 13:00:01 +0000

For the last few months, I’ve been obsessed with a specific problem: the friction between privacy and utility in modern AI tools. Most "private" AI solutions still rely on a local LLM running on your CPU or GPU via a heavy desktop application. They require installation, constant background processes, and often struggle with performance on older hardware.

I wanted to see if we could do better. I wanted to see if we could run a capable language model entirely within the browser, using only the device’s hardware acceleration, with zero data leaving the machine.

The result is PrivateScribe, a tool I built to handle note summarization, email drafting, and rewriting. But more importantly, it’s an experiment in what’s possible when you treat the browser not just as a display layer, but as a compute engine.

The Wedge: WebGPU and True Offline

The core constraint that drove this project was simple: nothing leaves the device.

In the current landscape, "on-device AI" often means "installed on your device." This is fine for desktop apps, but it creates silos. You can’t easily share a workflow across a Chromebook, a Windows machine, and an iPad without installing three different native applications.

By leveraging WebGPU, PrivateScribe runs entirely in the browser. This unlocks a few critical advantages:

Zero Installation: Users open a URL and start working. No downloads, no permission dialogs for file system access beyond what’s needed for the session.
Hardware Acceleration: WebGPU allows the browser to tap directly into the GPU. This is crucial for inference speed. A small model that runs in your browser can process text significantly faster than a CPU-bound implementation, especially on modern laptops with integrated graphics.
True Offline Capability: Because the model weights are loaded locally via WebAssembly and the inference happens on-device, the app works completely offline. If you lose your internet connection in the middle of drafting an email, the AI doesn’t stop. It continues to function because it isn’t waiting for an API response from a cloud server.

The Developer Experience

Building this presented several unique challenges. The most significant was managing memory. Browsers have strict memory limits, and loading a quantized model into the GPU memory requires careful handling. I had to ensure that the model could be loaded, used for inference, and then released without causing the tab to crash or the browser to become unresponsive.

Another challenge was latency. Even with WebGPU, inference isn’t instant. I implemented a streaming token output system that mimics the "typing" effect of cloud-based AI. This doesn’t just make the experience feel smoother; it also provides immediate feedback to the user, reducing the perceived wait time.

The codebase is relatively lean. It relies on a standard JavaScript/TypeScript stack for the frontend, with a custom inference engine that interfaces with the WebGPU API. There’s no backend server involved in the AI processing. The only server interaction is for authentication and saving your notes to your own storage if you choose to sync them.

Privacy by Design

Privacy isn’t a feature here; it’s the architecture. Since the AI processing happens locally, there is no data to leak. The model never sees your raw text in a way that can be logged or used for training. This is a significant shift for users who are wary of sending their personal notes and draft emails to third-party cloud providers.

This approach also means that the intelligence is tailored to the immediate context. The model doesn’t have access to a vast database of your previous interactions unless you explicitly provide them in the current session. This forces a cleaner, more focused interaction model.

Practical Usage

PrivateScribe is designed for two main workflows:

Note Summarization: Paste a long article, meeting transcript, or document. The AI generates a concise summary, extracting key points and action items.
Email Drafting and Rewriting: Draft a quick, rough email and ask the AI to refine the tone, fix grammar, or make it more concise. Alternatively, paste an incoming email and get a suggested reply.

The interface is minimal. There are no complex settings to tweak. You paste text, select a function, and get results. The goal is to reduce cognitive load, not add to it.

Pricing and Access

PrivateScribe is a paid tool, designed to be sustainable for long-term development. There is a 7-day trial that allows you to test the full functionality without commitment. For users who prefer to try before they buy, there are also free turns available in the associated AI games, which serve as a sandbox for the same underlying technology.

Why This Matters

The trend of moving AI to the edge is well-documented, but most implementations require native apps. By proving that a usable, fast, and private AI experience can be delivered via WebGPU in a browser, we open the door for more lightweight, cross-platform AI tools.

This isn’t just about avoiding cloud costs. It’s about control. It’s about having a tool that works when the internet is down, respects your data by design, and doesn’t require you to change your browser habits to use it.

If you’re curious about the technical implementation or

Scheduling Across Time Zones Without Leaving the Browser

AI Predictions Dev — Fri, 10 Jul 2026 13:00:00 +0000

I spent the last few weeks building a tool I actually use myself. It started as a frustration with existing scheduling apps. They all feel heavy. They require accounts, they require integrations, and most importantly, they require your data to leave your device to be processed on a server. For a developer who cares about privacy and latency, that friction is unacceptable.

So I built TimeForge.

It’s a scheduling utility that helps you find the best meeting times across every timezone, but with a twist: it runs entirely in your browser using WebGPU. Nothing is uploaded. There is no backend server processing your calendar data. If you disconnect your internet after the page loads, the tool still works.

The Problem with Current Tools

When I need to schedule a meeting with a colleague in Tokyo and another in San Francisco, I usually end up with three tabs open: my calendar, a world clock widget, and a mental map of working hours. I have to manually calculate the overlap. It’s tedious.

Most online schedulers solve this by asking you to sign up and sync your Google or Outlook calendar. That’s fine for teams, but it’s overkill for a quick "when are you free?" check. Plus, you’re handing over your schedule data to a third party. I wanted a tool that respects the boundary between my local machine and the cloud.

How It Works

TimeForge is a single-page application. When you open it, you input your time zone and your working hours. You then add the time zones of the people you want to meet with. The interface renders a visual overlay of these time zones, highlighting the windows where everyone is technically "awake" or "working."

The magic happens in the rendering engine. Because it uses WebGPU, the heavy lifting of calculating and rendering these complex time overlays happens on your GPU. This means the UI remains buttery smooth even if you add a dozen time zones. There is no lag because there is no network request waiting for a server to respond.

Privacy by Design

The core philosophy here is data locality. Your time zone preferences and working hours never leave your browser. If you use the tool offline, you can still plan your week. If you use it online, you can share a link, but that link contains only the configuration parameters, not your personal calendar events unless you explicitly choose to export them.

This approach also makes the tool incredibly fast. There is no loading spinner while it "syncs." It just updates.

The Technical Stack

I built this with a focus on minimalism. The frontend is vanilla JavaScript with WebGPU for the rendering pipeline. This was a deliberate choice to avoid the bloat of heavy frameworks for a utility that doesn’t need complex state management. The UI is clean and functional, designed to be used in seconds, not minutes.

One of the challenges was handling daylight saving time transitions across different regions without a server-side library. I implemented a lightweight local algorithm that handles these edge cases, ensuring that the "working hour" overlays are accurate year-round.

Why It’s Paid

TimeForge is a paid tool, though it offers a 7-day trial so you can see if it fits your workflow. I chose a paid model because it allows me to keep the infrastructure lean and focused on quality rather than scaling for millions of free users. There are no ads, and no data mining. The cost supports ongoing development and maintenance of the tool.

Who Is This For?

If you are a developer, designer, or remote worker who frequently coordinates with people in different time zones, this tool might save you a few minutes per week. It’s not a calendar replacement. It’s a tactical utility for finding that elusive overlap when you’re planning a quick sync.

It’s particularly useful for:

Remote teams with members in disparate time zones.
Freelancers coordinating with clients across the globe.
Anyone who values privacy and wants to avoid signing up for another SaaS platform.

Try It Out

You can see it in action at TimeForge.

I’m still iterating on the UI and adding small features based on how people actually use it. If you have thoughts on the design or the functionality, I’d appreciate hearing them. I’m always looking for ways to make remote coordination less painful.

Stop Guessing: A Local-First Approach to Decoding Cron Expressions

AI Predictions Dev — Tue, 07 Jul 2026 13:00:01 +0000

If you have spent more than a few years in DevOps or backend development, you have likely had that specific moment of panic at 3 AM. You are staring at a misfired job, a log file that looks like noise, and a cron expression that refuses to make sense. 0 */2 1-15 * 1-5. Does that mean every two hours? Every day at midnight? Only on weekdays?

We all know the syntax. We have all memorized the five (or six) fields. But memory is fallible, and context switching is expensive. When a production incident hits, you do not want to open a new tab, search for a cheat sheet, or spin up a Docker container just to test a schedule. You want the answer now, without leaving your current context.

I built CronExplain to solve this specific friction. It is a utility designed for developers who need to understand scheduling logic instantly, without the overhead of cloud dependencies or data privacy concerns.

The Problem with Current Tools

Most online cron calculators are simple form-fillers. You type the expression, hit "parse," and get a list of dates. While functional, they often lack two critical things: privacy and persistence.

When you paste a cron expression into a third-party web tool, that data leaves your machine. For many teams, this is a non-issue. For others, especially those dealing with internal infrastructure or proprietary pipelines, sending configuration details to an external server is a hurdle. Furthermore, these tools rarely explain the logic behind the schedule. They give you a list of dates, but they do not tell you, in plain English, what the rule actually is. This forces you to mentally reverse-engineer the output, which is exactly the cognitive load we are trying to reduce.

The Solution: 100% Local, 100% Offline

CronExplain is different because it runs entirely in your browser. There is no backend server processing your requests. When you type an expression, the parsing happens locally using a private on-device AI engine. This means your data never leaves your computer. You can disconnect your internet, open the app, and it still works.

This architecture was a deliberate choice. By leveraging modern browser capabilities, specifically WebGPU for accelerated processing, we can run a small model that runs in your browser to interpret complex cron syntax. This allows for natural language explanations that feel conversational rather than robotic. Instead of just seeing "Every 2 hours," you might see, "This job runs every two hours, starting at midnight, but only between the 1st and 15th of the month, and only on weekdays."

The visualization component complements this. Seeing a calendar heatmap of when a job is scheduled to run helps catch edge cases that textual descriptions might miss. For example, you might realize that a monthly job actually skips February in a leap year, or that a weekly job overlaps with a holiday maintenance window. Visualizing the schedule makes these anomalies obvious.

Why On-Device AI Matters

The decision to use a private on-device AI was not just about privacy. It was about latency and control. Traditional cloud-based AI APIs introduce network latency. If you are iterating on a cron expression, tweaking the minute field to see how it affects the schedule, that round-trip time adds up. Local inference is instantaneous.

Moreover, because the model runs in your browser, it is lightweight. It does not require a heavy installation or a dedicated server. It is a utility that lives in your tab, ready whenever you need it. The small model that runs in your browser is optimized for this specific task: parsing cron syntax and generating clear, concise explanations. It does not need the full power of a large language model; it needs precision and speed.

A Note on Pricing

CronExplain is a paid tool, as it requires ongoing maintenance and development. However, I believe in letting the utility speak for itself. There is a 7-day trial available so you can integrate it into your workflow without commitment. If you find it saves you time during debugging or onboarding new developers, it is a small investment. For those who prefer to test the waters, the core parsing features are accessible during the trial period.

Building for Developers, by Developers

The interface is intentionally minimal. No clutter, no ads, no distractions. Just an input field, a plain-English explanation, and a visual calendar. It respects your time.

I built this because I was tired of guessing. I wanted a tool that felt like a natural extension of my development environment, not a separate service I had to authenticate with. By keeping everything local, I ensure that my configuration data stays mine. By using on-device AI, I get the benefit of intelligent explanation without the compromise of privacy.

If you find yourself frequently second-guessing cron syntax, or if you are onboarding a team member who is new to scheduling logic, this tool might save you a few minutes of confusion. It is a small piece of software, but it addresses a real pain point in the developer experience.

You can try it out at [https://cronexplain.bestpaid.app](https://

Stop Copy-Pasting Regex from Stack Overflow

AI Predictions Dev — Fri, 03 Jul 2026 13:00:02 +0000

We’ve all been there. You need to validate an email address, or extract a specific pattern from a log file, or sanitize user input in a security-sensitive backend. You know you need a regular expression. You open your favorite regex playground, type in ^\w+, realize it’s not quite right, tweak it, test it, break it, tweak it again, and eventually copy-paste it into your codebase.

The problem isn’t just that writing regex is hard. It’s that reading and explaining regex is even harder. A week later, when a bug surfaces because the regex didn’t handle a hyphenated name, you stare at that string of symbols and wonder what you were thinking.

I built RegexBuilder to solve the "what was I thinking?" problem, but with a specific constraint: I wanted it to work entirely in your browser, with zero data leaving your machine.

The Wedge: Privacy-First, Real-Time Explanation

Most regex tools are simple validators. You type a pattern, you type a test string, and you get a green check or a red X. Some fancier ones highlight matches. But they don’t help you understand why a pattern works or fails, and they certainly don’t help you write the pattern in the first place.

RegexBuilder flips this. Instead of starting with the regex, you start with the problem. You describe what you’re trying to do in plain English: “Extract all hex color codes from a CSS file” or “Validate a strong password with at least one uppercase, one number, and one special character.”

The tool then generates the regex for you. But the real value isn’t the generation—it’s the explanation. It breaks down the generated pattern part-by-part, explaining what each group does in plain language. If you tweak the description, the regex updates in real-time. If you tweak the regex, the explanation updates to reflect your changes.

This back-and-forth is crucial. It turns regex from a black-box syntax puzzle into a transparent logic structure. For backend and security teams, this is huge. You can audit the logic without being a regex expert, and you can document the intent directly alongside the pattern.

Why 100% On-Device?

The biggest constraint I imposed on myself was: no server-side AI.

When you type a sensitive regex pattern—especially one that might contain proprietary data formats, internal identifiers, or security rules—you shouldn’t have to send that data to a cloud API to get help. There’s latency, there’s trust, and there’s the simple friction of knowing your code is leaving your environment.

RegexBuilder runs entirely in your browser using WebGPU-accelerated inference. There’s a small model running locally that processes your natural language descriptions and generates the regex logic. Because it’s on-device, it works offline. It works instantly, without network lag. And it works privately.

I’ve found that this approach changes how developers interact with the tool. You don’t hesitate to type out complex, specific requirements because you know nothing is being logged or stored elsewhere. You can experiment freely.

The Developer Experience

I’ve used many regex tools over the years. The best ones are fast and accurate. The worst ones are slow and opaque. RegexBuilder aims to be fast, accurate, and transparent.

Here’s how a typical workflow looks:

Describe: You type, “Match IPv4 addresses but exclude private ranges.”
Generate: The tool produces a regex. It highlights the parts that handle the octets and the parts that exclude the private ranges.
Refine: You notice it’s too broad. You add, “...and only match if it’s at the start of a line.” The regex updates instantly.
Explain: You click on the generated pattern, and it breaks down each component: “^ asserts start of line,” “(?: starts a non-capturing group,” etc.
Copy: You copy the final regex and the explanation into your code comments.

This isn’t just about convenience. It’s about reducing cognitive load. When you’re debugging a security vulnerability related to input validation, you don’t want to spend 20 minutes deciphering a regex you wrote three months ago. You want to understand the intent immediately.

Honest Take on Pricing

RegexBuilder is a paid tool. I believe in building sustainable, high-quality developer tools, and this model allows me to focus on performance and privacy without ads or data harvesting. There’s a 7-day free trial so you can test it on your actual projects. If you’re exploring the interactive learning features or games, those have free turns available.

If you’re curious, you can try it here: https://regexbuilder.bestpaid.app

Why This Matters Now

As applications become more complex, the need for robust input validation and data extraction grows. Regular expressions remain one of the most powerful tools in our toolkit, but they’re also one of the most misunderstood. By lowering the barrier to entry and increasing transparency, we can make regex safer and more maintainable.

I’m still refining the

Why I Built a JSON Toolkit That Never Touches a Server

AI Predictions Dev — Mon, 29 Jun 2026 13:00:01 +0000

Most of the time, when I need to inspect a complex JSON payload, I copy the raw string from my terminal or network tab, open a browser tab, and paste it into one of the many "JSON Formatter" sites that clutter the first page of Google. It’s a ritual we all do. We paste, we click "Format," and we wait.

For small payloads, this is fine. But when you are debugging a massive API response, a deeply nested configuration file, or a large dataset, that ritual breaks down. The browser freezes. The site asks you to upload a file. Worse, many of these tools send your data to a server for processing. If that JSON contains API keys, user PII, or internal schema definitions, you are essentially trusting a third-party service with your proprietary data every time you hit "pretty print."

I got tired of the latency and the privacy overhead. So I built JSONForge.

The core premise is simple: do everything locally. No server-side processing. No file uploads. No network requests for the core logic. Everything happens in your browser, powered by WebGPU for heavy lifting and a small model that runs in your browser for schema inference.

The WebGPU Advantage

JSON parsing is computationally cheap for a modern CPU, but rendering and diffing large structures is not. When you have a 5MB JSON file, the DOM manipulation required to display it as a tree view can cause significant jank.

By offloading the parsing and formatting logic to the GPU via WebGPU, JSONForge handles massive payloads without blocking the main thread. You can open a file, click "Pretty Print," and see the result instantly, even if the file is hundreds of kilobytes or larger. The UI remains responsive because the heavy computation is parallelized on the graphics card.

This also means the tool works offline. If you are on a plane, or your internet drops in the middle of a debugging session, your toolkit doesn’t vanish. You can continue to diff, validate, and format without interruption.

Schema Generation Without the Server Round-Trip

One of the most tedious parts of API development is keeping your JSON Schema in sync with your actual data. Traditionally, you might use a command-line tool or an online service to generate a schema from a sample JSON object.

JSONForge includes a schema generator that analyzes your JSON structure and infers the types, required fields, and constraints. Because this runs entirely in the browser, you can take a raw response from your staging API, paste it in, and immediately get a draft schema. You can then copy that schema directly into your OpenAPI spec or TypeScript definition files.

The inference engine uses a small model that runs in your browser to understand complex type patterns, but it does so without sending your data to a cloud API. This keeps the inference fast and your data private.

Diffing and Validation

Beyond formatting, the tool includes a visual diff engine. If you have two versions of a configuration file, you can paste both side-by-side and see exactly what changed. The diffing algorithm highlights added, removed, and modified keys, making it easy to spot unintended changes in your deployments.

Validation is another key feature. You can paste a JSON Schema and a JSON instance, and the tool will validate the instance against the schema in real-time. Errors are highlighted directly in the tree view, showing you exactly which path in the JSON failed validation and why. This is particularly useful when you are working with strict schemas that require specific types or formats.

A Honest Note on Pricing

JSONForge is a paid tool. I built it to be sustainable and to continue improving the performance and feature set. There is a 7-day free trial so you can test it with your own workflows. If you are looking for a quick, one-off format, the free tier might be enough, but for heavy daily use, the paid plan unlocks the full suite of features, including unlimited schema generation and advanced diffing.

Why This Matters

The web is becoming more capable. We have WebGPU, Web Workers, and efficient JavaScript engines. Yet, many developer tools still rely on the old pattern of "send data to server, process, return result." This pattern introduces latency, privacy concerns, and dependency on network availability.

JSONForge is an experiment in what we can do when we embrace these capabilities. It is not just a prettier printer; it is a local-first toolkit that respects your data and your time. If you spend a significant amount of your day working with JSON, I hope you find it useful.

You can try it out at https://jsonforge.bestpaid.app.

Why I Built an SEO Auditor That Doesn’t Upload Your HTML

AI Predictions Dev — Thu, 25 Jun 2026 13:00:01 +0000

Most SEO tools follow the same pattern: you paste your URL, they crawl it, they send the data to a cloud server, an AI model processes it, and then they send you a report. It works, but it introduces latency, privacy concerns, and a hard dependency on network connectivity.

I built MetaForge to solve a specific friction point: the desire to audit and rewrite meta tags, Open Graph (OG) images, and Twitter cards instantly, without leaving the browser or uploading sensitive HTML to a third-party API.

The Wedge: Local-First AI for Web Developers

The core insight behind MetaForge is that modern browsers are powerful enough to handle natural language processing tasks locally. By leveraging WebGPU, we can run a small model that runs in your browser entirely on-device. This means your HTML never leaves your machine. If you disconnect your internet, the tool still works.

For developers and content creators, this isn’t just about speed; it’s about trust. When you’re tweaking the <head> section of a critical landing page, you don’t want to copy-paste sensitive content into a SaaS dashboard just to get a readability score or a meta description suggestion. You want the feedback loop to be instantaneous and private.

How It Works

MetaForge operates as a local-first application. When you paste your HTML or load a local file, the following happens entirely within your browser:

Parsing: The DOM is parsed to extract all existing meta tags, OG properties, and Twitter card data.
Analysis: A private on-device AI analyzes the content for length, keyword density, clarity, and emotional resonance.
Rewriting: The model generates optimized versions of these tags, adhering to character limits and best practices for click-through rates.

Because the model runs locally, there is no API latency. The feedback is immediate. You can tweak the source text, and the meta tags update in real-time. This allows for an iterative workflow that feels more like editing code than filling out a form.

The Developer Experience

I designed MetaForge with developers in mind. The interface is minimal, focusing on the code output. You can export the generated tags directly as HTML snippets, making it easy to copy-paste into your component library or static site generator.

The tool handles common pain points:

Length Constraints: It automatically truncates or expands meta descriptions to fit Twitter and LinkedIn preview limits.
OG Image Suggestions: It analyzes your content to suggest descriptive alt text and titles for social sharing.
SEO Hygiene: It flags duplicate tags, missing canonical links, and malformed JSON-LD structures.

Privacy and Offline Capability

The decision to run everything on-device was intentional. Many developers hesitate to use AI tools for content generation due to data privacy policies. With MetaForge, your content never leaves your local environment. There is no telemetry, no tracking, and no data retention. This makes it suitable for auditing internal tools, draft pages, or sensitive client projects where confidentiality is paramount.

Furthermore, because it relies on WebGPU, it works offline. You can draft your SEO strategy on a plane or in a café without worrying about connection stability. The only requirement is a browser that supports WebGPU (currently Chrome, Edge, and Safari Technology Preview).

Honest Note on Pricing

MetaForge is a paid tool designed to be lightweight and efficient. It offers a 7-day trial so you can test the local inference capabilities on your own projects. If you find the tool useful for your workflow, the subscription supports the ongoing maintenance and model updates. Note that if you use the companion games or interactive features, they have free turns to allow for casual exploration without immediate commitment.

You can try it here: https://metaforge.bestpaid.app

Why Local AI Matters for SEO

SEO is often a slow, iterative process. Tools that require server-side processing add friction to this loop. By moving the intelligence to the edge (your browser), we reduce that friction. MetaForge isn’t trying to replace your entire SEO stack. It’s a specialized utility for the final mile: ensuring that the technical metadata driving your click-through rates is optimized, accurate, and generated from your actual content.

If you value privacy, speed, and a developer-centric interface, this approach to SEO auditing might fit into your workflow. It’s a small tool for a specific problem, built for those who prefer to keep their data local and their workflows fast.

Generating WCAG-Compliant Palettes Locally: A WebGPU Experiment

AI Predictions Dev — Mon, 22 Jun 2026 13:00:01 +0000

Color is deceptively difficult. We often treat it as an aesthetic choice, but in practice, it is a rigorous compliance constraint. If your interface fails WCAG 2.1 AA contrast ratios, you aren't just making a design mistake; you are excluding users. The typical workflow for solving this involves opening a separate tool, manually adjusting hues, checking contrast ratios, and then copying values back into your codebase. It is a context-switching tax that accumulates quickly.

I built ColorWell to remove the friction between selecting a base color and generating a fully compliant, accessible palette. The core philosophy was simple: the heavy lifting should happen where the data lives—in the browser.

The Wedge: Privacy and Performance via WebGPU

The defining constraint of this project was that no data should leave the user's device. Most palette generators require uploading your design files or sending hex codes to a server for processing. For sensitive projects, this is a non-starter. Furthermore, round-trip latency kills the "flow" state of design work.

ColorWell runs 100% in the browser using WebGPU. This allows the application to leverage the GPU for parallel processing of color space calculations without the overhead of WebGL. The result is a tool that works offline, respects privacy by default, and generates palettes instantly.

When you input a base color, the system doesn't just pick random harmonies. It calculates a range of complementary, analogous, and triadic schemes, then filters them through a strict WCAG 2.1 AA compliance layer. Every generated color is validated against both light and dark backgrounds to ensure legibility. If a color fails, it is adjusted or flagged, ensuring the final palette is not just beautiful, but usable.

Exporting to the Developer Workflow

A palette is useless if it stays in a UI. The second half of the tool focuses on integration. ColorWell exports directly to CSS custom properties, Tailwind configuration objects, and Figma tokens. This means you can copy a block of code and paste it directly into your globals.css or tailwind.config.js file.

The export format is clean and ready for production. For example, a Tailwind export includes not just the color values, but also the semantic naming structure that helps maintain consistency across a project.

:root {
  --color-primary: #3b82f6;
  --color-primary-hover: #2563eb;
  --color-text-dark: #111827;
  --color-bg-light: #f9fafb;
}

This reduces the manual error rate when translating design decisions into code. You don't have to worry about whether the hover state has sufficient contrast because the tool has already verified it.

The Role of On-Device AI

While the core generation logic is algorithmic, I integrated a small model that runs in your browser to assist with semantic labeling. This private on-device AI analyzes the base color and suggests contextual names (e.g., "Ocean Blue" vs. "Steel Gray") based on color theory and common usage patterns. This helps developers maintain consistent naming conventions in their CSS variables.

Because the model runs locally, there is no API call, no latency, and no data privacy concerns. It is a lightweight enhancement that adds intelligence without the infrastructure overhead.

Building in Public

Building ColorWell was an exercise in balancing complexity with simplicity. The challenge wasn't just the color math; it was ensuring the WebGPU implementation remained stable across different browsers and devices. Early versions struggled with shader compilation on some laptops, which required significant optimization of the compute shaders.

The tool is designed for developers and designers who value speed and privacy. It is a paid tool, with a 7-day trial available for anyone who wants to test the full export features. For those exploring the interactive aspects, games have free turns to try out the generation logic without commitment.

Why Local-First Matters

The trend toward local-first software is gaining traction for good reason. When you remove the server from the equation, you remove single points of failure, reduce latency, and enhance privacy. ColorWell is a small example of how modern web APIs like WebGPU can enable sophisticated tools that were previously only possible with desktop applications or heavy cloud services.

If you find yourself manually tweaking colors to meet accessibility standards, this tool might save you time. It is a focused utility that handles the tedious part of color theory so you can focus on the broader design system.

You can try it out at https://colorwell.bestpaid.app.

Why I built a code debugger that never leaves your browser

AI Predictions Dev — Thu, 18 Jun 2026 18:47:56 +0000

We've all been there. You're deep in the zone, debugging a subtle race condition or untangling a messy dependency graph, and you realize you need a second pair of eyes. The instinct is to copy-paste your code into a chat interface, hit enter, and wait for the magic.

But then the friction hits.

You pause: Is this code proprietary? Does it contain API keys? Am I comfortable sending this logic to a cloud server I don't control? You might redact the sensitive bits — which defeats the point of context-aware help. Or you skip the AI altogether and go back to the slower, guaranteed-private route of manual inspection.

That tension between convenience and privacy is the real problem. Most AI coding tools solve convenience by sacrificing privacy — they trade your data for speed. For a hobby project, fine. For an enterprise codebase, or proprietary logic, or developers who are privacy-first by nature, it's a dealbreaker.

That's why I built CodeClarify.

The wedge: WebGPU and true locality

CodeClarify explains and refactors code, but the defining trait isn't that it's "local" — it's that it runs 100% in your browser via WebGPU. No backend processing your requests, no API call to a cloud provider. When you paste code, inference happens on your own GPU, right there in the tab. Nothing leaves your device — not the code, not the analysis, not the metadata.

That immediately dissolves the privacy anxiety: paste a file with production secrets or proprietary algorithms and know with certainty no one else sees it. It also means the tool works offline — if your internet drops, your debugging session doesn't.

Why browser-based AI matters

Running models in the browser is no longer theoretical. With WebGPU we can run small, efficient models directly in the page with hardware acceleration. It shifts the compute from the network to the user's device — what used to need Docker containers or heavy Python scripts now runs in a tab on a modern laptop.

The trade-off is speed: a local in-browser model is slower than a massive cloud cluster. But for understanding why a function fails — not just getting a quick patch — you need accuracy, context, and privacy more than raw throughput. CodeClarify is built for that thoughtful pause.

The experience

Paste your code — snippets, whole files, or error logs.
Define the goal — explain this, find the bug, suggest a cleaner refactor.
Local inference — the model runs on your GPU.
Result — a detailed, contextual answer with zero data egress.

Because the model is small and tuned for code, it's surprisingly good at syntax, logical errors, and cleaner patterns. It's not trying to write your whole app — it helps you debug the piece in front of you.

Honest about pricing

CodeClarify is a paid tool, kept deliberately focused and sustainable. It runs right in your browser with a 7-day trial so you can test it against your own codebase before committing. Not a freemium trap — a direct value exchange for a privacy-first tool. You can try it at codeclarify.bestpaid.app.

The future of private dev tools

I don't think the future of dev tools is just bigger models — it's smarter, more efficient ones that respect user agency. As WebGPU becomes standard, expect more tools that offer cloud-like intelligence without cloud-like exposure. CodeClarify is my attempt to build that today: for the developer who values control as much as speed.

If you're curious what's possible when AI stays on your machine, give it a spin — nothing leaves your device, just code and context.

What's your biggest friction point with current AI coding tools — privacy, speed, or something else? I'd genuinely like to hear your experience in the comments.

I built a roguelike whose dungeon master is an LLM running 100% in the browser

AI Predictions Dev — Wed, 17 Jun 2026 19:54:19 +0000

Most "AI games" phone home. Every turn is an API round-trip, every player burns your tokens, and the whole thing dies the day the bill scares you. I wanted the opposite: a text roguelike where the dungeon master is an LLM that runs entirely in the player's browser — no server, no API key, no per-token cost, and it keeps working offline after the first load.

Here's the architecture and the one bug that taught me the most.

The core trick: WebLLM + WebGPU

WebLLM compiles quantized models to WebGPU, so inference runs on the player's GPU. There is no backend at all.

const cdn = "https://esm.run/@mlc-ai/web-llm";
const webllm = await import(/* webpackIgnore: true */ cdn);
const engine = await webllm.CreateMLCEngine(MODEL_ID, {
  initProgressCallback: p => setLoading(p.text),
});

First load pulls the weights once (the browser caches them). After that every turn is local and free.

Let the model narrate — never let it adjudicate

A dungeon master should be creative, but it must not be allowed to break the rules. The split that made it stable:

Narrative comes back as free prose. Let it cook.
Mechanics — HP delta, items, whether the run ends — come back as a small JSON object the engine validates. The game loop trusts the JSON, not the prose.

My most instructive bug: early on I let the prose drive death detection (regex for "you die"), and the model cheerfully killed players on turn one with pure flavor text — "this could be the end of you" → game over. Moving death to an integer the engine owns (if (hp <= 0)) fixed it instantly.

Rule of thumb: the LLM writes the story; your code keeps the score.

Why on-device is the right default for indie games

$0 marginal cost — 10 players or 10,000, the server bill is identical: nothing.
Privacy — choices never leave the device.
Offline — runs on a plane after first load.
No rate limits, no leaked keys.

The tradeoff is model size: you run something small enough to load in a tab, so prompt design carries real weight. For a narrative game master that's a fair trade.

One engine, many games (config beats code)

Genre is just a config object — palette, HUD labels, seed scenarios, system prompt. Same engine, swap the config, ship a different game. Adding a genre is data, not a code change, which means a generator can author new ones.

If you want to poke at a live one, the cyberpunk build (NeonHeist) and a few others are up under Games at bestpaid.app — all running on-device.

Happy to go deeper on the JSON-contract prompt or the WebGPU loading UX in the comments.

Dev tools that run 100% in your browser — your data never leaves the page

AI Predictions Dev — Sun, 14 Jun 2026 10:45:26 +0000

Most "free online dev tools" quietly POST everything you paste to a server. For API payloads, tokens, or customer data, that's a bad default.

A cleaner pattern: tools that do all the work client-side. The page loads once, then parsing/generating/converting happens locally — nothing is uploaded, no signup, and it works offline.

Here's a set that actually follows this. All have a free core; paid only unlocks bulk/export/history.

Runs entirely in your browser

JSONForge — format, diff, validate, infer a schema. Inspect payloads you'd never paste into a random box.
RegexBuilder — live match highlighting + a plain-English explainer; Pro exports the pattern as JS/Python.
PasswordForge — passwords/passphrases generated locally; secrets never hit a network.
ColorWell — palettes + WCAG contrast; export CSS vars / JSON tokens.
CronExplain — cron → plain English + next run times.
MetaForge — meta-tag audit + Google/social preview.
TimeForge — multi-timezone overlap planner.

On-device AI (the model runs in the browser)

PrivateScribe — summarize/rewrite/draft with AI that runs locally; nothing you type is uploaded.
Grimhollow — an AI dungeon master that runs fully offline after a one-time model download.

Why bother?

Privacy by architecture — no server log to leak.
No signup friction — paste, get the answer.
Works offline — even the on-device-AI ones.

The trade-off is honest: free covers everyday use, paid adds bulk/exports/history. If you touch anything sensitive, in-browser tools are simply the safer default.

What in-browser tools do you reach for? Curious what I'm missing.