Building a real
product with zero
code knowledge
Ripple is a personal habit tracking web app that connects to Strava and replaces a decade of Google Sheets — built entirely through AI-assisted development by a product designer.
01 — Overview
What is Ripple?
For years, a growing collection of Google Sheets tracked habits, workouts, investments, and everything in between. The system worked — but it was brittle, impersonal, and never quite right. Ripple is the answer: a custom-built web app designed around one person's exact needs, built without writing a single line of code.
This is a case study about that build — but more than that, it's a reflection on what it means to be a designer when AI can take your rough idea and turn it into running software in minutes.
Full-width screenshot of the live Ripple dashboard. Ideally showing the main habit tracking view with data populated.
Role
Product Designer & sole builder — responsible for product direction, data architecture decisions, feature prioritisation, and UI.
Problem
Existing habit apps never fit personal needs. Spreadsheets offered flexibility but lacked automation, integrations, and a proper interface.
Solution
A custom habit tracking web app with Strava integration, goals setting, a demo environment, and dev/prod database separation — built via AI-assisted development.
Tech Stack
02 — Process
Six steps from
idea to live
No Figma. No technical background. Just a chat window, a clear goal, and the discipline to go slow and understand everything along the way.
Project Setup & Tech Stack
The first prompt wasn't perfect, but it got the ball rolling. Rather than over-preparing, the ask was simple: help me understand what technology to use, and let's build for mobile and desktop. Claude recommended Next.js, Supabase, and Prisma — and walked through every decision step by step.
One deliberate choice: follow the process manually rather than having AI execute everything autonomously. As a designer, understanding what's happening under the hood matters. It was slower. It was the right call.
Screenshot of the initial conversation with Claude about tech stack. Shows the back-and-forth that shaped the project foundation.
Data Migration from Google Sheets
All existing habit records lived in Google Sheets — seven different activity types, each with their own structure. Rather than building a live Google integration, the pragmatic approach was to export everything as CSV files and write a migration script to populate the Supabase database.
This step forced a careful look at the data model early. Every activity type required schema validation before import. It was methodical, time-consuming, and entirely necessary.
First UI — Letting Go of the Canvas
Here's where a decade of design instinct had to be set aside. Claude generated a full UI with no design direction provided — no Figma mockups, no style guide, no colour palette. Just code.
The result was clean, functional, and generic. A dark theme with warm accents. Monospaced numbers. Generous whitespace. It did the job. It had no personality. And the decision was made: leave it. Focus on functionality first. The UI can be owned later.
“Clean, athletic, data-forward. Think of a training log used by a serious amateur athlete — not a fitness app, not a SaaS dashboard.”
That was Claude's unprompted design direction. Zero input from the designer. It landed closer to the imagined layout than expected — which raised a question that wouldn't go away for the rest of the project.
Screenshot of the original Claude-generated interface. The “before” state — functional but generic.
Dev & Demo Environments
While testing locally, every interaction was hitting the real database — real data, real records. Claude suggested mirroring the database for a dev environment. A demo environment followed: a free-to-access version with sample data, safe to share with colleagues without exposing personal habits.
Setting this up while the project was still young paid dividends later. As the codebase grew, having clean environment separation was a relief, not a retrofit.
Screenshot or diagram showing the dev / demo / prod environment structure, or the demo version of the app.
Moving to Claude Code
As the project grew, the chat window became unmanageable. Claude lacked file context between sessions. Files had to be uploaded manually to keep conversations coherent. The workflow was breaking down.
The switch to Claude Code — giving the agent direct access to the project folder — solved the context problem. But it introduced a new one: the back-and-forth planning that made the Chat sessions valuable was gone.
The solution became the most important workflow discovery of the entire project.
Screenshot of Claude Code in the terminal, or the CLAUDE.md context file that was built to bridge Chat and Code sessions.
Strava Integration & Goals Feature
The first data source was manual CSV imports. The first live integration was Strava — an app used daily for running and cycling. Automating the pull of workout data into Ripple was the moment the product stopped feeling like a prototype.
Goals setting followed as the final MVP feature: the ability to set targets per activity and track progress over time. With that shipped, Ripple had everything it needed to be a real, daily-use product.
Screenshot showing the Strava-connected activity data or the goals tracking feature. Ideally with real data visible.
03 — Workflow
The two-mode
method
The biggest process discovery wasn't a technical one. It was figuring out how to combine two different AI tools to get the best of both: strategic thinking with full file context.
Plan
Claude Chat
Direction set
Write prompt
Execute
Claude Code
Review
Test & iterate
Next feature
Back to Chat
Claude Chat handled planning, direction-setting, and the back-and-forth needed to make good decisions. Once a direction was clear, Claude Chat would write the precise prompt to hand to Claude Code — which had full project context through the CLAUDE.md file and direct folder access.
The near-miss with the demo environment was a reminder that the agent is powerful and fast — which means a sloppy instruction can cause real damage in a growing codebase. Staying in control of direction isn't optional. It's the job.
04 — Key Learnings
What this project
actually taught
Go slow to go fast
The temptation to let AI run ahead is constant. The better approach: short, clear tasks. Understand each step before moving to the next. A growing project can be derailed quickly when context is lost.
You are the director, not the passenger
AI is an exceptional executor but a poor strategist. Product direction, feature prioritisation, and the “why” behind every decision has to come from the builder. Delegating tasks is fine. Delegating direction is a mistake.
Ask why, always
Every technical recommendation from the agent came with a follow-up question: why this approach? Why this tool? Understanding the reasoning builds context, catches mistakes early, and makes you a better collaborator.
Plan before the chat window opens
The best sessions started with a clear goal. The worst started with vague exploration. AI is not a good brainstorming partner for direction — it's brilliant for execution once the direction is set.
Watch the agent closely
The demo environment build nearly went wrong. The agent's recommendation was sloppy, and catching it early prevented a painful rollback. In a large codebase, unchecked agent actions compound fast.
Set up infrastructure early
Dev and demo environments, the CLAUDE.md context file, environment separation — all of these felt like overhead at the time. All of them paid back double as the project scaled.
05 — 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 wks
From first prompt to live product on Vercel
7+
Activity types migrated from Google Sheets
Live
Daily use, Strava connected, goals tracking active
2–3 key screens of the live Ripple app. Ideally showing desktop + mobile views, or the main views: dashboard, activity detail, and goals. Use real data if possible.
06 — Reflection
What this means
for design
Claude generated a decent UI in seconds with zero design input. That fact sits differently depending on how you look at it.
It's impressive. It's useful. And it's missing something. The human craft — the intentionality, the detail, the decisions that make an interface feel like it was made for a person — that isn't there yet. The AI built a functional interface. It didn't build a considered one.
But the more interesting question isn't whether AI can replace designers. It's how the design process itself is changing.
The canvas of the designer is shifting. 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.
This project didn't prove that AI can replace designers. It proved that designers who learn to direct AI effectively can build things they never could before — and that the skill of knowing what to build, why to build it, and how to make it right for a person, remains entirely human.
Side-by-side comparison: the old Google Sheets habit tracker on the left, the Ripple app on the right. Tells the story of the transformation without words.
Next Steps
The UI is still Claude's. The next chapter is taking it back — building a personal design system, applying craft and intention to every component, and turning Ripple from a functional product into a considered one. That work starts in Figma. It ends in code. Just like it always did.