So here’s me sharing a few things I learned (and paid for) so you don’t have to.
First, the positive news: getting started doesn’t have to be expensive. Your initial cost breakdown will probably look something like this:
- AI coding agent ~ $20/month
- Hosting ~ $1-50/month (depending on services and traffic)
- Domain ~ $5-50/year
- Additional tools and APIs ~ $10-100/month (payments gateway, email sender, LLM access, etc.)
Everyone’s setup is different, but for me, these were acceptable costs for trying new tech, learning a lot, and having at least a small chance of building something useful.
So I had fun. I experimented with agents, built small apps, and published them on the internet. I found a stack that worked for me, learned just enough to ship seemingly working products, and rushed them into production.
That’s when the expensive lessons started.
Costly Lesson Number One: Mistakes in Production Cost You The Most
While you’re playing locally, you pay almost nothing. But the moment you open your app to the internet, surprises can happen.My first one came a few weeks after publishing HowExpensive.in. I hadn’t promoted it. I barely told a few friends about it. And still, it cost me a few hundred pounds in unexpected charges.
Totally my fault.
I had what seemed like a clever idea: use the Google Translate API to translate content dynamically when users requested it. Efficient, right?
What I didn’t account for was that Google’s indexing bots would also request that content - and trigger translations.
That “clever optimisation” cost me a few hundred pounds in Google Translate API costs.
Lesson learned.
Costly Lesson Number Two: You’re Not a Security Expert. The People Who Attack You Are
The second major upset happened a few weeks ago.It was a quiet Sunday. I wasn’t planning to work. Then my phone buzzed with a notification from my bank about a payment to Google Cloud.
Then another.
Then another.
I opened the Cloud Console and saw my running costs had increased by 87,547% (as in eighty-seven thousand %) in a single day.
And they were still growing.
It took me a moment to realise what was happening: my app was under attack.
So I did everything you’re supposed to do:
- rotated credentials
- took the app offline
- disabled billing
- froze my credit card
- contacted support
Getting through to a human took time. When I finally did, I could only speak with Cloud Billing support. The representative was polite, but not very helpful. They couldn’t explain what had happened or what I should do next.
They did open a case and promised a response within 32 to 48 hours. They also reassured me that the steps I’d taken should prevent further fraudulent charges.
It was late. I decided to call it a day.
You can probably guess what happened next.
The next morning, I woke up to more attempted charges. My Cloud bill had grown further. Support hadn’t responded.
So I started googling.
The first link I opened led to a Reddit thread where dozens of builders described situations almost identical to mine. Some posts were months old. Others were recent and asking why the issue still hadn’t been fixed.
So this was known.
And yet there was no clear guidance from Google. Support didn’t seem prepared to help in cases like this. Worse, the attack appeared to be enabled by permissive default security settings.
That was the real shock.
How can a platform attract thousands of vibe coders, people who are not cloud security experts, while leaving defaults this exposed?
It almost felt like rapid Gemini adoption mattered more than protecting users from predictable mistakes and attacks.
To be fair, most of the blame belongs to the attackers. Some belongs to me too. If I hadn’t rushed to production… if I’d studied Cloud security more… if I’d found those warnings earlier…
But some lessons are simply expensive.
Where does that leave me?
My apps are still down. Google waived part of the fraudulent charges, but not all. Most importantly, they never explained what actually happened or how to prevent it in the future.
After struggling that much just to get support, I decided to move away from Google Cloud entirely.
Which brings me to the third lesson.
Costly Lesson Number Three: Vendor Lock-In Is Good for Them, Not Great for You
Platforms love lock-in. It makes perfect business sense.As a product manager, I appreciate it.
As a builder, I hate it.
When you start with Google AI Studio or Firebase, everything feels frictionless. Authentication, hosting, storage, AI models - all just one click away.
It’s only when something goes wrong, and you try to move elsewhere, that you realise the real cost of that convenience.
Migration suddenly becomes architecture archaeology, or a total rebuild exercise.
What I Would Do Differently
Retrospectives matter. If you don’t run retrospectives, eventually you’ll run post-mortems.Here’s what I’d change:
Learn the platform before investing in it.
Look for other builders’ experiences. Edge cases. Support quality. Failure modes.Don’t rush to production.
Validate locally. Use preview environments. Production exposure changes the risk profile immediately.Limit your spend proactively.
Use prepaid cards. Configure billing alerts and caps wherever possible.Avoid vendor lock-in early.
Ask your LLM to generate a theoretical migration plan. If parts of your stack can’t move easily - rethink the architecture.Talk to experts before scaling.
Some people have already paid for these lessons. It’s cheaper to learn from them.Lighter in the Pocket, but a Tiny Bit Wiser 💸
Will the costs of these lessons stop me from building?No.
Will there be more costly lessons in the future?
Almost certainly.
And I am fine with that.
A wise person once said: lessons you pay for with money are the cheapest ones.