DEV Community: Krystian

I built a silent, privacy-first file organizer that lives in your system tray and sorts your Downloads folder automatically

Krystian — Sun, 10 May 2026 12:22:49 +0000

I don't know about you, but my Downloads folder has always been a disaster zone. PDFs next to memes, installers tangled with family photos, zip files from six months ago still sitting there unopened. Every few weeks I'd open it, sigh, and spend ten minutes manually dragging things into folders. Then two days later it'd be chaos again.

So I built Mouzi — a tiny desktop app that watches your Downloads folder and automatically sorts every file by type into the right subfolder. All while living silently in your system tray.

🤔 The Problem

Let's be honest — we all download files constantly:

That one PDF invoice you need for taxes
A Zoom installer for tomorrow's meeting
Screenshots from the last debugging session
The .zip someone sent you on Slack three months ago

They all land in the same flat folder. Finding a specific file becomes a hunt. The Downloads folder becomes a digital black hole.

✨ The Solution

Mouzi sits in your system tray and monitors your Downloads folder for new files. When something appears, it moves it to the appropriate subfolder based on its extension:

File Type	Extensions	Target Folder
Images	.jpg, .png, .gif, .webp	Downloads/Images/
Documents	.pdf, .docx, .xlsx	Downloads/Documents/
Archives	.zip, .rar, .7z	Downloads/Archives/
Installers	.exe, .msi, .dmg	Downloads/Installers/

No popups, no notifications, no interruptions. It just works.

🛠️ Use Case: My Real-Life Workflow

Here's how Mouzi actually fits into my day:

Client sends a contract as PDF → lands in Downloads
Mouzi moves it to Downloads/Documents/
I download a logo asset as PNG → lands in Downloads/Images/
I grab a new tool as .exe → lands in Downloads/Installers/

I don't think about it. I just know where my files are. When I need that contract, I know it's in Documents. When I need that logo, it's in Images. No manual sorting, no mental overhead.

🧠 Key Features

100% Local & Private — Your file names and contents never leave your machine. No cloud, no telemetry, no tracking. Period.
Open Source (MIT) — The full code is on GitHub. You can audit every line, fork it, modify it, build it yourself.
Silent System Tray Operation — Runs in the background, completely invisible until you need it.
Undo Any Action — Every file move is logged in the History tab. Undo with one click if something goes wrong.
Custom Rules Engine — Coming soon: define your own sorting rules by extension, name pattern, size, or date. Dynamic placeholders like {year} or {month} will let you build powerful, automated folder structures.
Multi-Folder Support — Watch more than just Downloads. Point Mouzi at any folder and it'll apply your rules there too.

⚙️ Tech Stack

Layer	Technology
Desktop Framework	Tauri v2
Backend	Rust
Frontend	React 19 + TypeScript
Build Tool	Vite
Styling	Tailwind CSS
System Tray	tauri-plugin-tray

Why Tauri instead of Electron?

Bundle size: ~5 MB vs 100+ MB
Memory: Uses the system WebView, not a bundled Chromium
Rust backend: Native performance for file system operations
Security: Minimal attack surface, explicit permissions model

🔒 Privacy Philosophy

I built Mouzi because I couldn't find a file organizer that didn't want to upload my file names to some cloud or charge a subscription. Mouzi is built on three principles:

Local-first — everything runs on your machine
Open source — transparent and auditable
Zero friction — no accounts, no paywalls, no features locked behind payments

📥 Try It

🌐 Website: https://mouzi.cc
🐙 GitHub: https://github.com/hsr88/mouzi

Mouzi is free forever. If it saves you time and you want to support ongoing development, you can buy me a coffee on Ko-fi.

🚧 What's Next

This is an early beta. I'm actively working on:

Custom rules engine with pattern matching
Scheduled folder cleanup for Downloads older than N days
Dark mode
Native Acrylic/Mica effects on Windows
macOS and Linux builds

🙏 Feedback Welcome

I'd love honest feedback — bugs, feature ideas, code reviews, everything. I'm a self-taught dev and this is a project I genuinely use daily. If Mouzi could help you too, I'd be thrilled.

Drop a comment below, star or open an issue on GitHub, or reach out directly. Thanks for reading!

I tested 20 websites for consent timing — 14 loaded analytics before user approval

Krystian — Thu, 12 Feb 2026 17:56:00 +0000

We see cookie banners everywhere.

But I wanted to check something simple:

Do websites actually wait for user consent before loading analytics?

So I tested 20 sites (SaaS, e-commerce, agencies, blogs).

The result?

14 out of 20 loaded analytics before the user clicked “Accept”.

In most cases:

The banner was visible
No interaction had happened
But GA/GTM requests were already firing

Visually compliant.
Technically… not really.

How I measured it

Instead of manually watching DevTools every time, I built a small tool to monitor:

Cookies being set
localStorage / sessionStorage usage
Network requests to common tracking domains
The exact timestamp of the consent click

Core logic:

If tracking_timestamp < consent_click_timestamp
→ tracking happened before consent

Simple in theory. Messy in real-world implementations.

The tricky parts

SPAs injecting CMP late
GTM containers firing too early
Server-side tagging hiding third-party domains
Heuristic detection vs explicit CMP integration

Most issues looked like misconfiguration — not intent.

Why this matters

As developers, we often:

install GTM
plug in analytics
add a CMP
assume everything is fine

But unless you verify timing, tracking may fire earlier than expected.

The browser doesn’t lie.
Network requests don’t lie.
Timestamps don’t lie.

If you want to test this yourself

I packaged the tool into a Chrome extension called ConsentScope.

You can check it here:
👉 https://www.consentscope.pro/

It’s not a legal tool — just a technical way to inspect what fires before and after consent.

Curious how others are validating consent timing in their projects.

No Kotlin? No Problem. How I shipped Android Apps using React & Capacitor

Krystian — Mon, 12 Jan 2026 17:50:29 +0000

For years, I thought mobile development was reserved for "native" developers. I looked at Java and Kotlin code, and frankly, I wanted to run away. I am a web developer. I think in terms of React components, hooks, and CSS.

But this week, I achieved something I didn't think was possible for me: I published my first two applications on the Google Play Store. And the best part? I didn't write a single line of native code.

Here is how I did it, and one mistake you should avoid.

The False Start: PWABuilder At first, I tried to take the shortest shortcut possible. I used PWABuilder to simply package my existing Progressive Web App into an APK.

It sounded perfect on paper, but in reality, it felt... pointless. While it technically worked, I felt like I had zero control over the native experience. It was just a website pretending to be an app, with limited access to device features and a shaky user experience. I realized that if I wanted to be on the Store, I needed something more robust.

The Solution: React + Capacitor. That’s when I found Capacitor. If you are a React developer, this tool is a superpower. Unlike PWABuilder, Capacitor allows you to keep your standard web development workflow but gives you a runtime that bridges the web world with the native world.

My workflow looked like this:

I built my UI in React (just like I do for the web).
I used Capacitor to wrap the build output.
I generated the Android project folder and opened it in Android Studio only to hit the "Build" button.

Suddenly, I had access to native plugins, a real file structure, and a performant app that didn't feel like a cheap wrapper.

The Boss Battle: Google Play Console Coding the app was actually the easy part. The real challenge was the Google Play Console. If you are an indie developer, be prepared for a bureaucratic nightmare:

The Verification Process: It’s getting stricter every year.

Privacy Policies: You can't just ignore them anymore.

Testing Tracks: You need 12 testers for 14 days before you can even think about production (if you have a personal account created after Nov 2023) - annoying AF...

It took me some time, but finally seeing that green "Approved" status is one of my biggest wins this year.

The Result Both apps are now live. They aren't perfect, but they are shipped.

So If you are a web developer afraid of mobile stores: Just do it. Don't waste time on shortcuts like basic PWA wrappers if you want a real store presence. Go with Capacitor (or React Native), leverage your JS skills, and push through the Google Play verification. It's worth it.

Stop Crashing VS Code: How to View 10GB Log Files in Your Browser

Krystian — Sat, 06 Dec 2025 00:13:59 +0000

The "Friday Deploy" Nightmare 😱

We've all been there. It’s Friday afternoon, production acts up, and you need to investigate. You SSH into the server, find the error.log, and... it’s 8.5 GB.

You download it. You try to open it with VS Code.
Result: The window freezes. Your fans spin up like a jet engine. The OS asks if you want to kill the process.

You try Notepad++. It complains the file is too big.
You try less or grep in the terminal, but reading JSON logs in a console is a pain.

This specific frustration led me to build a tool that solves this problem once and for all.

Meet Log Voyager 🛸

I built Log Voyager – a specialized, web-based tool designed specifically to handle massive log files without eating your RAM.

It runs entirely in your browser, works offline, and—most importantly—it opens 10GB+ files instantly.

🛠️ How It Works (The Technical Part)

Why does VS Code crash? Because it tries to load the entire file string into memory (RAM) to tokenize and render it.

Log Voyager uses a different approach: File Slicing.

Instead of reading the whole file, it uses the native HTML5 File API, specifically the .slice() method.

It reads the file metadata (size).

It calculates which "chunk" (e.g., 50KB) corresponds to your current scroll position.

It reads only those bytes from the disk into memory.

This means the memory footprint is constant (~20MB), whether your log file is 5MB or 500GB. It acts like a "window" sliding over the data on your hard drive.

✨ Key Features for Backend Devs

Besides not crashing your computer, I added features that I personally missed in other tools:

🔒 Privacy First (Local Execution): This was critical. Even though it's a website, your files are never uploaded anywhere. The processing happens 100% locally in your browser's sandbox. Safe for sensitive production logs.

JSON Prettifier: If your logs are messy JSON blobs, Log Voyager detects them. One click formats them into a readable tree structure.

Warp Jump Bookmarks: Navigating a 10GB file is hard. You can "bookmark" a line, scroll 5GB down, and then "warp" back to the exact byte offset instantly.

Mobile Friendly: Since it's efficient, it works perfectly on mobile. You can analyze logs on your phone while away from your desk.

🚀 Try It Out

It is a free, open-source project. If you are looking for a reliable huge log file viewer, give it a spin next time you face a giant log file.

👉 Live App: logvoyager.cc
💻 GitHub: hsr88/log-voyager

Let me know in the comments if you have any feature requests! I'm actively working on adding regex filtering next.

Happy debugging! 🐛

A Cyberpunk notification library with glitch animations and typewriter effects.

Krystian — Thu, 04 Dec 2025 17:48:58 +0000

Just finished my latest open-source project: CyberToast.js. A zero-dependency notification system focused on Sci-Fi aesthetics. It taught me a lot about DOM manipulation and CSS animations. Check it out on GitHub!
https://github.com/hsr88/cyber-toast-js