ClickAi v2: Rebuilding an AI Product from Scratch

There's a moment in every product's life where you have to ask yourself a hard question: is the foundation strong enough to build what comes next, or do I need to start over? With ClickAi, I hit that moment in late 2021, and the answer was clear. V1 had served its purpose, but v2 needed to be a completely different product.

What ClickAi v1 Was

ClickAi started as an AI-powered website generator. The premise was straightforward: describe what you want, and the AI generates a website for you. No coding required. No design skills needed. Just describe your business and get a functional site.

V1 worked. People used it. But it had fundamental architectural limitations that became more apparent as AI capabilities advanced and user expectations grew. The generation pipeline was rigid, the output templates were constrained, and the customization options were bolted on rather than built in.

Most critically, v1 was built during a period when AI capabilities were more limited. The models available could handle basic content generation and layout selection, but they couldn't do the kind of nuanced, context-aware design decisions that users increasingly expected.

The Decision to Rebuild

The decision to rebuild wasn't impulsive. I spent two months evaluating whether I could incrementally improve v1 to where it needed to be. I mapped out every architectural constraint, estimated the refactoring cost, and compared it to a clean rebuild.

The math was clear. Refactoring v1 would take approximately the same time as rebuilding, but I'd end up with a system that still carried the design assumptions of the original architecture. A rebuild would take the same time but give me a foundation designed for where AI was going, not where it had been.

There's a psychological barrier to rebuilding. You look at all the code you've written, all the edge cases you've handled, all the bugs you've fixed, and it feels wasteful to throw it away. But code isn't the asset. Knowledge is the asset. Every lesson I learned building v1 was going into v2, even if none of the code was.

The Architecture of v2

V1 was essentially a template system with AI-generated content. You'd describe your business, the AI would select a template and fill in the content, and you'd get a website. It was functional but felt generic.

V2 took a fundamentally different approach. Instead of templates, I built a component-based generation system. The AI didn't select from pre-built layouts; it composed layouts from a library of design components, making decisions about spacing, hierarchy, and visual flow based on the content and purpose of each section.

The technical stack changed significantly. I moved to Next.js with TypeScript for the frontend, which gave me the component architecture I needed. MongoDB handled the dynamic data structures that varied between generated sites. The AI pipeline was completely new, using a multi-stage generation process where each stage refined the output of the previous one.

The multi-stage pipeline was the biggest architectural innovation. Instead of one AI call that tried to do everything, I broke generation into distinct phases: content strategy, information architecture, visual design, copy generation, and refinement. Each stage had its own prompt engineering and quality checks. The result was dramatically better output because each stage could focus on doing one thing well.

What I Learned About AI Product Development

Building ClickAi v2 taught me several lessons about AI product development that I keep coming back to.

The first is that prompt engineering is product design. The prompts you write determine the product experience as much as the UI does. I spent as much time crafting and testing prompts as I did writing application code. Every word in a prompt affects the output quality, and small changes can have dramatic effects on user satisfaction.

The second lesson is that AI products need graceful degradation. AI output is inherently variable. Sometimes the model produces excellent results; sometimes it produces mediocre ones. A good AI product needs to detect quality issues and either regenerate, fall back to safer defaults, or give the user easy tools to fix problems. V1 didn't have this. V2 built it into every stage of the pipeline.

The third lesson is about user control. Early AI products, including ClickAi v1, tended toward a "magic" interaction model: press a button, get a result. But users want control. They want to guide the AI, not just accept its output. V2 introduced a conversational refinement flow where users could iterate on any aspect of the generated site. "Make the hero section more professional" or "use warmer colors" became valid inputs that the system could act on.

The Migration Challenge

Rebuilding a product that has existing users introduces a challenge that greenfield development doesn't have: migration. I had users who were actively using sites generated by v1. I couldn't just turn off the old system.

I ran both versions simultaneously for three months. New users went to v2. Existing users could continue on v1 or migrate their sites to v2. The migration tool I built analyzed their v1 site, extracted the content and design intentions, and regenerated it using the v2 pipeline. It wasn't perfect, but it gave users a starting point on the new system that preserved their content and brand identity.

This migration period was one of the most stressful parts of the rebuild. Running two production systems simultaneously, with different architectures and different deployment pipelines, while also building new v2 features, pushed my operational capacity to its limit.

The Results

V2 launched in February 2022, and the difference in user response was immediate. Generation quality improved significantly. Users were spending less time customizing and more time being satisfied with the initial output. The conversion rate from free trial to paid plan increased because users could see the value faster.

But the metric I'm most proud of is the iteration rate. V2 users were making more refinements per session than v1 users, but spending less total time. They weren't iterating because the initial output was bad; they were iterating because the refinement tools were good enough to be worth using. They were crafting their sites rather than fixing them.

When to Rebuild vs. When to Iterate

If you're facing the rebuild decision with your own product, here's the framework I'd use.

Rebuild when the core architecture prevents you from implementing the features your users need. Rebuild when the technology landscape has shifted enough that your original design assumptions are wrong. Rebuild when the cost of working around architectural limitations has become a significant portion of your development time.

Don't rebuild when you're bored with the existing code. Don't rebuild when you want to use a new technology just because it's new. Don't rebuild when your users' problems can be solved with incremental improvements.

The rebuild decision should be driven by user needs and architectural reality, not by engineering preferences. I rebuilt ClickAi because the v1 architecture literally couldn't support the AI pipeline that the product needed. That's a valid reason. "I want to try this new framework" is not.

Looking Forward

V2 is live, stable, and growing. But the AI landscape is evolving so fast that I'm already thinking about what v3 might look like. The models available today are significantly more capable than what I built v2 on, and the gap is only widening.

The good news is that v2's architecture was designed for this evolution. The multi-stage pipeline means I can upgrade individual stages as better models become available, without rebuilding the entire system. The component-based design system can grow with new components without breaking existing generated sites.

Building AI products means accepting that the ground is always shifting beneath you. The best you can do is build architectures that can adapt and maintain the product knowledge that no amount of AI advancement makes obsolete: understanding what your users actually need.