Filaxy Files

I'm a Senior Business Analyst by day. PC Windows from 9 to 6. Then at night I switch to my MacBook for personal projects — and every single time I touch Finder, something breaks in my brain.

Finder isn't just different. It's worse. Worse visually, worse functionally, worse for power users coming from anywhere else. Windows Explorer has had a real address bar, proper keyboard navigation, and (with Windows 11) tabs — basics macOS still treats as optional.

And here's the twist: dual-pane is the one thing neither Finder nor Explorer has ever shipped. The feature that breaks me hardest at midnight, when I'm moving files between two folders and have to open a second window and arrange them manually like an animal. Filaxy Files's dual-pane isn't catching up to Windows — it's the part where it overtakes Windows.

ForkLift exists. Path Finder exists. They're both fine. But neither one feels like "the file manager I wish came with the OS." They're ports of someone else's idea of what a Mac file manager should be — not what cross-platform power users actually need.

"I decided to stop suffering with Finder. Same day I had the idea, I started building."

Most Mac apps are built for Mac purists — people who've used macOS their whole lives and don't want anything to feel different. Filaxy Files is the opposite. It's built for the developer who runs Windows at the office and Mac at home. The designer with a PC at the studio and a MacBook at the café. Anyone who lives between two operating systems and is tired of switching mental models every time they open a folder.

That single decision — target the dual-OS user, not the Mac purist — drove every UX choice in the app. Windows-style keyboard shortcuts. Dual-pane by default. A weather widget on the taskbar (yes, like Windows 11). A status bar that lives at the bottom of the window. Nothing alien, but nothing artificially "Mac-like" either.

Zero external dependencies. No SPM packages, no CocoaPods, no Carthage. Every line of file-system access, every animation, every UI primitive — pure Apple frameworks. That decision keeps the binary tiny, the startup instant, and the long-term maintenance burden close to nothing.

Spanish-first by design. The defaultLocalization in Package.swift is "es", not "en". English is added through the LanguageService with hot-swap (no app restart). My audience starts in Latam and grows from there.

I have 28 years of experience in IT. I understand systems, architecture, file systems, OS conventions. What I don't have — and never built — is a deep daily workflow in Swift or SwiftUI.

Five years ago, that gap would have stopped me. Today it didn't, because the constraint that mattered most stopped being "how fast can you write Swift" and became "how clearly can you specify what you want."

My methodology was simple and ruthless:

1. Open Windows Explorer on a PC. Use the feature I want to replicate.
2. Open Filaxy Files on the Mac. Try to replicate it.
3. When it didn't match, take a screenshot, drag it into the conversation, and explain — in detail — what was wrong and how it should look.
4. Ship the change. Test again. Repeat.

That workflow produced ~14,400 lines of Swift in 240 hours of nights and weekends. That's about 60 lines of code per hour — a number that doesn't make sense for a solo dev writing every line by hand. It only makes sense when the dev is acting as the architect, the QA, and the product owner simultaneously, with code generation handled in tight feedback loops.

"Working with AI requires a new skill: spec-writing visual. It's no longer 'ask it to write code' — it's 'show screenshots and explain exactly what should happen.' The skill of communicating intent precisely is the new craft."

A visual test suite from day one. Every view in Filaxy Files renders dozens of small details — sort indicators, hover states, focus rings, contextual menus. Right now, when something breaks visually I find out by using the app. Snapshot tests would have caught regressions in seconds instead of days.

Bilingual from the first commit. I shipped English on top of Spanish a few weeks in, which meant retroactively wrapping every user-facing string in the localization service. Starting with both languages from the start would have skipped that refactor entirely — and forced me to think about string length and layout breakage from the beginning.

I picked Lemon Squeezy over Paddle for two reasons: it sets up in hours instead of days of KYC review, and the license API is cleaner to integrate from Swift. Both are Merchants of Record — they handle global VAT, sales tax, and disputes — so I don't end up filing tax forms in 30 countries to sell a $20 app.

When I shipped v1.0 the app was just called Filaxy. By the time v2.0 went remote — six protocols, sync engine, embedded SSH terminal — it was obvious the project had outgrown a single-app identity. The file manager wasn't going to be the only thing Filaxy ever ships.

So I split the brand into two layers. FILAXY is now the umbrella — the parent brand that future apps will hang from. The legal entity behind it is Filaxy Labs (LLC or INC, TBD on formal registration). And the macOS file manager you've been reading about for the last 900 lines is now its first product: Filaxy Files.

Future apps under the umbrella will follow the same naming model — Filaxy [Noun]: Filaxy Sync, Filaxy Drive, whatever ships next. The site at filaxy.app stays the product home for now; an umbrella-level catalog will move there once there are two products to catalog, and Filaxy Files will move to its own subdomain (files.filaxy.app).

"Naming a single product is a hundred decisions in a row. Naming a brand that will outlive any single product — that's a different exercise. The umbrella had to be neutral enough to host whatever comes next without contradicting it."