I couldn't find anyone to build my dream app. So I vibe coded it myself.

A few people have asked me two questions lately: how did you learn to vibe code something as complex as AusBUG? and what does your workflow actually look like? So here's the honest version of both.

First, some credentials for the sceptics: I have no tech background. I work full time in a completely unrelated field. And today I run a cycling app — native iOS, Android, and a web platform — with over 900 registered users (roughly 60 on it daily), a loose partnership with Bicycle Network, the occasional meeting with the Department of Transport and Planning, and a growing community of Melbourne riders who message me bugs and feature ideas every week. I built all of it myself, 100% with AI, mostly on weekends and either side of my day job.

Here's how that happened.

Part 1: How I got here

The expensive way to learn you should do it yourself

Four or five years ago I created a website called Bike Routes. I paid an Australian web developer about $5,000 to build it. He told me it would take about a month. It took six — he outsourced everything offshore and did an okay-ish job.

A few years down the track I decided to rebuild. I planned to source the dev online and found a guy — he quoted about the same ($5k), asked for half up-front, did some work, and then stalled. And stalled. And stalled some more. A host of excuses later, I realised I would not be getting my rebuild. I persisted, and I finally found a genuinely lovely, smart developer who rebuilt Bike Routes properly for about $3,000 — a great experience, no complaints.

But then I wanted to build something new, something I was really excited about, something that would take Bike Routes to the next level — an interactive gravel riding map. Unfortunately for my nice dev guy, it was beyond him; he was a WordPress guy, and mapping was another world. It seriously was: I couldn't find anyone, anywhere, who wanted to touch mapping. One guy quoted $20,000 and others were around the same. Eventually I found someone who said he could build it for around $5,000, and he made a start. It was actually pretty exciting — he showed me his progress and it looked good. Unfortunately he never made it past the Figma stage, and many excuses later, I realised he probably didn't know how to build it in the first place. I went through the Upwork appeal process and got maybe 50% of my money back, despite clear evidence of the conversations and the lack of delivery. You see, Upwork wants their money too — it's more of a buyer-beware system than you realise.

It's not really the money that bothered me, to be honest. I went in knowing that being ripped off was a real possibility (though I can't say I was fully aware of just how dodgy the platform could be). Needless to say, I'd had enough. The crux was: I could not find anyone to build my dream app.

It is a genuine minefield out there if you want to build anything complex, or you're coming from very little experience — development just didn't seem accessible to people outside the industry.

Now I'd argue vibe coding it yourself is little risk, more fun, and probably a lot cheaper — at the very least to get a concept off the ground. And that's the idea, isn't it? I mean, if you want a SaaS model making you thousands a week from something you vibe coded in a month with no experience — look mate, it's just not going to happen. Vibe coding is a grind, not a get-rich-quick scheme. Use it first to prove concepts, then to help you pivot to the right approach. Then you can start building.

ChatGPT had just arrived. And I remember thinking: stuff this. I'm going to build it myself, by trial and error, even if it takes me all the time in the world. One day at a time. One prompt at a time.

That was about two years ago.

“Hannah! Look! A bloody map!”

I want to be clear about my starting point. As a teenager I built fan websites for games like SimCity (nerd alert). I picked up some HTML and actually got pretty good at it. It's funny what you can teach yourself when your mind is still young and malleable and you have the time.

Ever since, I'd wanted to learn to code. I tried all the online courses, bought the books, tried to build a Pinterest replica in Ruby on Rails. Man, I just sucked. I couldn't get it. I don't know — maybe I just don't have the mind for it. Maybe my ADHD-riddled mental processes just can't take on that type of thing. I'd always thought I was pretty good at picking up new languages, but coding wasn't one of them. To be honest, it was a real source of frustration, because the desire to build has always been strong with me. Hence the SimCity addiction — I played it right up until the day I started vibe coding, and isn't it funny: I've barely played it since. Vibe coding replaced the creative outlet I'd been yearning for.

Looking back, I don't actually think coding knowledge would have significantly helped me. In fact, I think it might have done the opposite. I strongly believe that because I wasn't traditionally trained in coding or development, my workflow has taken on a no-nonsense, pragmatic approach that just seems to work. Look, I'm sure there are things I would have benefited from knowing — but whatever. The moral is, all I really needed was some computer competency and the confidence to begin. That's it.

I started by asking ChatGPT everything. Where do I begin? What tools do I need? What even is this? It pointed me to VS Code, and my first goal was gloriously simple: show a map on a screen. It led me to Mapbox, and it took me a full day of setting up API keys and copy-pasting code back and forth before it worked. I learnt about localhost and .env files. Seriously, the learning curve was ridiculously efficient.

After one day — POP — a map. On my screen. That I made. I must have refreshed the page a thousand times that day, and on the 1,001st refresh: a map. A beautiful map of Australia.

I yelled out to my partner: “Hannah! Look! A bloody map!” I could not believe what I had done. What seems laughably simple to me now was the moment everything clicked: this was actually possible. If I just followed one prompt after the other, I could build — who knows! Anything!

ChatGPT taught me about GitHub and version control. It steered me towards Vercel and Next.js. Eventually we even touched on architecture and how to keep the codebase clean (which we ignored, of course).

The copy-paste era (and the keyboard I punched in half)

The early workflow was rough. The AI couldn't touch my code — everything was copy and paste. I'd leave marker comments in my files so I knew where to paste blocks in and out. I'd paste an entire page of code into the chat and ask the AI to retype the whole thing with the change. It was slow, it was error-prone, and the models were genuinely limited — there were features I simply could not build no matter what I tried. I struggled with servers. I struggled with everything. To roll out a new feature, I'd be looking at a day to a week of copy-pasting, plus tantrums.

One day I got so frustrated with the model that I punched my keyboard in half. I remember the late nights. The endorphins from landing a new feature were so strong that if you couldn't get a win that day, it was the equivalent of coming down off cocaine or something. Toddler-style tantrums ensued when I couldn't get what I wanted to work. ChatGPT accepted my expletives with open arms and always apologised.

But here's the thing — despite the time, despite the poor workflow: it was cheap, and it was working. I was producing more than I could ever have dreamed of. Hours and hours of trial and error later, I had a map where you could draw routes and add photos. Ugly, but real. I put it out to my Instagram followers. Some interest — but it was extremely niche. A tool I wanted, that maybe not many others did.

Lesson one, learned early: the building was the easy part to fall in love with. Building the right thing takes a few attempts. And how lucky! How lucky! Imagine if I'd spent $20,000 on a concept nobody cared about. THIS! This is the point. Most of your ideas are bad ones — but they often lead into other things.

Getting drunk on vibe coding

The models improved fast, and my tooling improved with them. I moved to VS Code with the Claude extension built in, and it changed everything — the AI could finally edit my code in real time. No more copy-paste.

It was also expensive. In those days I was burning up to $100 a day in API tokens, sometimes more. I was properly drunk on vibe coding. I loved it, and I always needed the next feature.

I was building CYA Routes by then — my old Bike Routes site reborn with built-in mapping, bikepacking features, adventure cycling routes. Big plans, big ideas. Embeddable maps that cycling organisations could put on their own websites. I was certain people would love it! Nobody cared. I launched, and it failed quietly. I was certain people would come. They didn't.

Along the way, though, my stack was quietly settling through pure trial and error: I'd tried MongoDB in the early days (slow, for me), tried Supabase (didn't click), landed on Firebase. Sampled MapTiler and Google Maps, stayed with Mapbox. Got comfortable with Next.js and Vercel. Nobody taught me any of this. I just kept building and kept whatever felt fast and looked good.

So I pivoted: I'd make an app. Routes in your pocket. I started vibe coding for iOS — and hit the hardest wall of the whole journey. I was building cross-platform, “whatever works for both,” and it was a nightmare. Packages that wouldn't install, builds that wouldn't run. I spent a week just trying to get a test version running on my own computer. At one point I was convinced I'd lost my entire codebase, started rebuilding from scratch, and then found it all again — git and version-control habits are things I learned through pain, not tutorials. I nearly gave up. I actually took a break for a while when I couldn't get mobile working; it didn't seem to matter what I did. Back in those days I'm not sure the AI always gave the right advice — I feel like it's improved a lot now — but at no point did it ever tell me to give up on cross-platform and go native.

The pivot that worked

Then something clicked, and it wasn't technical. I was building too niche. Adventure cycling and bikepacking is a tiny market. Commuters and bike path riders? Much bigger. (Also, my partner was pregnant with our first child — I wasn't going to be doing much adventuring for a while anyway.)

The CYA Routes app was finished and sitting in App Store review. I'd navigated that whole nightmare. And right before I pushed the launch button — I stopped. It wasn't going to work. I'd take everything I'd learned and start something brand new.

By this point I'd switched to Claude Code, and my workflow exploded. I was also using it to bounce ideas around, not just write code — and out of those conversations came the concept: an app for Melbourne's commuters and bike path riders, integrated with the local Bicycle User Groups. VicBUG.

This time I built native iOS first, because I'd learned that lesson the hard way. And this time the rebuild was fast — V1 didn't take long at all, because two years of accumulated scar tissue meant I knew exactly what worked.

I launched. And people actually cared. It didn't blow up, but it hit 30 users quickly and people started messaging me about it. Faith from Merri-bek BUG — a wonderful Melbourne cycling advocate — invited me onto 3CR community radio's cycling show. More people noticed. The web version came together alongside iOS. My workflow was so fast by now that I managed to build Android over a three-or-four-week holiday break (the Play Store was its own nightmare, but a surprising number of people ride with Android phones), and it immediately added to my user base.

Around nine months on from launching the iOS app: over 900 users have created an account, a Bicycle Network partnership, meetings with DTP, and five or so dedicated users who lovingly flood me with bug reports.

The economics changed too, and I want to be honest about them, because “vibe coding is cheap” is only half true. I have spent thousands on this over two years. Absolute thousands — especially in the pay-per-token days, when $100 could vanish in an afternoon. But when Claude Code moved to subscriptions the bleeding stopped: now it's about $300 a month for AI and $400–500 for hosting, servers, Google APIs and the rest. No more spending guilt. Still thousands a year, sure — but per feature actually shipped, it's not even in the same universe as what you might pay developers.

And the time? Here's the honest part: weekends, before work, after work. Hours and hours and hours — probably the equivalent of 40 hours a week on top of a full-time job. I know that sounds insane. But it's my stress relief. Maybe it pays off one day, maybe it doesn't. I'll never stop building. I don't care — and every chance I get, I'm on Claude Code typing away.

Just as a side note

I don't want this to be seen as a success story — I mean, it's really not. I'm paying to keep this running, so financially, effectively — right now — this is not a working concept. From my own point of view, I'm creating something and people are finding value in it. That's a personal success.

I think the point proven here, though, is that we have the beginnings of a concept that could work — perhaps through a major paying sponsor or a partnership with someone. I'm not prepared to charge money for the app or charge people subscriptions, because that kind of defeats the whole concept. But with nothing but AI at my side, I feel it's extremely achievable for someone with no experience to get deep into a proof of concept without having to spend thousands and thousands on developers or Upwork rolls of the dice. And it's much easier to pivot along the way.

Part 2: What my workflow actually looks like

Everyone expects this section to be full of frameworks and agent architectures. It isn't. My entire philosophy is: stop overthinking and just build it. That's the advantage of AI, right? You aren't paying anyone just to test ideas on — you can test them yourself at no extra charge.

Just build. There are engineer-types who want to plan, plan, plan — tiered workflows, MCP this, agents that. I'd rather just ignore the noise, open up Claude Code and build. Don't get bogged down in YouTube tutorials about “the perfect AI coding setup” — I never watched any. Ask the AI itself what to do; that's the entire trick. Sometimes it's wrong, but you learn to smell when it's wrong. Put in the time. That's all there is.

Here's my actual setup, and it'll probably horrify real developers: I never have fewer than three terminal tabs running, usually five — say three Claude Code and two Codex, because any model can be slow or having a bad day. One tab might be on an iOS feature. One might be porting a finished feature from iOS to Android (iOS is my gold standard; Android gets the port). One might be the website, one might be researching ideas, one might be on another project entirely. I flick between them one at a time — when a tab finishes, I test it, look at it, move to the next. A one-man feature factory. This keeps me fully plugged in with no time for distraction while Claude works away. As one tab works on a feature, I flick to the next and see where it's at. I love this setup — I just get so much more done working multiple tabs at a time.

Anatomy of a feature: the search bar

Here's a real feature I implemented, start to finish. A user emailed me: searching for a location isn't obvious in the app — it should be a quick search bar at the top, like Google. That email is the most valuable thing a user can give you. A genuine pain point, and most people will never bother telling you.

My first step wasn't code. I went and looked at similar apps that do UI really well — Google, plus the apps that have invested heavily in UI: AllTrails, Ride with GPS, Strava. I do this constantly, because mate, I'm a concreter — how on earth am I going to know good UI? I don't have to. Someone already spent millions figuring it out.

So I screenshotted Google's search bar, pasted it into Claude Code along with the user's actual email, and said: I like this. Let's do it. Make it look something like this. Once it worked, I asked for the personal touches — a find-my-current-location button, pan to the user's home if they've set one. Then I fiddled with the styling, which is genuinely the fun part. Once I liked the look and functionality, I ported it over to Android and asked Claude to commit it.

Meanwhile the other tabs had been chewing through bug fixes, so I pushed the lot together, had Claude bump the version numbers of the apps, and uploaded to both stores. Apple goes live around 10–11am California time on business days; Google takes three or four hours. Once it's live, I delete the app off my own phone, re-download it fresh from the store, and do one final test like a user would. Only when I'm happy do I have Claude flip the flag in Firebase that prompts users — once, not nagging — to update.

That's the whole workflow: user pain point → steal from the best → screenshot into Claude → tweak → ship → verify → roll out.

Build, ship, fix. Just launch. See if it takes. There will be bugs — your users are your bug testers, and some people genuinely love reporting them. I have about five regulars who do it enthusiastically. That frees me to keep building while fixing along the way. The one non-negotiable: keep things secure as you go. A lot of security is common sense, and the AI can handle most of the rest if you ask it to.

Test before you ship — properly. You still need to see every feature working. Mostly that's the simulator on the Mac; sometimes a real phone when it's called for, though a phone build takes longer — and a single UI change can take 10 or 20 (sometimes more) tweaks and builds to get right. Move the pill two pixels right. Now left. Now up a bit. New build every time. It's slow, it's annoying, it's necessary; you will rarely get it right first time. And before every release, click through four or five of your main features, every single time, because one change can quietly break something unrelated. Ask me how I know.

And a confession that will horrify professionals: I don't use TestFlight at all. I test enough myself, then put it straight into production. It's something I might introduce in the future, but for now I'm a one-man band. I've had a stuff-up or two in production, but the update prompt is my safety net — nobody gets told to update until I'm happy with it, and for bigger features I'll have one or two of my regulars kick the tyres first.

Your app is not enterprise-grade. Don't believe the AI when it says it is. Claude or ChatGPT will happily tell you your codebase is production-ready, enterprise-level, best-practice. It's not. It's good — it might even be great — but it's not enterprise, not right away. Nine months in, I'm getting closer, but I'm honest with myself that it's not there yet. Things just take longer than that. To be frank, the concept isn't even fully served yet — though I'm not convinced it ever will be.

Grow slow. I've spent zero dollars on advertising. The app is free. Word of mouth, community radio, and letting users test and shape it. This isn't a get-rich-quick scheme — it's going to take constant pivots and refinement, and I'm fine with that. I actually haven't really encouraged any word of mouth at all beyond the very early days on radio. More users means it costs more money to run, and the earlier versions of the app weren't as refined as they are now. Plus, I have no idea how the apps will perform under heavy load. Slow and steady is good for now.

How I pick what to build. A mix of shower thoughts and users — honestly, mainly users. I've had big ideas on the list since day one that I still haven't got to, and for those the question is always: do I have the energy to commit to something massive? The latest one is a detour-mapping studio site that links into the web, iOS and Android apps — which means finding organisations to use it, working with them, and suddenly maintaining two websites and two mobile apps' worth of incoming bugs. So I weigh impact against the energy I've got. But user-reported bugs I fix ASAP, always. That's how you build trust. I want users to feel like I'm working for them — I've stopped thinking of this as my app. It's the community's.

The rules: what I don't let the AI do

Two years of mistakes have hardened into a short list of hard rules:

• No destructive git commands. Ever. No reverts, no resets, nothing that throws away work. I hate revert — especially because I often have five Claude Code tabs working on the same iOS build at once. Spot-fix the problem instead. I know that's not how “real” developers work. I don't care. It works for me.
• Fact-check everything it writes twice. If the AI is writing content or researching real-world information — trail details, anything factual — it gets fact-checked twice, every time, because it makes things up. Always has. Every time.
• It builds and tests before I do. I make it compile and run the code itself first, to save my time and to make sure it isn't asleep at the wheel.
• It confirms before committing. Before any commit, it has to confirm it's not pushing anything nasty. (Honestly, the models are much better at this than they used to be — the mistakes of a year ago are rarer and rarer.)

These rules live in a CLAUDE.md file in my repo — the AI reads it at the start of every session, so I'm not repeating myself every day. When it breaks a rule, the rule gets written down.

When the AI is confidently wrong

It will be. Regularly. The only move that works: show it factual evidence that it's wrong, or it will burn hours of your time politely insisting. Screenshots pasted straight into Claude Code will set you free. Don't argue — show. And on occasion, you'll then learn that you are in fact the one who's wrong, and you've glossed over something very simple.

The tuition fees

The painful lessons are inevitable, and they're how you actually learn. My worst two:

• Not pushing to git. I've lost work to this over and over. It sucks every time, and you can only blame yourself.
• The $2,000 runaway function. I once deployed a cloud function that triggered itself millions and millions of times. Google billed me about $2,000. (They refunded half, being a genuine mistake — decent of them.) This taught me to set spending limits and alerts, so the alarm sounds before it's too late.

There will be more. That's the deal.

The cheat sheet: my actual stack

People always ask for specifics, so here they are — as of July 2026, because this stuff moves fast.

AI models. Claude Code running Fable when the limits allow — it's the most powerful model so far, but it burns through tokens, and honestly it feels like you only get the real Fable on rare occasions. When it's on, though, it's almost unbelievable how good it is. Opus 4.8 is the sweet spot — really good without destroying your limits in a few hours. Although some days it feels like they've turned the dial down; you learn to identify those days and switch to Codex. Sonnet 5 is a genuinely good option on a tight subscription or budget. I also keep a Codex subscription, because some days Claude just doesn't feel like showing up. That's the reality of AI: sometimes amazing, sometimes you flip between models. I've tried DeepSeek and a few other cheaper models — hit and miss, and I haven't bothered going back.

Database, auth and sign-ins. I just love Firebase. Maybe because I'm used to it now, but it's really simple to use — and you can set up its CLI inside Claude Code, so the AI can make changes to your database and settings without you even opening a browser. Supabase is also fantastic; I've worked with it a little. I'm just liking Firebase for its security and the fact that so many of the pressure points are bundled together.

Maps — horses for courses. The reason I'll talk you through these properly is that, as I explained earlier, I once couldn't even get a map to show on a screen. Now I've run through them all and tested what works, what doesn't, what's possible and what's not. Persistence pays off. If you love mapping, this gets SUPER tough. Mapbox is probably the best all-rounder: the most customisable, most apps use it, and it seems to be the easiest to build with AI, especially cross-platform (iOS, Android, web). Its satellite imagery is pretty rubbish, but the outdoor maps and others are amazing. MapTiler and a few others are also very customisable. (I haven't played with proper GIS tools much — I feel too much of an imposter to be using what the experts use, and it doesn't really suit what I'm building anyway.)

On iOS I've stuck with native Apple Maps. Why? Because the maps are bloody beautiful — the 3D maps are GORGEOUS on the phone, and it's geared to work with iOS without chewing your users' battery. The catch: no real offline maps in-app, and it can't run on web or Android, which means more maintenance and less continuity. With AI it's easy enough to manage, and I think the visuals are worth it. (Gaussian splats are coming to Apple Maps soon, which will make it even more spectacular.)

Google is probably the worst all-round case in my opinion: nice satellite, improving 3D, but not very customisable and the base maps aren't visually the best. The one thing they excel at is POIs — cafés, businesses, opening hours — and they're pretty easy to integrate into your app, at a cost. Mapbox POIs are terrible by comparison: they're linked to OSM, and not that OSM is bad, but for cafés and businesses it's just not well updated. Apple's POIs are a close second to Google's, but you can't really plug into them the way you can Google's.

So my setup: Apple Maps on iOS, Mapbox on Android and web, and Mapbox POIs enriched with Google's APIs so businesses get opening times. It all needs work. The moral: maps are horses for courses — most enterprise apps use Mapbox, and it's good to know a little bit of all of them.

Free data. You might not need to buy data at all. Almost my whole platform runs on data that costs nothing: OpenStreetMap for paths, trails and POIs (the Google POI enrichment is the paid exception), and government open-data portals for crash statistics and infrastructure. Weather is the other exception — I pay for a weather API so rain radar works across every device, though even the raw wind data comes free from NOAA. If you're building anything civic or community-shaped, OSM plus your government's open data portal is an absolute goldmine. The hard part is cleaning and shaping it — and that's probably the thing AI is best at.

Integrations you'd assume are out of reach. Two years ago, an OAuth integration would have been pure fantasy for me. I've now wired up Strava and Garmin sync solo. Every big platform has an API, the docs are always horrible, and the AI reads them for you. If your app idea depends on “connects with X,” it's achievable. (Some platforms make you apply for production API access — but that's paperwork, not code.) Garmin was a tricky one — they ask for all kinds of things, and honestly, even with the latest models it was weeks of effort plus back-and-forth with their support team, who for some reason will stop short of telling you exactly what you need to do. Still possible with the right persistence. The other thing to watch — and AI is great here too — is the terms of service. Strava, for example, won't let you use their API for anything competitive, and their data can only ever be shown back to the user it came from — so community heat maps from Strava data are off the cards.

Security minimums. “Keep it secure along the way” actually means, at minimum: API keys live in environment variables, never in your code. Your database rules deny everything by default and only open up what each user genuinely needs. And every so often, ask the AI to audit your own setup for holes — it's very good at finding the dumb mistakes it helped you make. A fair bit of this is time-consuming stuff the AI can't do for you, though — setting spending limits, restricting which web addresses can fire your APIs, that kind of thing. It's work to set up, and more work as your app expands across platforms, but it's what keeps you safe.

Hosting and plumbing. The website is Next.js on Vercel — push the code and it's live. GitHub for version control (learn it early; see “tuition fees” above). GitHub Actions runs my data pipelines — my map data now refreshes itself from OpenStreetMap every Monday at 4am while I sleep, because I had Claude build the whole pipeline. And a small DigitalOcean server runs my custom bike-routing engine, because some things still need an actual server.

Ops. Claude built me a daily 8am email digest: new riders, app usage, feature stats, and whether all my systems are healthy. Ten seconds over a coffee and I know if anything broke overnight. Highly recommend getting the AI to build your own dashboards.

Hardware. A MacBook Pro — M4 Max, 36GB of RAM. Powerful enough to run the builds, the simulators and five AI tabs at once. And remember: you need a Mac to build for iOS at all.

Logo and app icons. AI as well. Pretty basic, but it does the job — and it's one more thing you don't need to pay anyone for on day one.

The boring fees. Apple Developer Program is US$99 a year, Google Play is US$25 once, plus your domains and hosting. Small numbers, but nobody tells you about them until you hit the paywall.

The takeaway

I spent four years and thousands trying to find someone to build my dream app, and it never got built. In two years of vibe coding I've built more than everyone I ever hired combined — an iOS app, an Android app, a web platform, real users, real partnerships — for a few thousand dollars in AI and hosting bills and a frankly unreasonable number of early mornings. Less risk, more fun, a lot cheaper — and nobody can disappear on you.

You don't need a tech background. You need computer confidence, a stupid amount of persistence, and a first goal as simple as putting a map on a screen.

Then you yell for your partner to come and look at it, and you're gone. There's no way back after that.