Every SaaS product has an onboarding flow, and most of them have historically looked the same: a multi-step form wizard with progress bars, radio buttons, and input fields. You pick a goal from a predefined list, enter some numbers, click Next five times, and land on a dashboard. It works, but it's the digital equivalent of filling out paperwork at a doctor's office before anyone has talked to you.

I recently replaced the entire onboarding wizard in [FreedomTrack](https://www.freedomtrack.io) — a financial independence tracking app I built — with a conversational AI agent. No more steps. No more radio buttons. Just a chat where you describe your financial situation in plain English, and the agent creates your records, explains FI concepts along the way, and gets your dashboard populated in a couple minutes.

Here's how I built it, the pitfalls I hit along the way, and why I believe this pattern applies to far more products than just mine.

## What Was Wrong with the Wizard

FreedomTrack's original onboarding was a 5-step form:

1. **Welcome** — Pick your financial goal from a list, select how you found us
2. **Personalize** — Enter your age, target FI age
3. **Expenses** — Enter a total monthly expense number
4. **Income** — Add income sources one by one
5. **Review** — See a summary, optionally add an asset

It wasn't broken, but it had clear problems:

**It assumed users already understood FI concepts.** When someone sees a field labeled "yield rate" during onboarding, they either guess, skip it, or leave. The form had no room to explain _why_ a yield rate matters or what a reasonable value would be for their 401k.

**It forced a rigid structure.** Some users want to talk about their investments first. Others want to start with debt. A form wizard forces everyone through the same sequence regardless of what's on their mind.

**It captured the minimum.** The wizard got a total expense number and maybe one or two income sources. A conversation naturally surfaces more detail — "I spend about 2k on rent, 400 on groceries, 200 on subscriptions" gives you three expense records instead of one lump sum.

**It felt like a chore.** Five steps with a progress bar signals "this will take a while." A chat with an opening question signals "just tell me about yourself."

## The Architecture

The replacement has three pieces: an edge function that talks to Claude, a React hook that manages conversation state, and a set of chat UI components.

### The Edge Function

The edge function is a Supabase Edge Function that acts as a proxy between the frontend and the Claude API. It authenticates the user, builds the Claude request with tools, and executes tool calls against the database.

The key design decision is the **tool loop**. When Claude decides to create a record, the edge function executes the database insert and feeds the result back to Claude as a tool result. Claude might then create another record, ask a follow-up question, or summarize what it did. This loop continues until Claude responds with just text (no more tool calls), at which point the function returns.

![Edge Function tool loop diagram](/images/blog/edge-function-tool-loop.svg)

The tools available to Claude mirror the app's data model:

- `create_asset` — investments, retirement accounts, property
- `create_liability` — mortgages, loans, credit card debt
- `create_income` — salary, freelance, side income
- `create_expense` — rent, groceries, subscriptions
- `update_profile` — goals, age info
- `complete_onboarding` — marks onboarding done, writes a summary

Each tool inserts directly into the database with the authenticated user's ID. By the time the conversation is done, the user's dashboard is fully populated with real data.

### The System Prompt

The system prompt is where the domain knowledge lives. It teaches Claude the FI concepts that matter for the app:

- The 25x rule (FI number = 25x annual expenses)
- What yielding assets are and why they matter
- How savings rate is calculated
- Reasonable yield rates and growth rates for common asset types

It also defines conversation flow guidance — start with goals, then expenses, income, assets, debts — but explicitly tells Claude to be flexible and adapt if the user volunteers information in a different order.

One important behavioral rule: **confirm before creating records.** The agent should say "I'll create a $4,200/month expense record for your total monthly expenses" before actually calling the tool. This gives the user a chance to correct mistakes before data hits the database.

### Conversation History

The first version sent only the text content of previous messages to Claude on each request. This meant Claude had no memory of its own tool calls — it didn't know what records it had already created. The result: duplicate records.

The fix was to return the **full message chain** from the edge function, including the raw tool_use and tool_result message blocks. The frontend stores these in a ref and sends them back as conversation history on each subsequent request. Claude sees its own prior tool calls and their results, so it knows exactly what's been created.

The display messages (what the user sees in the chat) remain simple — just text and created record cards. The API conversation history is a separate, richer data structure that preserves the full tool interaction chain.

### The Frontend

The chat UI is straightforward: a message list with auto-scroll, a text input, and a header with a "Skip to Dashboard" button. Messages are styled as bubbles — user messages right-aligned, assistant messages left-aligned. When the agent creates a record, a compact card appears below the message showing the record type, name, and value.

The hook manages two parallel data structures:

- `messages` — the display state (simple text + record cards)
- `apiHistoryRef` — the full API conversation history (tool calls included)

On completion, the agent calls the `complete_onboarding` tool, the response includes an `onboardingComplete` flag, and the UI swaps the input for a "Go to Dashboard" button.

## What Makes This Better

**Natural language parsing removes friction.** "I make about 120k" becomes a $10,000/month income record. "We spend maybe 4k a month total" becomes an expense record. Users don't need to think about which field to put a number in or what format to use.

**Concepts get explained in context.** When the agent asks about investments, it can naturally explain yield rates: "For a broad index fund, a yield rate around 2% and growth rate around 7-10% would be typical." This happens in conversation, not as a tooltip the user has to hover over.

**The flow adapts to the user.** If someone opens with "I have $200k in student loans and I want to get out of debt," the agent starts with liabilities instead of forcing them through a goal-selection step first. The conversation goes where the user takes it.

**More data gets captured.** In the wizard, users entered a single total expense number. In conversation, they naturally break things down — rent, car payment, groceries, subscriptions — which gives the dashboard much richer data to work with.

**Skip still works.** The "Skip to Dashboard" button is always available. Any records created during the conversation persist even if the user skips partway through. There's no all-or-nothing commitment.

---

Want to see this in action? Try the conversational onboarding at [FreedomTrack.io](https://www.freedomtrack.io) — it's free, and you'll have your FI dashboard populated in a couple minutes.

_If you're looking at your own product's onboarding (or any workflow that could benefit from conversational AI) and thinking "this could work for us" — I'd love to chat. I build these kinds of agentic integrations for teams. Hit the "Get in Touch" button below or reach out on [LinkedIn](https://linkedin.com/in/awwester)._


How I replaced a 5-step form wizard with a conversational AI agent that collects richer data while teaching users along the way

Replacing Onboarding Forms with an AI Conversational Agent

We've all been there: you ask an AI coding assistant to implement a feature, and it immediately starts making changes across multiple files. Halfway through, you realize it's heading in the wrong direction, making assumptions that don't align with your architecture. Now you're faced with a frustrating choice—spend time fixing a tangled mess of changes, or just revert everything and start over.

There's a better way. Today, I want to share how Claude Code's Plan Mode prevents this scenario entirely by establishing a clear roadmap before any code gets written.

## The Challenge: Adding a "Remix" Feature

Recently, I worked on adding a new "Remix" feature to an application that processes YouTube videos and creates content based on that video, such as a news summary article. The requirement was to allow users to enhance existing generated content by incorporating additional source materials like PDF reports or web articles. This required API changes, service changes for parsing files or URLs to gather data to pass into LLM for remixing the content, database considerations, frontend form components with validation, frontend service for managing the request/response, file upload handling for multiple formats, integration with existing content generation pipelines, and UI/UX implementation.

## The Tale of Two Approaches: With and Without Plan Mode

To truly appreciate the value of Plan Mode, it's helpful to contrast what this development process would have looked like without it.

### Without Plan Mode: Direct Implementation

In Claude Code without Plan Mode—where there's minimal upfront discussion and the AI jumps straight into implementation—here's how this remix feature would have unfolded:

1. **Initial Analysis**: Claude Code would receive the requirements ("add a remix feature") and perform some quick analysis based on its understanding
2. **Assumptions Made**: It would make assumptions about implementation details—perhaps assuming we should reuse the existing "regenerate" function which starts from scratch, or assuming we need storage for the source files provided
3. **Immediate Implementation**: Development would begin immediately based on these assumptions
4. **Mid-Development Surprises**: Halfway through coding, we'd discover that reusing the regenerate function doesn't preserve the original content for remixing, or that we don't actually need persistent storage for the source files
5. **Course Corrections**: This would lead to refactoring, redesigning, and potentially scrapping work already done
6. **Iterative Fixes**: Multiple rounds of "let me fix this" and "actually, let's try this approach instead"

The result? A meandering development process with false starts, wasted effort, and potentially a final implementation that addresses the immediate need but creates technical debt.

### With Plan Mode: The Structured Approach

Plan Mode completely transforms this dynamic:

1. **Collaborative Planning**: Claude Code presents a comprehensive, step-by-step plan covering all aspects of the feature, breaking it down into phases and sub-tasks
2. **Feedback Loop**: I can review the plan, spot potential issues, and provide feedback before any code is written or any file is changed
3. **Shared Understanding**: We align on implementation strategy, architectural decisions, and user experience considerations upfront
4. **Informed Execution**: Development proceeds with confidence in a structured way because the approach has been validated
5. **Smooth Integration**: Each implementation step builds logically on the previous ones because the interfaces and dependencies were planned in advance

### The Key Difference: Collaboration vs. Assumption

The fundamental difference isn't just about planning—it's about **collaboration**. Without Plan Mode, Claude Code has to make educated guesses about my intentions and preferences. With Plan Mode, we have a conversation about the approach before committing to it.

This dynamic mirrors the relationship between a product manager and an engineer. The PM provides requirements and context, the engineer proposes a technical approach, they discuss trade-offs and alignment, then the engineer executes with confidence. Plan Mode transforms Claude Code from a "guess and implement" tool into a collaborative partner that seeks alignment before action.

## Planning Prevented These Problems

Plan Mode forced us to step back and analyze the full scope before any code was written. What seemed like "just adding a button" revealed multiple layers of complexity that could have derailed the implementation:

**Over-Engineering the Database**: Initially, we considered creating a new remix_sources table to store uploaded materials. Planning revealed this was unnecessary complexity—the remix functionality only needed source material during processing, not for long-term storage. Without planning, we might have built and later removed an entire database layer.

**UI Chaos**: We were going to add the new Remix button alongside existing Regenerate, Edit, Copy, and Delete buttons. Planning helped us realize this would create a cluttered interface. Instead, we designed a clean dropdown menu that consolidates all content actions. This prevented shipping a poor user experience and then having to refactor it later.

**Component Architecture**: Rather than cramming functionality into existing components, we planned a clean separation: RemixContentForm for form logic, RemixContentDialog for dialog state, and ContentProductActionsDropdown for the consolidated UI. This upfront architecture decision prevented messy, tightly-coupled code.

**File Processing Strategy**: We decided upfront to support only PDF and DOCX files with a structured approach that makes adding new file types trivial. Without planning, we might have built a rigid solution that would require significant refactoring to extend.

Each of these decisions made during planning prevented expensive mid-development course corrections and potential reverts.

## The Implementation Journey: Staying on Track

With our plan in place, the implementation became a series of well-defined, manageable tasks: Backend Foundation File processing utilities with proper validation, new API endpoint with multipart support, and enhanced content generation logic to handle remix scenarios. Frontend Polish Reusable form components following established patterns, dialog components with both controlled and uncontrolled modes, and clean dropdown interface replacing button chaos. Integration Points Service layer updates with proper error handling, React Query hooks for state management, and real-time updates via existing WebSocket infrastructure. Each step built logically on the previous ones, and because we had planned the interfaces upfront, integration was smooth.

## Key Lessons Learned

### 1. Planning Reveals Hidden Complexity

What seemed like a simple feature request revealed multiple layers of complexity that only became apparent through thorough planning. Without this upfront analysis, we would have discovered these complexities during implementation—when they're much more expensive to address.

### 2. Architecture Decisions Have Lasting Impact

The decision to use a dropdown menu instead of multiple buttons, or to process files in-memory rather than storing them, had implications throughout the entire feature. Making these decisions during planning, when the cost of change is low, is infinitely better than making them during implementation.

### 3. User Experience Should Drive Technical Decisions

Planning forced us to consider the user experience first, which then informed our technical approach. The dropdown menu decision is a perfect example—it was driven by UX concerns but had positive technical implications as well.

### 4. Consistent Patterns Accelerate Development

By planning to follow existing patterns (React Hook Form, shadcn/ui components, TanStack Query), we avoided reinventing the wheel and maintained consistency across the application.

## The Results

The final implementation was clean, well-structured, and user-friendly: robust backend file processing with proper validation and error handling, intuitive frontend dropdown interface with comprehensive form validation, seamless integration with existing content generation pipelines, and maintainable code that follows established patterns and is easy to extend. Most importantly, the feature shipped without major revisions or refactoring needs because the planning phase had identified and addressed the key challenges upfront.

Perhaps most remarkably, this entire feature took under 3 hours to complete, when in the past—before AI assistance was a thing—a similar feature could have taken a full week.

## Conclusion: Plan Mode is Your Friend

In our fast-paced development world, it's tempting to skip planning and jump straight into implementation. But as this example demonstrates, taking time for proper planning—especially for complex features—pays dividends throughout the development process. Plan Mode in Claude Code isn't just about organizing thoughts; it's about revealing hidden complexity before it becomes expensive, making architectural decisions when they're cheap to change, ensuring user experience drives technical implementation, and creating a roadmap that keeps development focused and efficient. The next time you're faced with a feature request that feels complex, resist the urge to start coding immediately. Fire up Plan Mode, think through the implications, and create a roadmap. Your future self (and your users) will thank you.

The remix feature described in this article demonstrates how proper planning can transform a potentially chaotic development process into a structured, successful implementation. While the specific domain was content generation from YouTube videos, these planning principles apply to any complex feature development.


Discover how Plan Mode transforms complex development tasks through collaborative planning

The Power of Plan Mode in Claude Code

## From Single Agent to Specialized Teams

The shift from using a single AI coding assistant to orchestrating specialized agent teams has fundamentally changed how I approach software development. After years of building products—from initial MVPs to scaling production systems—I've learned that the same principles that make human development teams successful apply to AI agents as well.

The traditional approach has been heavily reliant on human labor, but if you haven't heard, that landscape is changing rapidly.

Over the past couple months, I've been using Claude Code to handle my coding changes. I've thoroughly enjoyed how it breaks out prompt requests into a set of tasks, and then allows you to review the code along the way and help guide it into the proper direction. For technical users, it provides benefits over some of the earlier code editors which tend to be better for non-technical users (cursor, windsurf, co-pilot).

That being said, there still is a lot of human oversight required to build products, especially if you want it to be quality work that is easily maintained and expanded upon. Until now, I had been using a single agent (just the built-in claude code, co-pilot, cursor, windsurf, etc) in my IDE to work through coding changes. However, in the past few days I found the /agents command in claude code.

## The Vision: Specialized Agents, Unified Goal

Traditional development teams succeed because of specialization. You have frontend developers who live and breathe React, backend engineers who architect robust APIs, QA specialists who think in edge cases, and DevOps engineers who understand infrastructure at scale. My intended approach with Claude Code mirrors this structure, but with AI agents filling each role.

Currently, I've built agents for my projects that specialize in:

- **React Development**: Handles component architecture, state management, and modern frontend patterns
- **Supabase Operations**: Database design, real-time subscriptions, and authentication workflows
- **Django REST Framework**: API design, serialization, and backend architecture
- **Quality Assurance**: Test planning, edge case identification, and validation strategies
- **Code Review**: Standards enforcement, security audits, and optimization suggestions

Each agent operates with instructions that encode years of my product development experience. When a React agent consistently produces components with poor structure or continually repeats state management code, I update its prompt to emphasize proper standards which lead to a maintainable system. When the QA agent creates flaky tests for trivial edge cases, I enhance its testing methodology to focus more on actual usage cases that won't easily break with non-breaking code changes.

The problem with the single agent approach is that the instructions file becomes far too large and broad. It gets split up into several sections, however there is too much context scope for a single agent to handle everything and that in turn results in more extensive human reviews and more guidance required.

## The Orchestration Challenge

Right now, I serve as the conductor of this orchestra. I formulate task requirements, determine which agents need to collaborate, and sequence their work to avoid conflicts. A typical workflow might involve:

1. The Supabase agent creating the database migration and updating the frontend types
2. The React agent building the service layer and components that consume the API
3. The QA agent creating tests for the new coverage
4. The Code Review agent auditing everything to ensure project standards are met

This orchestration role mirrors what I've been doing manually previously—analyzing requirements, sequencing development phases, managing dependencies, and ensuring quality at each step. The difference now is scale and consistency. What once required weeks of careful coordination can now happen in hours, with the same attention to detail and best practices I've developed through years of product development.

## The Self-Serving Future

The natural evolution is automating the methodology I've developed over years of building products. I'm currently developing a project that will deploy this entire agent ecosystem as a self-serving system—essentially codifying my entire product development methodology into an automated pipeline. Imagine describing a product idea and watching as the system automatically applies all the lessons, patterns, and quality standards I've learned through hands-on experience:

- Breaks down requirements into specialized tasks
- Assigns work to appropriate agents
- Manages inter-agent communication and dependencies
- Deploys the final product

The technical challenges are significant, but the challenge is good. I'm able to build this incrementally, one step at a time, driving closer to making myself obsolete and my team of agents more useful in building products. Agent coordination requires sophisticated workflow management, shared context understanding and proper oversight for improvement. These are rapidly evolving concepts that the entire industry is still figuring out, so there is much evolution taking place constantly.

*Building with AI agents has fundamentally changed how I approach software development. If you're experimenting with similar workflows or would like to build a product together, I'd love to see if we can collaborate.*


Building collaborative AI agent systems that work together to build products

Building Products with Specialized AI Agent Teams

## Discovering AI-Generated Code

A couple of months ago, I decided to switch from standard VS Code to Windsurf. I had been using VS Code since about 2015, although since Copilot autocomplete came into the picture a couple years ago, coding became much easier. The autocomplete feature finished my thoughts, and I could even write a docstring for a class or function and Copilot would give me a usable solution, most of the time.

And then came editors that used the entire codebase as context and were able to generate full projects. I decided to try out Windsurf and see what happened. Within an hour I had a full Django REST framework server foundation ready for a stock trading application. This was no basic implementation—it contained authentication, interactive documentation, and was fully tested.

The next day I built out a personal finance application that I had in my head for years, but had never built. As opposed to the day before, this time I built out both the frontend and the backend. Everything was working great, and I built it in a day. What would have taken months of traditional SaaS development—user authentication, subscription management, admin dashboards—was scaffolded and functional in hours.

This is incredible, I thought. And my career is toast.

## The Fundamentals Haven't Changed

A client of mine sent me a message. Through his code editor, he had accidentally terminated the entire production environment, including the database. He'd been experimenting with an AI coding assistant, got confident with the rapid development speed, and made a destructive command. Here's the thing—AI is super confident, and if something doesn't work, one idea to get to its goal is to terminate your environment.

The recovery took a few days, and served as a stark reminder that while AI can accelerate development, it doesn't replace the fundamental need for proper development practices, staging environments, and human intervention (at least for now).

Even though I was able to build these projects with incredibly different timelines than before, that didn't mean that anyone could. The speed of AI-assisted development can mask the complexity of the decisions being made. When you can generate a working solution in minutes, it's easy to skip the critical thinking about whether it's the right solution. You still need to review the code, and know when something smells wrong.

The core process remains unchanged: understand requirements, build, gather feedback, and iterate. What's transformed is the speed and efficiency of execution, particularly in that crucial "build" phase, but the other phases remain important.

## Wearing Many Hats Just Got Easier

Throughout my career, I've always juggled multiple roles—product manager understanding user needs, project manager coordinating timelines, and as an engineer implementing solutions. This wasn't by deliberate choice; as a consultant working with startups and growing companies, wearing multiple hats was simply necessary. My business background has always driven me to approach solutions from a strategic perspective, focusing on what creates real value rather than just what's technically interesting.

What's fascinating is how AI code generation has shifted the balance of these responsibilities. The engineering portion, which used to consume about 90% of my time on a project, has become dramatically more efficient. I can now stand up complete SaaS applications in weeks instead of months, prototype business ideas in hours instead of days, implement complex features in days instead of weeks.

But here's the key insight: this efficiency gain doesn't make the other roles less important—it makes them more critical.

## Fast Code, Wrong Direction

The "build" phase is undeniably faster now. I can describe a component, API endpoint, or a database migration, and have working code in minutes. Features that would have taken me a full day to implement—like setting up user authentication, subscription billing, or admin dashboards for a SaaS product—can now be scaffolded and functioning in an hour.

However, this speed comes with a significant caveat: you must know what you're building and why. AI is incredibly powerful at execution, but it will enthusiastically code you into a corner if you're not providing clear direction.

I've watched AI dig deeper and deeper into architectural rabbit holes, creating increasingly complex solutions to problems that didn't need solving. Without experience to recognize these patterns, it's easy to end up with a codebase that works but is unmaintainable.

The key is finding the right balance on the spectrum of human involvement. On one extreme, you could write every line of code manually, gaining complete control but sacrificing the enormous efficiency gains AI offers. On the other extreme, you could create a completely autonomous coding agent, give it broad directives, and let it make all implementation decisions before pushing directly to production. Both approaches miss the sweet spot.

The optimal approach lies somewhere in the middle: leveraging AI for rapid implementation while maintaining human oversight of architectural decisions, code quality, and strategic direction. You want to be involved enough to catch problems early, but not so involved that you're micromanaging every function the AI writes.

## The Product Management Mindset

What I've discovered is that successful AI-assisted development requires thinking like a product manager creating requirements for a very capable but literal team member. Instead of thinking in terms of "how do I implement this function," I'm now crafting detailed product requirements to relay to my AI agent for accurate implementation.

The shift is fundamental: I'm no longer building the solution directly—I'm defining the problem and success criteria so clearly that the AI can build it correctly. The questions I ask now are:

- What exactly should this feature accomplish for the user?
- What are the specific acceptance criteria and edge cases?
- How should it behave in different scenarios?
- How does this integrate with existing functionality?

These detailed requirements aren't just helpful—they're essential. The more precise and comprehensive my "product brief" to the AI, the better the resulting code. I've learned that vague instructions lead to elegant solutions to the wrong problems, while clear requirements lead to exactly what I need.

## What This Means for Developers

For developers early in their careers, my advice is to focus on building solid engineering fundamentals alongside your product sense. You still need to recognize bad patterns when AI applies them, understand how to debug issues properly, and know when the code "smells" wrong. AI can generate code quickly, but you need the technical foundation to evaluate whether that code is maintainable, performant, and follows good practices.

For experienced developers, embrace the efficiency gains but double down on your strategic thinking. Use the time saved on implementation to better understand your users and market. To improve your efficiency, you must expand into more of a product perspective, or else your role might be not needed in the near future.

For organizations, recognize that while development speed has increased dramatically, the need for experienced technical leadership hasn't diminished—it's evolved into something more strategic and product-focused. This is especially critical for SaaS companies where rapid iteration and market validation are essential for success.

## Looking Forward

We're still in the early days of this transformation. AI tools will continue improving, and development will become even more efficient. But the fundamental skills of product thinking and strategic decision-making will only become more valuable.

This added efficiency creates new opportunities. When you can build SaaS products in days instead of weeks, the ROI calculation changes dramatically. Ideas that were previously too expensive or risky to pursue become viable. Prototypes that would have cost thousands can now be built for hundreds. This opens up entirely new categories of business models and makes validating SaaS concepts exponentially more affordable.

The future belongs to developers who can effectively orchestrate AI tools while maintaining a clear vision of what they're building and why. We're transitioning from being primarily implementers to being primarily strategists—and that's an exciting evolution.


Adam's Tech Blog

Replacing Onboarding Forms with an AI Conversational Agent

The Power of Plan Mode in Claude Code

Building Products with Specialized AI Agent Teams

The AI Coding Revolution Is Here