Building Stdout: A Local-First Developer Toolkit for Privacy-Focused Workflows

Chung Ho — Fri, 06 Mar 2026 17:12:22 +0000

In fintech, a single leaked payload isn't just a bug—it's a compliance incident. That anxiety of pasting production JSON into an online formatter is what killed my flow. So I built stdout: a local-first workspace where privacy isn't a feature, it's the architecture.

The Problem: When Convenience Conflicts with Compliance

As a Tech Lead working on multi-country lending products, I handle sensitive data daily: merchant KYC payloads, API keys, transaction logs, and loan calculation schemas.

The workflow was familiar:

Copy a production payload for debugging
Open an online JSON formatter / JWT decoder / base64 tool
Paste → process → copy result → move on

But step 3 always came with a quiet question: "Did this page just send my data somewhere?"

The Invisible Tracking Risk

Even if a tool claims not to store your data, the modern web is rarely that simple. When you paste sensitive merchant data into a browser-based editor, you're potentially exposing it to:

Browser fingerprinting scripts that log input patterns
Third-party analytics (Mixpanel, GA, Hotjar) capturing DOM content
Malicious browser extensions with content-script access
CDN compromises injecting telemetry via compromised dependencies

For a lending platform operating across VN, TH, PH, HK, ID with country-specific compliance rules, this isn't paranoia—it's threat modeling. A single leaked KYC document or loan schema could trigger regulatory scrutiny, merchant trust erosion, or worse.

I didn't need another online tool. I needed a trusted local workspace that respected the constraints of real-world engineering: air-gapped environments, compliance boundaries, and the simple desire to keep sensitive data on my machine.

The Solution: Local-First by Design, Not by Accident

stdout started as a personal scratchpad and evolved into a modular toolkit with 50+ developer utilities—running entirely in your browser, with zero backend, zero telemetry, zero network requests after initial load.

Core Architecture Principles

Principle	Why It Matters	Implementation
Zero-backend	No server = no attack surface, no compliance review, no operational overhead	Static hosting (Cloudflare Pages/Vercel), all logic in-client
Local-first data flow	Your data never leaves your machine unless you explicitly export it	No fetch calls to external APIs for tool processing; optional user-controlled exports
Modular registry	Scale to 100+ tools without bloating the initial bundle	Lazy-loaded tool modules via dynamic imports; shared context via Zustand
Progressive enhancement	Works offline, installs as PWA, optional Electron wrapper for power users	Service workers for caching; Electron build for system-level integrations

The "Hero Tools" — Where Local-First Shines

Instead of listing all 50+ utilities, here are 3 that demonstrate the philosophy:

JWT Debugger (Local)

Decode and verify tokens without sending them to a third-party server. Supports HS256/RS256 with local key input. No network, no logs, no surprises.
Payload Sanitizer

Paste production JSON → auto-mask PII fields (email, phone, account numbers) based on configurable rules → copy sanitized output. Built for fintech debugging workflows.
Webhook Replay Lab

Simulate webhook signatures locally using your secret key. Test signature verification logic without hitting staging endpoints or leaking test data.

These aren't just "tools that work offline". They're trust primitives: operations that were previously risky to delegate to the cloud, now safely brought back to your machine.

Technical Trade-offs: What You Gain, What You Give Up

Building local-first isn't free. Here are the real trade-offs I navigated:

Gains

Security boundary by architecture: No backend means no SQL injection, no auth bypass, no data breach surface.
Zero marginal cost: Hosting static assets is cheap; scaling is just CDN distribution.
User trust as differentiator: In a world of "free tools that sell your data", being verifiably local is a feature.

Challenges

Performance with large payloads: Processing 10MB+ JSON in-browser requires careful memory management. Solution: Web Workers for heavy parsing, with progress feedback.
State management across tools: With 50+ modules, sharing clipboard history or preferences needed a lightweight global store. Solution: Zustand with persisted middleware (localStorage, user-controlled).
Discoverability vs. bundle size: Lazy-loading solves bundle bloat, but how do users find tools? Solution: Command palette (Ctrl+K) + fuzzy search, indexed at build time.

🔍 Verifying the "Zero Network" Claim

Skepticism is healthy. Here's how I validate the privacy guarantee:

Audit network tab during tool usage
Run Lighthouse with network throttling to "Offline"
Check source for fetch/XMLHttpRequest outside of explicit export flows
Optional: build from source and verify no telemetry SDKs

The promise isn't "trust me". It's "verify me".

What's Next: From Utility to Workflow Memory

The current version of stdout is deliberately stateless: refresh the page, and your work is gone. This keeps the core simple and privacy-preserving.

But I'm exploring an optional, user-controlled sync layer—not for your data, but for your workflow memory:

Saved snippet libraries (encrypted, client-side key)
Tool preferences and presets
Session restoration across devices

The core remains free, local, and open. The value-add would be continuity: picking up your debugging context on another machine without compromising the local-first guarantee.

Would you pay for "context portability" or keep everything strictly local? This isn't a rhetorical question—I'm gathering signals before building. Let's discuss.

Try It, Break It, Make It Yours

🌐 Web app: stdout (PWA, works offline)
💻 Desktop: Electron builds via Homebrew / direct download
🔨 Contribute: Modular registry makes adding tools straightforward; PRs welcome

If you build with constraints like compliance, air-gapped envs, or just value data sovereignty—I'd love to hear which tools matter most to your workflow.

stdout is a product experiment, a distribution lab, and a case study in "free utility → optional SaaS" evolution. Built in public, because transparency is the only sustainable trust model.

Forem: Chung Ho