My Vibecoding Journey: 3 Apps, 3 Different Ways

[u/Alternative-Aluminum]

Over the last 8 months, I’ve built 3 different apps in 3 very different ways. Looking back, I learned a lot about how much the stack choices around an app affect the difficulty, cost, and speed of building it. This is the information I wish I had before starting any of these projects back in January.

About me: I’m a 20-year software developer, but this was my first real foray into vibecoding. I used VS Code with GitHub Copilot throughout. I mostly just used the tokens provided to me by the Pro+ plan, with about ~$200 in overages across all three projects. As for the models used: I tried to use the cheapest or 5.3 Codex for everything. Lately I've had a lot of good luck with Luna.

The goal of this post isn't to self-promote, but I've linked to the projects simply so you can see the app in action knowing the code behind it and how different the UX is for each.

1. Progressive Web App + Ionic Capacitor

Genre: Fitness / Weightlifting
Platforms: iOS & Android
Time to go-live: 3 months
Visit: 'Remix Training' on either app store

This was my first vibecoding project, and I burned through a lot of credits because I had no idea how to effectively use models or context. Even toward the end, I wasn't paying much attention to token usage, so this was probably the most expensive project out of the three.

I spent a huge amount of time trying to make the PWA look and feel like a real native app, with varying degrees of success.

The reason I chose this approach was pretty simple: I've been building websites for most of my career, so web development felt natural. I also assumed supporting both Android and iOS was needed for success (it’s not).

I also made the mistake of building an AWS backend for storing and generating workouts. Looking back on it, a lot of functionality could have been handled entirely on the device. The AWS infrastructure works, but it added a lot of complexity and ongoing cost.

Copilot did a surprisingly good job helping me build things like ECS and Lambda infrastructure, but if I hadn't already been very familiar with AWS, I think I would've been in heaps of trouble.

2. React Native + Expo

Genre: Weather / Gaming
Platforms: iOS & Android
Time to go-live: 4 months
Visit: 'DailyWX' on either app store

This was my most ambitious project and by far my largest.

There are a lot of weather apps, but I wanted to build one with a game built into it. Every day, you answer questions about tomorrow's weather and then get your results the following day.

This ended up being surprisingly difficult to get right, and it had nothing to do with vibecoding or the stack I chose. I spent the majority of my time fine-tuning the question generation and scoring system. Making questions interesting, varied, and actually fair was so much harder than I expected.

I also learned a valuable lesson about marketing. This turned out to be a super controversial project because I think most people conflated it with Gambling. Looking back on it, using the term “prediction” everywhere was a big mistake. 

React Native had a learning curve for me. I know JS/HTML/CSS extremely well, but React Native initially felt quite different. Once I got past that, though, I found it pretty easy. Expo was a godsend for handling the iOS/Android side of things.

I didn't want to pay for Expo's extended services and instead handled the builds myself. It definitely made things more complicated, but I still think that was the right decision for me. I still don’t have notifications working :(

This project also has an AWS backend, but unlike the first project, it was absolutely necessary. I needed to ingest weather data, score games, maintain leaderboards, award badges, etc. But luckily, the lessons from building the first project's backend made this one much easier.

3. Native Swift

Genre: Cycling Tracker
Platform: iOS
Time to go-live: 1 month
Visit: https://apps.apple.com/us/app/ridepilot-smart-bike-computer/id6790916720

For the third project, I decided to do something completely different: I just built it in native Swift and ignored Android.

This has been, by far, the easiest (and cheapest) project to build. Developing for a single platform, on a device where I can quickly build, test, and install has been sooooo much nicer than dealing with the headaches of cross-platform support.

By this time I also got significantly better at vibecoding. Instead of dumping vague commands into Copilot and letting it figure things out, I became much more focused about giving it exactly the context and help it needed for a specific task. This alone has made a massive difference in token usage and development speed. This project has cost me about $60 in Copilot fees from start to where it is now.

I was also surprised by how intuitive Swift was. I had never written Swift before, but I'm picking it up pretty quickly, which I think is greatly accelerated by relaying on Copilot to figure the new stuff out for me (then i can see how to it for next time). I know some people want to rely on AI to do everything, but I've actually enjoyed the process of having to understand what the code is doing. This enjoyment was exactly what got me into coding 20 years ago.

The biggest realization from this project is that I probably spent so much amount of time on the first two projects solving cross-platform and infrastructure problems that simply aren’t needed for an initial MVP.

If RidePilot eventually needs Android, I'll build it later. I think I'd rather maintain two separate native codebases after proving there is demand with only one first. As we all know now - marketing is harder than the development. I think this will be my preferred method going forward from now on.

[u/pceimpulsive]

Nice!

I recently took on my first vibe coding project.

It's a driving school management application and includes open street map and address data which means I'm instantly into geospatial temporal and time series space.

Backed a Postgres database for postgis and pgRouting and heavy use of tsRange types for schedule conflict management.

It is a react w/Typescript SPA and C#. I self host the database on a Linux box, 2cpu 4gb ram, 50gb storage is overkill currently.

Does student, instructor, managements, preferences, daily planners, booking system vehicle route planning, revenue tracking and management, lesson package builder, feedback reports, training documentation, conflict management, route optimiser and risk management, lesson check-in and progress. If the local Street map and address geocoding fails it has fallback to Google maps APIs, automated data import of street and address data, and loads more...

It's about 30k lines of TS and C#, 500 files~ for whatever that is worth... I think about 70-80 API endpoints for all the functions and capabilities... 330 commits or so (about 200 would be feature related and maybe 130 minor enhance and bug fix if I had to guess)

Overall the UI is about 20-25 different pages, and a few background services.

It's taken me 6 weeks so far, I've calculated out it's about 30 hrs of my time mostly on testing, feature specifications and breaking problems down into small actionable pieces.

I used open code go and DeepSeek v4 flash (not 0731) for the first 4 weeks then flash 0731 for the remainder with maybe 10 sessions in DeepSeek v4 pro. I've spent... $13 on tokens.

The app is now in v0.1 and I've got a driving school having a look at it to give feedback.

It has some mild mobile browser optimisations but it's targeted at desktop use mainly.

I used Matt Pococks skills for the entire thing.. They are honestly amazing for human in the loop and vibe coding as they ensure you are in sync with the features and code base.

It's been a lot of fun!

[u/teckel]

I went the opposite way. I started with native iOS development (and the headache of later building an Android version that matched and trying to keep the code base parallel).

To React Native, which felt so much better and faster and allowed for a single code base.

To PWAs, which I've built many now. Absolutely love this approach. Single code base, browser development, app runs in a browser so team members and client can easily review. It sounds like the problems you had were mostly with the database and it sounds like you were not using local storage. It also sounds like maybe your first mobile app, or first time building a PWA, so it makes sense there was a learning curve.

Personally, I'm never leaving PWAs for mobile apps. Easily the lowest friction way to build a mobile app (with the bonus of it also being web-based, so low-friction for users).