Hi guys, I decided to spend these 4 hours doing something that almost no one does these days: reviewing code by hand, zero-AI. I noticed some contradictions, something that didn’t quite reflect Defied’s values and status. So here’s the final, working, bulletproof, but most importantly meaningful version of Defied’s landing page.

I will soon ship it, so wish me luck!

Hi guys, I’ve been quite busy lately with my life outside Stardance. However I still managed to put some effort on a new project: Defied.
Defied is a software company that builds advanced digital products, combining software engineering, AI and design to create reliable, elegant and accessible tools.
Here’s what I did so far:

Backend

• Built basic magic-link auth that will be later moved to a Zitadel-based auth for a more ecosystem-like architecture

Frontend

• Designed and built landing page
• Designed and built login page

Just as a quick note, this is Defied’s landing page and service wrapper, not a service. For Defied services, check out Defied Prism (Which I will later post here, as a multi-framework, css modules and tailwindcss component library).

If you ever created a web application with React using some component library, you know how it goes. You start with a simple page, maybe a header and a button. Then you add some more components, maybe a form or a dropdown. Before you know it, you have a full-blown application with dozens of components and complex state management. This is why I invented Paradox UI, an opinionated, highly-reusable React component library engineered to eliminate dependency fragmentation and bridge the gap between basic primitives and complex, data-dense UI. Built by and for the frontend community.

What I Built (The First 8 Hours)

• Set up the development environment with pnpm and turbo
• Created the basic project structure with multiple apps (web, server, docs)
• Implemented UI primitives and components in @paradox-ui/primitives (WCAG AA accessibility) and @paradox-ui/ui (divided in client and server components)
• Created the “preset submission flow”

Next Up

• Build out the main application components and pages for the web app
• Create additional UI components such as modals, tooltips, and tables
• Implement responsive design improvements

It is finally done. After 3 hours and 40 minutes, WinSentry is complete, fully optimized, and running flawlessly. The final block of development focused entirely on the user-controlled workspace clearing engine and rigorous resource profiling.

The Final Piece: The Safe Developer Staging Queue

The automated system janitor is great for temp folders, but developer bloat like node_modules or pycache requires absolute user safety.

• How it works: I implemented a high-speed, sequential directory traversal engine. When triggered on-demand via the CLI (winsentry –scan), the tool walks through user-specified workspace paths looking for target directory names defined in the config.
• The Guardrail: Instead of deleting anything, the tool calculates the total directory size and flushes the data to a local state file inside %APPDATA%/WinSentry/queue.json.
• The Interactive Review: The user is notified via the terminal that bloat has been discovered. Running winsentry –purge loads the JSON queue and gives the user an interactive, explicit review prompt to check boxes or type all to confirm deletion. Absolute control, zero risk of accidental data loss.

Production Performance Benchmarks

Since this tool was built to fight Windows sluggishness, it could not afford to be heavy. Running a fast compiled systems language like Rust paid off massively. Here are the real-world metrics monitored via Windows Task Manager:

• Idle Footprint: 0% CPU and 0.9MB of RAM. It sits completely dormant in the background, listening for the global hotkey message loop and waiting for the 30-minute system interval.
• Peak Scan & Discovery Footprint: Maximum 10% CPU usage and a peak of 5MB of RAM while actively traversing thousands of subdirectories and calculating file sizes during a deep disk scan.

On an NVMe and DDR5 setup, the scan completes in seconds, meaning the system never hitches and the user never has to wait for the utility.

READY TO SHIP!

Two more hours in, and WinSentry now has a fully functioning debloating engine and a robust multi-threaded architecture.

What’s new

• I ripped out the real-time event watcher and replaced it with a task that executes once every 30 minutes. It sleeps completely in between cycles. Performance dropped immediately back to 0% CPU on idle, achieving the exact “invisible” footprint a performance tool needs.
• Reworked Threading: Thread safety is locked down. The core engine now cleanly separates the global UI hotkey listener thread from the background debloating loop, ensuring a heavy system cleanup never hitches or delays the 300ms “Panic Button” response.
• System Debloater: The 30-minute janitor thread now actively sweeps system-generated trash paths (configured via %APPDATA%/WinSentry/config.toml). It safely bypasses active, locked files while cleanly executing deep purges on dead telemetry and crash dumps.
• Robust Logging & Documentation: Implemented a lightweight, structured local logging system to track exactly how many megabytes of ghost space are reclaimed over time. I also laid down the full README.md.

Next Up
Implementing the User-Specified Safe Queue (queue.json). I’ll be writing the directory traversal logic to detect massive developer black holes (node_modules, pycache) and scaffolding the manual CLI review step so users can safely approve massive space reclamation.

Windows has a bad habit of treating the user like a guest on their own machine. Despite running an i7-12700K, 32GB of DDR5, and a fast NVMe, I still run into locked UI threads, disappearing taskbar icons, and a persistent “waiting for the OS” feeling.

Instead of dealing with it, I’m building WinSentry—a lightweight, native Windows daemon written in Rust designed to force the OS to be responsive and clean.

What I Built (The First 2 Hours)

Instead of cutting corners, I spent the first block of development setting up a bulletproof core architecture:

• The 300ms Panic Button: Implemented a low-level global keyboard hook using the Win32 API (RegisterHotKey). Pressing Ctrl + Alt + W forcefully kills explorer.exe, wipes the easily-corrupted local %localappdata%\IconCache.db file while the thread is dead, clears the icons registry at HKEY_CURRENT_USER\Software\Classes\.png and instantly spawns a clean shell instance.
• Configuration System: Designed a centralized configuration system that initializes inside a specified directory. Users can customize their hotkeys and define exact target paths.
• Aggressive Binary Optimization: The background daemon sits completely idle at 0% CPU and takes up less than 1MB of RAM, making it practically invisible to the system.

Next Up

Moving on to the storage engine:

• Implementing ReadDirectoryChangesW for zero-overhead, real-time event tracking on high-bloat system folders (%TEMP%, crash dumps).
• Building the staging queue pipeline (queue.json) to safely scaffold and manually review massive developer black holes like node_modules and pycache before purging them.

Hi guys, I started building this project right between Flavortown and Stardance, so here’s what I did so far:

• The Content Engine: local JSON-based CMS.
• The Project CMS (Admin Panel)
• The “Contribution” Chronology: I’ve implemented a custom Contribution Graph and Timeline. Unlike a standard GitHub embed, this logic parses my own project milestones and releases (dating back to the founding of OmniCraft in 2020) to visualize activity across various platforms (Java, Discord, Web).
• WebGL Integration (“Faulty Terminal” background)
• Kibo-UI & Custom Components: I’m using a mix of custom components like PixelCard (Canvas-based shimmering effects) and kibo-ui for complex elements like date pickers and dropzones in the admin panel.

What’s missing:

• Filtering Logic
• Mobile Optimization
• Data Integrity: Some sections of the “Contributions” page are still being backfilled with historical data from the 2020–2023 era.