Self-taught developer · Builder of free client-side tools · Based in Singapore
Hi, I'm Duc Nguyen — a software developer in Singapore who builds practical, privacy-respecting tools and writes detailed technical guides. Everything published on this site is created to be genuinely useful: the tools run entirely in your browser, the guides come from real debugging and research, and everything published here is something I built and use myself.
Counts span my full network of sites (Free Tools Hub, Crypto Brief, Finance Daily, and the others listed below) — not just this root domain. This page's own articles are in the blog.
I'm a self-taught developer. I didn't come up through a formal computer science program — I learned by building things I needed and couldn't find, by reading source code written by people better than me, and by fixing the same stubborn bug at 2 a.m. enough times that it eventually taught me something. That path shaped how I work today: I respect craft over credentials, working software over presentations, and a small tool that solves one problem completely over a sprawling platform that solves none of them well.
Before focusing on this site full-time, I spent years writing automation, building internal developer tooling, and shipping the kind of unglamorous plumbing that makes other people's work faster. That background is why so much of what I build is developer-facing: formatters, converters, encoders, generators, and small utilities that take a tedious manual step and remove it. I've felt the friction of a missing tool often enough to know exactly what a good one should do.
I'm based in Singapore (UTC+8), and I run this entire operation as a solo builder — design, development, writing, testing, and support. There's no team and no agency behind it, which is exactly how I keep the quality bar where I want it.
My work is built on a small set of principles that I treat as non-negotiable. They're the reason the tools behave the way they do, and the reason I'd rather ship nothing than ship something that quietly sells out the people using it.
Every tool I publish is 100% client-side. The code runs in your browser using JavaScript and standard Web APIs; nothing you type, paste, or upload is ever transmitted to a server I control. When you paste a JSON document into my formatter, it is parsed, pretty-printed, and displayed on your device — it never touches my infrastructure, because there is no backend to touch. This isn't a marketing line. It's an architectural decision baked into every tool from the first line of code.
My open-source libraries use only the Python standard library or browser-native APIs — no transitive dependency tree of hundreds of packages I can't read. Fewer dependencies means a smaller attack surface, faster installs, fewer breaking changes, and code that anyone can audit in an afternoon. I'll write thirty lines of standard-library code before I pull in a dependency for the same job.
I'd rather publish one thorough guide that solves a problem completely than ten shallow ones that each leave the reader stuck. When I write about JSON parsing or client-side encryption, the article reflects real debugging sessions — the actual errors I hit, the trade-offs I weighed, the benchmarks I ran. There is no AI-generated filler on this site, and there never will be. Every sentence is something I either verified, measured, or learned the hard way.
The tools are free, and they stay free. No paywalls, no sign-ups, no "premium tier" that gates the useful features behind a credit card. Optional Ko-fi support funds the work, but it never gates the tools.
This site is a hub that connects several focused projects, each maintained independently and built around a clear purpose:
Most of my tools share the same architecture: a single static HTML page, a small amount of vanilla JavaScript, and the browser's built-in APIs. There is no application server, no database, and no build pipeline more complex than necessary. The practical consequences are significant, and they're worth stating plainly.
Because there is no backend, the marginal cost of a new user is effectively zero. A tool can serve one person or a million without me provisioning another server, which is exactly why I can keep all of them free. Because the code is vanilla JavaScript with no framework lock-in, a tool I wrote two years ago still works today without a forced migration to a new major version of some library. And because every computation happens client-side, I never have to make a privacy promise I can't keep — I literally have no server on which to store your data.
I write zero-dependency Python for the libraries I open-source, using only the standard library. That discipline forces me to understand what I'm actually depending on, keeps the install footprint tiny, and makes the code auditable: a security-conscious user can read every line in a single sitting. When I do reach for a third-party package, it's a deliberate choice with a documented reason, never a reflexive pip install.
The articles and guides on this site are held to a standard I take seriously, because the whole point of writing them is that they should be worth your time to read.
Every guide starts from a real problem I needed to solve or a question I couldn't find a clear answer to. I write the first draft only after I've actually done the thing — run the benchmark, reproduced the bug, tested the workaround. Code samples are tested, not theoretical. When I cite a number (a parse rate, a byte size, a latency), it came from a real measurement on my machine, and I describe how it was taken so you can reproduce it. When I'm uncertain about something, I say so rather than papering over it with false confidence.
I do not publish AI-generated filler. Large language models are genuinely useful for some of my workflow — drafting, brainstorming, translating rough notes into prose — but no article goes live without being rewritten, fact-checked, and verified by me. If a sentence couldn't have come from my own keyboard after real experience, it doesn't belong on the site. This matters because Google's quality guidelines and the broader web are increasingly flooded with low-effort generated content, and the only durable response to that is to publish work that's demonstrably the product of a real human who actually did the thing.
This site is funded through two channels, and I want to be transparent about both because the funding model is what allows the tools to stay free and private.
First, optional sponsorships via GitHub Sponsors, for people who want to support the open-source work directly.
Second, optional Ko-fi support — a voluntary tip jar for anyone who finds the tools useful and wants to say thanks. There is nothing to buy and nothing is gated behind payment; every tool and every guide is free.
I want to be honest about what I am and am not. I am a working developer with years of experience building automation, developer tooling, and client-side web applications, and I've shipped enough of it to know where the sharp edges are. I am not a licensed financial advisor, a medical professional, a lawyer, or a certified security auditor — and the tools and guides in Finance Daily, Health Today, and the security articles are educational, not professional advice. Where a topic crosses into licensed territory, I say so plainly and point you to a qualified professional. I'd rather under-claim and over-deliver than the reverse.
What I can claim with confidence is that every tool on this site was built by me, tested by me, and is maintained by me — and that the writing reflects real experience rather than recycled summaries. If you find an error, a broken tool, or a guide that's wrong, I want to know about it, and I'll fix it. That openness to correction is, I think, the most important part of doing this credibly.
If you have a question, found a bug, or want to suggest a tool, the fastest way to reach me is through the contact page or directly on GitHub. I read everything, even when I can't reply to all of it. If you'd like to read more before getting in touch, the blog collects my longer writing on privacy, tooling, and the craft of building software.