Vibe-coding a product from scratch:
a designer's experiment
without the canvas
Ripple is a personal habit tracking web app I built through AI-assisted development, turning a fragmented personal tracking system into a single, intentional product.
Overview
What is Ripple?
I track a lot about my life. Habits, workouts, finances, and a few things I'd rather not admit to, scattered across Google Sheets and a few more tools that were never quite built for me. Ripple is my attempt to fix that. But this case study isn't really about habit tracking. It's about what I learned when I sat down with an AI and built real software for the first time.
At some point the Google Sheets stopped being enough. Not because they broke, they still worked, but because I knew exactly what I wanted and nothing out there was it. So I built it. No code knowledge, no engineering background, just a very clear idea and an AI that kept up.
Process
Six steps from
idea to live
The process was messier than it looks here. The temptation to move fast was real. What kept it on track came down to three things: go slow, ask why, and never move past something I didn't understand.
Project Setup & Tech Stack
The first prompt was rough. The task was straightforward: help me pick the right technology for a web app that works on mobile and desktop. Claude recommended Next.js, Supabase, and Prisma, and more importantly, explained why each one made sense.
I made a choice early on that slowed everything down and made it better. Instead of letting AI execute autonomously, I followed every step myself, read every recommendation, and tried to understand every decision before moving to the next one. It wasn't the fastest way to build. It was the best way to learn.
Data Migration
The data didn't have a single home. Years of personal logs were spread across Google Sheets, Notion, Strava, and a couple of other tools, each structured differently and requiring a different approach to migrate. Some came over as CSV exports, others needed manual work before they were ready to import.
What made this step genuinely valuable wasn't the migration itself. It was the process of defining the schema. Working through the data model with AI turned into a real collaboration. Claude asked clarifying questions, flagged inconsistencies, and pushed me to think about how each decision would affect the product down the line. That exchange built a baseline strong enough to carry everything that came after.
Letting Go of the Canvas
I had always assumed I would design this in Figma. Rough wireframes first, then higher fidelity, then hand the specs to the AI to build. The usual process, just with a different collaborator at the end.
Claude had other ideas. Somewhere in the middle of the project it started generating UI. I watched it happen and made a decision on the spot: let it run, see where it lands, then redirect from there. I had some paper sketches from a while back and a general vision in my head. I fed those in as loose direction and let it continue.
What came out was clean, functional, and forgettable. No personality, no craft, no real point of view. And under the surface, real problems: contrast ratios that wouldn't pass basic accessibility standards, inconsistencies that only show up when you know what to look for. AI had made decisions a designer would never make. As a designer that was uncomfortable to sit with. But I made the call to leave it and focus on functionality first. Taking ownership of the UI was always the plan. Just not yet.
The part that stayed with me was Claude's unprompted design description: clean, athletic, data-forward. No input from me. And somehow it was closer to what I had imagined than I expected. That gap between what AI generates and what a designer would craft became the question I kept returning to for the rest of the project.
Dev & Demo Environments
Every local test was hitting the real database. Real data, real records, no separation. I flagged this and Claude suggested mirroring the database for development. A demo environment came next: a safe, sample-data space to share with colleagues without exposing real personal records.
Getting this in place while the project was still young mattered. Clean environment separation became something I relied on as things got more complex. What I didn't know at the time was whether it was the right solution at all. Since then, conversations with colleagues have made me question the architectural approach. I followed Claude's lead because I had no technical foundation to challenge it. It worked, but it's a clear example of the blind spots that come with building outside your domain. Trusting AI in unfamiliar territory is sometimes the only option. That doesn't make it the right one.
Moving to Claude Code
Up to this point every interaction had happened in Claude Chat. One session, one conversation, one growing thread that was starting to show its limits. As the project expanded, the chat window became unmanageable. File context was lost between sessions, uploads had to happen manually to keep things coherent, and the workflow was quietly breaking down.
The switch was to Claude Code, the Terminal-based version that gives the agent direct access to the project folder. The context problem was solved immediately. But switching environments came with a cost. The collaborative planning that had defined the Chat sessions, the back and forth, the questioning, the refining, didn't translate to the Terminal.The Terminal is powerful but it doesn't invite conversation. It executes.
The solution came from keeping both. Chat for thinking, planning, and refining the direction. Then, once the path was clear, asking Claude Chat to write the right prompt to hand off to Claude Code for execution. Planning in one place, building in another. It was the most important workflow discovery of the entire project.
Strava Integration & Goals Feature
Two features defined the MVP finish line: Strava integration and goals setting. Connecting to an app used daily for running and cycling meant workout data could flow in automatically, without manual imports. Goals setting added the ability to define targets per activity and track progress over time. Together, those two features closed the loop on what a first version needed to do.
Developing digital products means making peace with what it isn't yet. The UI was still entirely Claude's, full of inconsistencies and accessibility issues that a designer would never have signed off on. The path to get there was messier than this summary makes it sound. Bugs came up throughout the build. Some were resolved through back and forth with the AI, which rarely got complex implementations right on the first attempt. Others were left deliberately for a future version, a conscious decision rather than an oversight.
Design is the next chapter. The UI that Claude generated from the start was always a placeholder, functional but without craft or intention. Rather than patching it, the plan is to build a multi-brand design system from scratch, something that can give Ripple and future personal projects a coherent visual foundation. That work deserves its own process and its own case study.
Calling something an MVP means making peace with what it isn't yet. For designers that goes against years of training. Every unresolved inconsistency is visible. Every rough edge is felt. But a working product with known limitations beats a perfect product that never ships.
Workflow
The two-mode
method
The biggest process discovery of the project was learning to combine two different AI tools in a way that got the best out of both.
Claude Chat was for planning, direction-setting, and the kind of back and forth that good decisions require. Once a direction was clear, Claude Chat would write the precise prompt to pass to Claude Code, which worked with full project context through direct folder access and a CLAUDE.md file. No lost context, no repeated explanations.
Strategic thinking in one place. Precise execution in another. That combination was the workflow backbone for the rest of the project.
Key Learnings
What this project
actually taught
Go slow to stay in control
The temptation to let AI run ahead is constant. Resisting it is a skill. Short, clearly scoped tasks, understood before moving to the next one, are the difference between a project that grows and one that quietly gets away from you.
You are the director, not the passenger
AI can be a poor strategist. Product direction, feature prioritisation, and the reasoning behind every decision has to come from you. Delegating tasks is fine. Delegating direction is a mistake. When something feels off, challenge it. Blind trust is how projects lose their way.
Orchestrate your tools intentionally
Different AI tools have different strengths. Using them interchangeably produces mediocre results from both. Knowing which tool to reach for at which moment, and why, is its own skill worth developing early.
Plan thoroughly, then prompt precisely
AI is most powerful when the direction is already clear. The quality of the output is directly proportional to the quality of the thinking that came before it. Time spent planning is never wasted. Time spent correcting a misguided execution usually is.
Keep your designer eye switched on
AI generates interfaces that look reasonable on the surface and fall apart under scrutiny. Accessibility issues, inconsistent decisions, lack of craft. The tools have no taste, no lived experience of using a product under pressure. That judgment still belongs entirely to the designer.
Technical ignorance has a real cost
Not knowing the domain means not knowing which questions to ask or which decisions to challenge. Seek out people with more technical knowledge, involve them early, and never assume AI recommendations are architecturally sound just because they work in the moment.
Outcome
A real product,
shipped
Two weeks from first prompt to live deployment. No code knowledge. No Figma mockups. No agency. Just a clear goal, the right tools, and the discipline to stay in control of direction.
2 weeks
from first prompt to live.
7
activity types migrated from Google Sheets, Notion, Strava, and more.
Live
working product deployed in Vercel.
Reflection
What this means
for design
This project started as a personal experiment and ended up challenging assumptions I didn't know I was holding.
Claude generated a UI that looked fine and fell apart under a designer's eye. Contrast issues, inconsistencies, decisions made without context or intention. Functional, not considered. That difference is real, and closing it still requires a human who knows what good feels like.
The canvas is shifting. Figma moves earlier in the process, closer to thinking and discovery, further from production. The chat window becomes the place where design decisions land directly in code. The handoff between designer and developer, the rituals around specs and redlines and component documentation, those are already becoming relics of a workflow that no longer fits how products get built.
Figma doesn't disappear — it becomes the early-stage space for play, discovery, and establishing groundwork. The chat window with an AI agent becomes the new canvas where design decisions go directly to code.
Building is no longer expensive or gatekept. Anyone with a clear idea and the discipline to direct AI effectively can ship a real product. That changes what makes a designer valuable. Not the ability to produce polished deliverables, but the ability to know what to build, why it matters, and how to make it right for a person.
As design systems become commoditised and UI patterns become generated on demand, genuine creativity, original thinking, and the human understanding of what it feels like to use something will matter more than ever. That space is getting smaller in some directions and much larger in others.
The boundary between UI designer and front-end developer is dissolving. This project is one small piece of evidence for that. The next one, building a design system from scratch with AI, is another. The process is the point.
Next Step
The UI is still Claude's and that was always temporary. The next chapter is taking it back. A multi-brand, multi-project design system built from scratch, exploring what it means to vibe-code it and how handoffs evolve with these new ways of working. Ripple works. Now it needs to feel like it was made by a designer.
This case study will be updated to reflect that work in the coming weeks.