I Rebuilt an App Thousands of People Use in 14 Days With AI

I’ve been a Sparkle user for a little under a year (I helped build v1), and despite it having its warts, I’ve loved the end result. My Desktop and Downloads folders being automatically organized allows me to work more peacefully, and offloading my personal organization (think: taxes, family photos, financial information) in my Google Drive to Sparkle means that I find what I need with no hassle. Sparkle is a sneakily special product, and we have a huge vision for it. To get it where it needs to go, we needed to rebuild it from the ground up. Sparkle general manager Yash Poojary explains how he did so in this piece.

To celebrate the launch of Sparkle v2, we’re giving 25 percent off the Every bundle—your all-access pass to Sparkle, Spiral, Cora, and our full library of newsletters and podcasts. Only want Sparkle? The lifetime plan is 25 percent off, too (just download the app). The offer is valid for the next 48 hours.—Brandon Gell

Every week, someone spins up an AI-powered app, drops a slick demo, and wakes up to $100,000 in annual recurring revenue. It sounds like a dream. These stories are equal parts inspiring and suspect. But mostly, they signal that the way we build software is changing.

Fast.

So I tested it the only way that made sense: by rebuilding something thousands of people use every day—Sparkle. It uses AI to reorganize any folder into a clean, structured system, all in the background so you never have to think about file management again.

I’m building Sparkle to be the default way people manage files on their (read: your) Mac. It’s already organized over 10 million files. People like bestselling author Tiago Forte praised it as “the end of organizing.” But the existing version had technical limitations holding back the user experience.

Sparkle was built with Electron, an open-source framework that made it increasingly painful to maintain. Even implementing a simple paywall took weeks of frustrating workarounds. I thought that by rebuilding Sparkle in Swift, Apple’s preferred language for building native Mac apps, we could make everything feel smoother, faster, more stable. It would act like a real Mac app because it would be one. 

It was also, admittedly, selfish. I use Sparkle every day, and it kept getting in my way. I couldn’t tell where my files were going. I couldn’t pause organizing. I couldn’t tweak how often it checked for new ones. I figured that if I was going to spend this much time using it, I might as well make it intuitive.

So I gave myself two weeks to rebuild it from scratch, not because it was realistic, but because artificial deadlines force real choices.

Vibe coding, take one

The one-shot build is a popular idea in AI: the fantasy that, with the right tools and a solid prompt, you can ship an entire product in a single pass. No rewrites or second-guessing—just generate, polish, ship. 

I wanted to see if that was possible. I’d always been intrigued by the idea of vibe coding, using AI to build quickly with creativity and intention.

The part that really resonated with me came from OpenAI co-founder Andrej Karpathy: You stop thinking like a traditional programmer. You give in to the flow, ignore the underlying code, and just tell your AI assistant what you want. You say things like, “Make the sidebar padding smaller,” without touching the actual layout file. You accept every suggested change without checking the diff. When something breaks, you don’t debug—you just paste the error message into the chat and hope the model fixes it.

I went into the project feeling confident. I had what I called the three Cs of vibe-coding: Claude for code generation, Cursor as my go-to code editor, and caffeine (read: Diet Coke) for the inevitable late nights. 

With that tech stack, I figured I could knock out most of the app in a weekend, and I did. The first version of v2 came together in just two days. The core file logic was in place, the user interface was functional, and the onboarding flow was complete. Internally, the team responded positively when I gave them a demo.

But something felt off. The team was happy, and I should’ve been too. That night, after presenting the demo, I couldn’t sleep. I kept turning it over in my head.The structure felt shaky. The interface felt soulless. It didn’t reflect any real intention; it wasn’t sparkling.

So I got on a video call with Brandon Gell, the head of Every Studio, and expressed my concerns: I needed a bit more time to get this right. He looked at me for a second and said: “Go be an artist.” 

That was all I needed to hear. I realized that while the first version worked, it didn’t fully align with my vision. The issue wasn’t just about writing more code. It was about giving the model the right context in the first place.

What follows is what I learned about vibe coding a real product: the pitfalls to avoid, strategies that actually work, and why good software still comes down to clarity and taste.

Step 1: Set the stage

Before writing a single prompt, I put together a starter project: an early version of Sparkle with just enough in place to show the model how things worked. The folders were named, the files were mapped, and the structure made it clear what connected to what. While the first version didn’t land, it had given me exactly what I needed: a clear foundation to build something better.

There was base functionality for how Sparkle listens to file changes, organizes them into folders, saves settings, and talks to the backend (which we use to sync things like preferences and recent changes). 

There’s a saying that you’re the average of the five people you spend the most time with. The same goes for code. Your code is the average of the first five prompts you feed into your editor. If those prompts are scattered or vague, the model will drift. But if you set a strong foundation early—clear structure, naming, logic—the model starts acting like a teammate instead of a guesser. 

Step 2: Use a model that gets it

This is where Gemini 2.5 Pro came in.

Most coding models aim for efficiency. It works until you try to change one line, and then it rewrites the whole function like it forgot what it just wrote. 

Gemini felt different. It utilized more tokens, not for verbosity, but to reason through the entire setup. It remembered what I'd already written and understood the underlying structure.

Gemini 2.5 Pro is built to think before it speaks. It’s what’s known as a thinking model, one that reasons through a problem step by step instead of racing to the finish. That shift shows up in the output: cleaner code, smarter suggestions, and fewer weird bugs that take hours to untangle. It didn’t feel like autocomplete. It felt like working with a developer who actually understands the code before jumping in.

Step 3: Don’t just prompt—direct

Once the foundation was in place, writing prompts stopped feeling like micromanaging and started feeling like giving creative direction.

Here’s a prompt I used:

“Build a Swift class that watches the newly added folders for files and moves them to the Recents folder using our folder config. Use async/await, avoid blocking the main thread, and place it inside FileOrganizer.swift.”

Because Gemini already had the context of my code structure, it knew what I meant. It reused helper functions, respected the naming patterns, and slotted the code exactly where it belonged. There were no vague abstractions or context drifts.

But here’s the prompt I wish I could use:

“Move new files into Recents automatically.”

Models are already moving in this direction. The next generation of models won’t need you to spell out class names or cram your prompts with technical terms. Models will infer your project’s structure and fill in the gaps, so you can focus on what you want instead of how to write it. You’ll direct a collaborator, not type code.

But back to the present: When my prompts didn’t land, I didn’t loop endlessly. If it wasn’t usable after three tries, I rewrote the prompt or fixed it myself. I learned this the hard way: Don’t prompt like you’re asking for help; prompt like you’re guiding a junior developer who’s already read the onboarding doc.

The best results came when I:

• scoped the request clearly ("one Swift class, not a full flow")
• tied it to a real file or function in the project
• referenced existing structures by name ("FolderRule," "FileManagerHelper")
• gave it clear constraints—what tools to use, what to avoid, and how clean the implementation should be. Those guardrails helped the model build something that wasn’t just functional, but aligned with how I wanted the system to work.

Step 4: Time for vibe debugging

For the next two days, everything flowed. The code made sense, the prompts landed, and Sparkle felt alive. Then, out of nowhere, the vibe cracked.

We needed a simple feature: When Sparkle moves a file, it should log the folder’s move under “recent changes.” And when someone clicks on the log, it should open the file’s location in Finder—straightforward, or so I thought.

I was surprised, honestly. Gemini 2.5 Pro had been sharp before, but this time it gave me 100 lines of bloated, overengineered code that missed the point entirely. I tried again. Five prompts later, it was still off.

So I did something I hadn’t done in a while: I looked up the solution on Stack Overflow, and found a thread with the exact answer I needed. It was just two lines of code, and it worked. No prompting, no rerouting, just writing it myself.

That moment snapped something into focus.

Until then, I’d been stuck in what I now call vibe debugging v1: Copy the error, paste it in, hope the model figures it out. If it fails, prompt again, or move the bug somewhere you can’t see it.

It’s chaotic, hands-off, and weirdly effective, but only to a point.

Writing the fix myself reminded me: I wasn’t collaborating with these models. I was outsourcing to them. And when things broke, my only instinct was to try harder prompts instead of stepping back to think.

That’s when vibe debugging v2 kicked in: Don’t just fix broken code, but figure out how to work with your tools. Know when to guide them, when to reroute, and when to code it yourself. Treat them not like magic boxes—but like teammates.

So I reframed my setup:

• Gemini 2.5 Pro → systems architect. It remembered structure, reused helpers, and didn’t hallucinate. I used it for anything that involved reasoning across files or managing background behavior—core logic, file observers, folder rules.
• Claude Sonnet 3.5 → UI lead. It was faster, better with tone, and made cleaner SwiftUI layouts with less fuss. Perfect for onboarding screens, modals, and interface logic that needed to feel Mac-native.
• ChatGPT o3-mini-high → utility developer. Lightweight, responsive, and ideal for quick helpers, refactors, or fixing syntax issues Gemini and Claude sometimes missed.
• And me → the last-mile feel checker. The models got me 80 percent there. For the final 20, I jumped in: I refined each prompt, ensured the correct files were in context, and avoided letting the process spiral into a recursive loop. When the output missed the mark, I was there to steer.

After this, on day 10 of my rebuild, Sparkle was working. And yet I still wasn’t happy. It was missing something.

Step 5: A personal touch

Sparkle still didn’t feel like something I had crafted.

So I texted a trusted designer friend and made him an offer: Try the app, give me your honest take, and if you help me redesign it, I’ll build your next app.

Within an hour, he was clicking around, sending Figma links, and pointing out things that didn’t feel right. We stayed up past 5 a.m., redesigning the entire app over bowls of ramen. At one point, we laughed because the folder animation looked too good.

That night felt like magic. It wasn’t about fixing Sparkle. It was about bringing it back to life with energy and intention, building something that felt like us.

And more than anything, it reminded me how good it feels to build with friends. The late nights, the feedback, the inside jokes—that’s the part I want more of.

Was vibe coding worth it?

Traditional builds stretch time. You write scaffolding. You pause for planning. You spiral on abstractions you don’t need. When you rebuild an app in days instead of months, you’re forced to face the product directly. There’s no buffer or hiding in frameworks. Every design choice has to hold up in motion.

That pressure clarified things. It exposed what Sparkle needed, what didn’t matter, and where the pain was hiding. That’s the magic of vibe coding. You can move fast, yes—but more importantly, you can recover fast. You can throw out a version and try something else. You can rewrite the same file four times until it feels right, because it's only been 20 minutes, not two weeks.

So did vibe coding make Sparkle better in a way traditional development wouldn’t have?

Yes. But not just because it was faster—because it helped me stay inside the product’s energy.

There’s a zone you hit when you’re building something you actually use. Not planning, not estimating—just fixing, nudging, crafting. You go from “this feels wrong” to “this looks better” in a single sitting. You’re not just solving bugs. You’re shaping taste.

Vibe coding kept that zone open. It lowered the walls between vision and implementation. I didn’t have to schedule a fix for the next sprint or spec out a new flow. I could just build it, test it, tweak it.

And that’s what made this version of Sparkle different. It’s not just that the code is cleaner—it feels like the product I’ve always wanted to use. The animations sparkle. The onboarding is smooth. The organization logic is smarter. The revert button makes sense. And it’s not because I planned better, but because I stayed close to it long enough to get it right.

If you're thinking of trying vibe coding, you should. It's worth it. Vibe coding didn’t make the work disappear—it just made it count.

What's next for Sparkle

Context-aware organizing, privately

File names are a good start, but real organization comes from understanding what a file contains. We're tinkering with lightweight, on-device models that can quickly understand your documents by reading metadata, tags, and even the contents—privately, locally, and without ever sending data to the cloud.

Workflow building blocks

Easily set rules like, “Move files tagged ‘figma-design’ to Documents at 6 p.m.” or, “Automatically group anything mentioning ‘Chase’ into Bank Statements.” Sparkle chains these mini-workflows together, so you can build a filing system that adapts exactly to the way you work.

Ask Sparkle 

Wonder where that huge Keynote file went or which PDFs mention quarterly results? Just ask, and Sparkle will find it, move it, or even delete it instantly.

File management isn’t just about organizing. It’s about cleaning up messy names, removing duplicates, and handling apps and installers. That’s where we’re headed—making Sparkle the one place your Mac turns to for keeping files in order.

If you want to see what vibe coding actually looks like, Sparkle is the real-world result. You can download it from here.

To celebrate the launch of Sparkle V2, we’re giving 25 percent off the Every bundle—your all-access pass to Sparkle, Spiral, Cora, and our full library of newsletters and podcasts. Only want Sparkle? The lifetime plan is 25 percent off, too (just download the app). The offer is valid for the next 48 hours.

Yash Poojary is the general manager of Sparkle. Follow him on X and LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Automate repeat writing with Spiral. Organize files automatically with Sparkle. Write something great with Lex. Deliver yourself from email with Cora.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Get paid for sharing Every with your friends. Join our referral program