In March 2026, I opened Xcode on a Saturday afternoon with zero expectations. I had an idea for a personal finance app — something I wanted for myself. No grand plan. No product roadmap. Just a designer who was tired of budgeting apps that felt like spreadsheets wearing makeup.
Two months later, Fisor was live on the Google Play Store.
I’m not writing this to teach you how to code with AI. There are plenty of tutorials for that. I’m writing this because what happened in those two months changed how I think about building things — and I think it will change how you think about it too
It started as a weekend experiment
I've been a product designer for over three years. I've shipped nine products. I know how to think in user flows, design systems, and edge cases. What I didn't know was how to turn a Figma file into a working app by myself.
So I did what everyone does in 2026 — I asked ChatGPT.
I described what I wanted: a clean, minimal finance tracker. Something that lets you log expenses fast, see where your money goes, and doesn't require a finance degree to understand. ChatGPT walked me through setting up a project in Xcode, gave me SwiftUI code, and helped me debug errors I couldn't parse.
And it worked. I had a functioning app on my phone within a few days.
Here's the catch: it only lasted seven days.
Apple's free provisioning profile expires after a week. Every seven days, I had to reconnect my phone, rebuild the project in Xcode, and reinstall the app. The data persisted, but the ritual got old fast. I was maintaining a personal app like it was a deployment pipeline.
Still — those seven days proved the concept. The app was useful. I was actually using it every day. That's when the thought crept in: if I need this, other people probably do too.
Finding Claude Code
Around the same time, I came across Claude Code — Anthropic's CLI tool for working with code directly in the terminal. I'd been using ChatGPT through the chat interface, copying and pasting code back and forth between the browser and my editor. It worked, but it was like writing an email to your coworker who sits three desks away.
Claude Code was different. It lives in your terminal. It reads your files, understands your project structure, and makes edits directly. No copy-pasting. No context window gymnastics. You describe what you want, and it writes the code where it needs to go.
I switched my approach. Instead of building for iOS with Xcode (and dealing with the seven-day reinstall cycle), I decided to rebuild Fisor for Android using Android Studio — targeting the Play Store from day one.
The combination of Claude Code + Android Studio became my workflow. I'd describe a feature in plain language, Claude would write the Kotlin code, I'd review it, test it on my device, and move on. When something broke, I'd paste the error, and Claude would trace the issue and fix it.
Was the code perfect? No. Did I have to learn enough about Android development to make judgment calls? Yes. But Claude handled the heavy lifting — the syntax, the boilerplate, the API integrations, the stuff that would have taken me weeks to learn from scratch.
What makes Claude Code good at this
Most people install Claude Code, type a prompt, and hope for the best. That works for simple stuff. But if you're building an actual app, your setup matters more than your prompts.
Here's what I learned after two months of daily use:
Set up a CLAUDE.md file first. This is a Markdown file you place in your project root that Claude Code reads automatically. Think of it as a briefing document. I used mine to describe the app's architecture, the folder structure, naming conventions, and design rules I wanted followed. Without it, Claude makes reasonable guesses. With it, Claude makes your choices.
Mine included things like:
- "This is a Kotlin Android app using Jetpack Compose"
- "All screens follow MVVM pattern"
- "Use Material 3 components"- "Color palette: [specific hex values]."
Every session started with Claude already knowing the project. No re-explaining.
Work in layers, not in leaps. Don't ask for a complete feature in one prompt. Start with the structure ("create the expense detail screen with a back button and a list of transaction fields"), review it, then refine ("add a date picker for the transaction date," "animate the save button on tap"). Each layer builds on reviewed, working code. Big prompts produce big messes.
Give it errors, not explanations. When something breaks, paste the full error log. Don't try to interpret it first. Claude Code reads stack traces better than most developers. I'd paste a build error, and it would trace the issue across three files and fix all of them. Let the tool do what it's good at.
Use the /compact command regularly. Long sessions eat up context. When you've been working for a while and responses start feeling less precise, run /compact to summarize the conversation and free up space. I did this roughly every 30-40 prompts.
Review before you move on. This is the discipline that separates a shipped app from a broken prototype. After Claude makes changes, read the diff. Understand what changed and why. If something looks off, ask Claude to explain its reasoning. The five minutes you spend reviewing saves you an hour of debugging later.
Let Claude handle the boring parts. Boilerplate, data classes, Room database setup, navigation graphs — this is where AI saves real time. I stopped spending energy on repetitive code and redirected that energy toward the parts only I could decide: how the app should feel, what interactions matter, and what to cut.
The setup is half the work. Get it right, and Claude Code stops being a chatbot and starts being a build tool.
Before you hit publish: security and safety
This is the part most vibe coding guides skip, and it matters.
When you're building with AI-generated code, you're trusting that the AI made reasonable security decisions. Sometimes it does. Sometimes it doesn't. Before I submitted Fisor to the Play Store, I went through a few checks:
Data storage
Where is user financial data stored? Is it on-device only, or does it touch a server? I made sure Fisor keeps everything local — no cloud sync, no analytics that leak spending data. If your app handles sensitive information, know exactly where it lives.
Dependencies
AI-generated code sometimes pulls in libraries you've never heard of. I audited every dependency in the project. If I couldn't understand why it was there, I removed it.
Permissions
Android apps request permissions, and AI-generated code can be overly broad. I reviewed the manifest and stripped out anything Fisor didn't need. A budget app doesn't need access to your camera or contacts.
Input validation
Even for a local app, I checked that user inputs were handled safely — no crashes from unexpected characters, no issues with large numbers, no edge cases around empty states.
Play Store policies
Google has specific requirements around privacy policies, data safety declarations, and content ratings. AI won't fill those out for you. I read the policies, wrote a privacy policy, and completed the data safety form manually.
This isn't optional. If you're putting something on a public store, you're responsible for what it does on someone's phone.
Is this the future? Will no one code?
No. People will still code.
I know i don't know much about the code (Just learned in college, where I felt this is not for me) What's changing is who gets to build things. Five years ago, if I wanted to turn my app idea into reality, I had two options: learn software development (months to years) or hire a developer (thousands of dollars). Now there's a third option: describe what you want and collaborate with AI to build it.
But "vibe coding" has limits. AI is good at generating code for well-understood patterns — CRUD apps, standard UI components, common integrations. It struggles with novel architectures, complex state management, and performance optimization at scale. The further you get from boilerplate, the more you need to actually understand what's happening.
I also found that my design background was an unexpected advantage. I wasn't just asking AI to "make an app." I was giving it specific interaction patterns, clear user flows, and detailed UI specifications. The better your input, the better the output. Domain expertise doesn't become less valuable — it becomes the differentiator. Now imagine same app created by Developer or Sales person or any other professional from different domain. Outcome will be different.
Professional developers aren't going anywhere. But the barrier between "I have an idea" and "I have a working prototype" just got a lot shorter. That's meaningful.
How to actually benefit from AI
After two months of building with AI tools daily, here's what I'd tell anyone starting:
Use AI as a collaborator, not a replacement for thinking.
The moment you stop understanding what the code does, you've lost control of your project. You don't need to write every line, but you need to understand every decision.
Pick the right tool for the stage.
ChatGPT was great for early exploration — "how does SwiftUI navigation work?" — when I was learning concepts. Claude Code was better for actual building — "add this feature to my existing project." Different tools, different strengths.
Invest time in review.
AI-generated code is a first draft. Treat it like one. Read it, test it, question it. The time you save on writing code should be partially reinvested in reviewing it.
Ship something.
The biggest advantage AI gives you isn't speed — it's the ability to cross the finish line. Ideas are free. Shipped products are rare. If AI helps you get from idea to app store, that's the real value.
Fisor started as a weekend experiment on my phone. It's now a real app that real people can download. I designed every screen, but I didn't write most of the code. And I think that's fine. The app works. Users get value from it. That's what matters.
The tools are here. The question isn't whether AI can help you build — it's whether you have something worth building.