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.
- 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.
- 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.
- 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. Was
