(This story is told in two parts: first by Erik, our non-technical founder, and then by Bruno, one of our developers.)

Erik's View: The Dream

At Flywheel Studio, we believe in putting our money where our mouth is. We don't just sell software development services; we build our own products using the very same platforms and processes we recommend to our clients. This is the story of one of those products: Somara.

Somara is a platform that allows teams to collaborate with custom AI assistants in real time. But this isn't a sales pitch. It's a story about a new phenomenon we're calling "vibe coding" and the messy reality of building software in the age of AI.

The Background

We're all-in on AI. I believe it's the future, and we're obsessed with finding where it can make our knowledge-based business smarter. Unlike businesses with transactional processes, we don't have obvious tasks to automate. Instead, our value lies in our expertise, which we started capturing in a library of detailed AI assistant prompts.

For example, our "Senior Developer" assistant's instructions begin like this:

Role: You are a Senior Software Engineer AI Assistant. You possess extensive knowledge... with a particular focus on modern web and mobile development tools and platforms, including but not limited to FlutterFlow, WeWeb, Vercel, Firebase, GCP... Your primary role is to provide expert technical guidance, identify potential risks, and offer sound architectural advice...

This is just a small piece of a much larger prompt. With 27 (and counting) of these assistants, managing them in a simple document became chaos.

Secondly, these AI conversations were happening in a vacuum. When one of us used ChatGPT, it was a single-player experience. We wanted our entire team in the conversation, participating and collaborating in real time.

No tool existed for this, so I decided to build it myself. I’m not a developer, but with tools like Cursor and the power of AI, I didn't have to be.

I "vibe coded" it.

The Good Side of the Story

I went crazy. I was working late into the night, between calls, and on weekends. It was exhilarating! If you aren’t a developer, AI is a godsend. There's no better feeling than bringing your own idea to life.

As I started building Somara, however, I quickly realized how much I didn’t know about what I actually wanted. My initial idea rapidly evolved as the process of building revealed the product's true needs.

A few examples:

• Dynamic Assistants: A conversation with a single assistant wasn't enough. I added a feature to switch assistants mid-conversation. You could start with a Product Manager to define a feature, then bring in a Senior Developer to analyze its technical feasibility.

• Organization & Security: A single, massive list of conversations was a non-starter. I created "Spaces"—like folders—for specific projects. This immediately raised the need for access controls to keep conversations private.

• Encryption: If we want users to trust us with their ideas and API keys, their data has to be secure. Encrypting everything became a top priority.

My simple concept quickly spiraled into a full-fledged platform. I blew through features at a record pace. We had an MVP in a week, a functional platform in three, and our team was using it in four. At Flywheel, we would have quoted a client months for this scope of work. And I, with zero development skills, had built it in my spare time in a month.

Kind of…

The Bad Side of the Story

As our team began using the platform, the cracks started to show. A lot of it worked, but not consistently. Edge cases popped up everywhere, and adding new features became a huge problem. We had hit a wall.

It was time to call in a professional. We brought in Bruno, one of our top developers, to take the platform to the next level. I’ll let him take over from here.

Bruno's View: The Reality Check

The first time I saw Somara was one of the most bizarre experiences of my career. On one hand, the platform itself was brilliant. I immediately fell in love with it and saw its incredible potential. A tool where we could converse with AI agents that already understood our tools, processes, and business logic? It seemed like the perfect way to accelerate our own development.

On the other hand, the code was something out of a technical eldritch horror story.

At the time, I was baffled as to how something like this could even exist. But after working on Somara for a couple of months and becoming more intimate with the machinations of AI-driven development, I now have a much clearer understanding of how and when everything went wrong.

Without getting too technical, there are a few core issues with letting an AI "vibe code" without expert supervision.

1. The AI Loves to Reinvent the Wheel.

The AI loves to create complex solutions from scratch, even when perfectly good solutions already exist in the codebase. If left unattended, you end up with three different implementations of the same feature scattered across the project. One clear example was the authentication flow. A user was being redirected to the site with a seemingly valid session, but we were getting an error that auth was failing. It took me a full day of debugging before I decided to scrap it and start over. That's when I found it: we had two separate authentication implementations. One on the client-side (which was failing) and another on the server (which was succeeding).

2. The AI is a "Yes-Man" with No Sense of Best Practices.

A non-technical user doesn't know what's required for a production-ready application, and that's perfectly fine. But AI coding agents won't make suggestions for industry-standard practices; they will simply agree with whatever you ask for. Critical features like a centralized state management solution or proper request token validation will be ignored unless you specifically ask for them. Security is an even bigger blind spot. While creating a caching mechanism, the AI tool stored our un-serialized provider keys in memory—a potential disaster waiting to happen if someone isn't paying attention.

3. The Code Becomes an Unmaintainable Mess.

The original Somara was riddled with technical debt.

• State Management: The user's "current organization" was the only source of state for the entire app. Every page had its own disconnected way of handling it, so if a user changed organizations, the entire app would break in unpredictable ways.
  
  

• Permissions: User role validation was implemented separately on every single page. When we wanted to change the permissions for "Editors," it meant hunting down every instance and hoping we didn't miss one. This also resulted in lots of unnecessary database calls, making the whole app feel slow and unresponsive.

• Inefficient Features: One ambitious feature allowed users to save AI-generated code or diagrams as "artifacts." To check if the AI had failed to create an artifact, the code parsed every user message for words like "create," "design," or "diagram." This meant for every one of those words in a message, we were triggering a series of expensive database checks before the AI even started responding. The result was painfully slow response times.

I made a mistake. I thought I could just patch these problems up—add state management, centralize permissions, improve error handling—and be done. But the problems with Somara ran deep; they were ingrained in its DNA. To have any semblance of a good developer experience moving forward, we had to start over.

There is no way a non-technical founder like Erik could have seen his vision come to life so quickly before these AI tools bridged the gap between an idea and executable code. But the original Somara was exactly that: a vision. A stunning UI facade over a foundation of unmaintainable code.

Working on it has been the best and most bizarre experience of my life. Erik's trust and support were crucial. His words, "I'll let you cook, but you have to seal the deal," gave me the responsibility and freedom to work on our terms and build a product we can be proud of for years to come.

Erik: The Lessons Learned

As we rebuilt the platform, I’ve come to appreciate this chaotic process. But I’m still asking: is there a better way?

Here’s what we learned.

• "Vibe Coding" is an Elite Prototyping Tool. I'm confident that building Somara this way saved us time overall. If we had gone through our standard, multi-month design and development process, we would have missed the critical features that make the platform what it is today. Vibe coding allowed us to use the product immediately and get real-time feedback on what was missing. We condensed a three-month cycle of design, build, and learn into a single month.
  
  

• Product Management is More Important Than Ever. Scope creep is dangerously easy when vibe coding. You're the only user, and adding features feels frictionless. It's easy to say, "Oh, we totally need X!" and have the AI build it in an hour. But there’s no feedback loop on complexity, business value, or customer demand. You must retain disciplined product management to prevent building features that add complexity without adding value.
  
  

• The Rebuild Isn't a Waste; It's the Second Draft. Rebuilding from scratch felt painful at first, but it gave our developers an incredible advantage. They had a complete, functional prototype to analyze. They could see what worked and what didn't on a technical level. Hindsight is 20/20, and the first version gave them a perfect framework to build the second, professional version. It wasn't a waste; it was an essential learning step.

Conclusion

This is why Flywheel builds its own products. We experiment with new processes internally to understand their limits before we ever offer them to clients. Developing Somara with AI, throwing it away, and starting from scratch was an invaluable learning experience.

"Vibe coding" will be discounted as unscalable and insecure by many, but the technology is improving at an astonishing rate. For us at Flywheel, we see it as a powerful new tool in our arsenal. It’s not about replacing developers; it's about accelerating the journey from a brilliant idea to a tangible product, then bringing in expert craftsmen to make it robust, scalable, and secure.

It’s a process we’re continuing to refine, and we believe it’s the future of building truly innovative products.

Thinking about how to bring your own idea to life? Reach out, and let's explore if this modern approach is the right fit for you.