Foldr — AI-powered file organization
Designing the intelligence layer, not just the interface.
Role
Design engineer, founder
Duration
8 weeks design (still ongoing)
Tools
Figma, Claude code, VS code, GitHub
TL;DR
File chaos costs freelancers real time and credibility. I built Foldr because I lived it, then validated the market was bigger. MVP before interviews: AI reasoning can't be evaluated in the abstract. Two rounds of testing later, bringing it to market.
Finding the signal
Before building, I went looking for signals. Forum threads, product reviews, and community sites told a consistent story: users weren't just frustrated, they were actively requesting automation. The market had already formed around the need.
The browser extension path was intentional. Cloud drives are where the problem lives, and an extension meant no installation friction and a real-world proving ground before committing to a native desktop build.
The approach
MVP user flow
The MVP user flow was built around one hypothesis: that AI could reason about a folder's contents and suggest an organization that felt right to the person who owned it. Getting that hypothesis in front of real users as quickly as possible shaped every scope decision.
Product roadmap
The roadmap is a sequence of learning stages, each with a question it needs to answer before the next phase opens up.
Immediate:
Ship the MVP happy path and get AI organizational reasoning in front of real users.
Near-term:
Add history and rules — features surfaced directly by Round 2 testing, not assumed.
Long-term:
Expand to local file systems and address the security and privacy questions that come with it.
Design
Designing the environment
The drawer embeds directly into Google Drive without displacing any native interface. The goal was to meet users where the problem already lives and make Foldr feel like a natural part of the environment rather than an overlay on top of it.
Built for the canvas
The drawer decision fixed the canvas before design started — a bounded side panel with actions anchored at the bottom. Round 1 testing sharpened the stakes. Users wanted to refine what the AI surfaced, not restart it. That behavior meant users would return to the action area mid-flow, looking for the right next step. Discoverability wasn't decorative — it was the whole job.
The result: icons by default, labels on hover. Compact enough to fit the fixed canvas, clear enough to guide a user who already knows what they want to do, and structured to absorb new actions as the feature set grows.
Compact default state
Icons only, with function revealed on hover. All the clarity, none of the noise.
Designed for growth
The compact pattern keeps room for future actions. No redesign needed when the feature set grows.
Designing from insight
This insight didn't come from a usability test. It emerged from running the system extensively across folders of all kinds. A pattern surfaced: AI suggestions consistently fell into two operations, moving files into existing folders, or creating new folders when no appropriate home existed. What started as a long flat list of actions became a tabbed interface organized around those two mental models. An insight only possible because the designer also built and operated the system.
List view (before)
Tabbed by action type (after)
Designing for AI legibility
The transparency layer wasn't a UX polish decision. It was foundational to trust. Streaming the AI's reasoning in real time served two purposes: keep users from reading silence as failure, and make visible how the AI was interpreting the folder's contents before surfacing recommendations. The goal was to turn an opaque automation into something users could follow and verify.
Loading and completion states, streamed in real time
Designing the intelligence layer
The hardest design problem on this project wasn't a UI problem. It was figuring out what context to give the AI so it could reason accurately. Passing only the selected folder produced shallow suggestions: the AI had no awareness of the parent folder above it, or the organizational structure within it. Getting the context mapping right was the difference between recommendations that felt random and ones that felt considered.
Building it
Building Foldr meant learning the full development lifecycle — not just writing code, but owning version control, repo structure, and architecture decisions from the ground up.
That fluency changes how design and engineering meet. When you can read the constraints directly, not just describe the outcomes, the gap between design intent and what ships gets a lot narrower.
Two rounds of testing later, the core bet is validated. Still in market exploration — and still building.