How I Built My First Mobile App Using Claude Code

As someone who owns both a car and a motorcycle, keeping track of preventive maintenance has always been more annoying than it should be. Oil changes, brake servicing, tire replacements, coolant flushes, and all the other maintenance schedules were scattered across reminders, notes, and my memory. Every time I wondered, "When did I last change the engine oil?" I found myself digging through old receipts or guessing.

I wanted something simple. An app where I could manage both vehicles in one place without creating an account, relying on cloud storage, or needing an internet connection. So last Sunday, July 5, I turned this idea into reality with the help of AI, and it became MotoCar PMS.

 

 

Instead of opening VS Code immediately, I started with ChatGPT. Rather than asking it to generate code, I asked it to interview me about the app I wanted to build. We discussed who the app was for, what problems it should solve, what features belonged in an MVP, and what success would look like for the first release.
 
That conversation eventually became a Product Requirements Document (PRD). Looking back, it was probably the most valuable part of the entire project because every design decision and every line of code that followed came from that document.
 
Once the requirements were finalized, I moved on to the design. I used Google Stitch to generate the initial UI, branding colors, logo, and screen layouts. It also produced a design specification that documented the color palette, typography, and reusable components. Having an actual design system instead of vague descriptions made it much easier for Claude to understand exactly what I wanted.
 
Next came the actual "vibe coding" part. I launched VS Code, installed the Claude Code extension, and opened the integrated terminal. That terminal became my whole workspace for the next stretch of the project.
 
Although Claude's Fable 5 model had just been released a few days earlier, I decided to use Opus 4.8 instead. Fable 5 consumes usage limits much faster, and I wanted enough headroom to finish the entire MVP without worrying about running out of context window midway through development.
 
Before asking Claude to write anything, I placed it in planning mode. I gave it both the PRD and the design markdown file, then instructed it to ask me clarifying questions before generating code. That turned out to be a great decision because Claude identified several assumptions I hadn't documented. Answering those questions resulted in a much more detailed implementation plan and prevented several issues before development even started.
 
Only after we agreed on the plan did I switch Claude into Auto mode. From there, Claude handled most of the heavy lifting. It created project structures, installed dependencies, configured navigation, implemented local storage, built screens, and connected everything together. I also kept the Superpowers and Ponytail plugins enabled to help maintain a clean and practical codebase without unnecessary complexity. I trusted the setup was configured correctly and let it run.

 

This is the part that still feels a little surreal: I left the laptop on, Claude working through its task list, and went outside for the rest of the day. Since Claude Code supports remote sessions, I could check the build from my phone whenever I wanted. It felt less like programming and more like supervising a teammate.

Once the app was in a working state, I compiled it with Expo EAS Build to produce an Android APK. It wasn't perfect on the first attempt. I went through two preview builds, testing, fixing small issues, and making adjustments until the app finally felt ready for an MVP.
 
If you want to try it yourself, here's the android build:
https://expo.dev/accounts/bluelime88/projects/MotoCarPMS/builds/dfde474d-4c89-4ab5-8593-912bd8d4ebee

I'd genuinely appreciate your feedback. Every suggestion will help improve future versions.

MotoCar PMS supports multiple vehicle profiles for both cars and motorcycles, complete with maintenance health indicators showing whether each vehicle is healthy, due soon, or overdue.
 
Service records include maintenance history, labor and parts costs, receipt attachments, service photos, and full-screen image viewing.
 
The reminders screen tracks upcoming maintenance based on due dates, mileage, or both, while the analytics dashboard summarizes yearly expenses, monthly spending trends, maintenance categories, and the highest maintenance costs per vehicle.
 
The app also includes CSV export, dark mode, configurable currency and distance units, and everything is stored locally on the device. No account registration, backend server, or internet connection is required.
 
Under the hood, it's built with Expo SDK 54, React Native 0.81, TypeScript, and Material Design 3.
 
The full codebase is also on GitHub: https://github.com/bluelime88/MotoCarPMS.git

This project reminded me how capable AI is becoming over time. It's changing how we build software.

The biggest challenge was never writing code. It was thinking clearly about the problem, making good product decisions, and communicating those decisions effectively to an AI that could turn them into working software.

That's probably the biggest lesson I learned from building MotoCar PMS. The next step is finishing the iOS version. Once it's available and hopefully sitting in the Apple App Store, I'll come back and update this post with the details.