February. High on New Year’s optimism, driven by a desire to build something for myself and fueled by the promise of AI to help execute, I started building Snapcoder - an AI code-generation platform that could turn UI designs into functional React components. Five months later, I shut it down. Here’s what happened and what I learned.

Enthusiasm Is No Business Plan

Snapcoder began as a weekend experiment. I wanted to improve my Golang skills and play around with OpenAI’s vision capabilities. The concept was simple: upload an image of any UI component and get back functional React and TailwindCSS code.

I’d seen Lovable gaining traction in the AI code-generation space, so I knew there was market validation, but I thought the quality of the UI Lovable produced wasn’t very good. I wanted to solve the problem for designers to have the reality of a coded component match the fidelity of their design and I began to conceptualize the project as a simple lead magnet for my burgeoning software agency.

Then I shared the proof of concept with a couple designer friends. Their feedback was overwhelmingly positive. One designer mentioned enjoying the ability to experiment with the code to see real-time previews of her design. She even considered it as a way to learn frontend coding skills. That feedback was so encouraging that I decided to see if I could build it into a paid product.

I confused enthusiasm with demand.

That was my first mistake. I confused enthusiasm with demand.

Building What I Could Build, Not What I Could Sell

Over the next few months, I dove deep into technical challenges. I learned Go concurrency patterns like routines, channels and Server Side Events to support streaming code output to multiple clients. I upgraded from early OpenAI GPT-3.5 vision models to GPT-4o, which dramatically improved output quality significantly but was painfully slow.

The image-first approach had limitations. Advanced design patterns, complex angles and shapes, and colors were hard to match exactly. So I pivoted to building a full Figma plugin to maximize context and information from design files directly. Luckily, I’d built Snapcoder as an API-first application, so integrating the plugin functionality was straightforward. I had a working MVP in an afternoon.

I was solving technical problems left and right. What I wasn’t solving was whether anyone actually wanted to pay for this.

I was solving technical problems left and right. What I wasn’t solving was whether anyone actually wanted to pay for this.

The Marketing Problem I Didn’t See Coming

Starting a business requires more than just the ability to build it. It requires the ability to sell it and market it. This is where I had a serious gap.

I launched a landing page and decided to “build in public” on TikTok. I posted regularly on Twitter in dev and builder communities. My content was mostly vibe-coding videos, AI prompting techniques, and posts called “Steal This Component” where I used Snapcoder to recreate UI designs I found online.

Early on, I was ecstatic that my landing page was generating signups. In a two months, nearly 50 people signed up for the alpha. But, when I released it to those early users, the response was crickets. One user logged in and actually used it.

Kind of…

Finally, I had engagement. One person was actually trying my product. I watched eagerly as they navigated through the interface for the first time. This was it. This was the moment I’d find out if all those months of technical problem-solving had created something people actually wanted.

Then the user uploaded a picture of a banana.

The system threw an error. He emailed me saying he wasn’t sure what the product even did.

I realized I had two problems: people will sign up for anything, and I had a serious onboarding issue. More fundamentally, I had built an audience of people interested in my coding journey, not people who had the problem I was trying to solve.

I had built an audience of people interested in my coding journey, not people who had the problem I was trying to solve.

I re-vamped the onboarding experience and provided clearer messaging but Mr. Banana never returned, and despite my best efforts to engage the other 49 users through emails and incentives, no one else signed up.

The Competition Reality Check

Around this time, I started researching the Figma plugin ecosystem more seriously. I discovered other tools doing similar work that already had huge followings, established user bases and lots of money. Worse, I became convinced that my AI-powered solution wasn’t even as good as some non-AI plugins and workflows people were already using in Figma.

It became apparent I had entered what was quickly becoming a saturated, highly competitive market against well-funded players. I wasn’t sure I had found a compelling enough angle to differentiate from the competition nor did I have the funding or marketing know-how to find that positioning.

When to Fold

By July, I was at a crossroads. I wasn’t getting traction, and I really needed feedback to validate spending time building out a paid rollout. Meanwhile, my agency work was producing actual clients and revenue.

Sometimes I wonder if I had just pushed harder on marketing, I might have had more success, but I think I made the right decision. The opportunity cost was too high, and the signals weren’t pointing toward product-market fit.

What I’d Do Differently

If I were to start the same idea today, I’d need to more quickly identify pain points for a specific audience. I’d do discovery interviews with folks in that audience before writing a single line of code. For Snapcoder, that would have meant asking designers about their workflows in Figma, what a typical handoff with developers included, whether the outcomes were ideal, and their experiences with existing AI code-generation tools.

I learned that validation should happen before you build anything, not after. I thought I knew what fast validation was, but in practice it needed to come sooner than I’d realized. Real validation isn’t enthusiastic feedback from friends or landing page signups. It’s understanding whether people have a problem worth paying to solve, whether your solution actually solves it better than existing alternatives and crafting an offer that addresses their pain points.

The Bigger Lessons

Building in public is great for building an audience, but you need to consider whether you’re building the right audience for your product. Because developers know engineering, we tend to do that first, but hindsight tells me that marketing trumps building.

I also learned that you have to build what you can sell, not sell what you can build. What can I offer to help someone meet a desired outcome or avoid pain? Build that.

These lessons have actually helped me refocus my agency away from broad offerings into a more focused niche. I heard somewhere that some of the best products get developed from learnings gained from service-based businesses and listening to your clients. That’s the path I’m taking now.

Snapcoder failed, but the education was worth it.