Back to all essays
Own Your TechResources

AWS and Google Cloud Are Designed to Keep You. Here's What We Do Instead.

·5 min read
George Pu
George Pu$10M+ Portfolio

27 · Toronto · Building to own for 30+ years

AWS and Google Cloud Are Designed to Keep You. Here's What We Do Instead.

When my startup was brand new, both AWS and Google Cloud felt like gifts.

Our incubator had relationships with both. The credits were generous.

The onboarding was smooth. We didn't pay a dollar out of pocket for months.

It felt like they were investing in us.

They weren't. They were investing in our dependency.

I didn't understand that then. I do now.

What You're Actually Paying For

I want you to try something. Strip away the logos and the marketing for a second.

Say you have some computer chips. You find a space to put them. You set up a rack. You start running software on them.

Then you realize you have extra room. Your colleague Alice pays $200 a month to use a slice. John pays $400 for a bigger slice.

You install some basic software to keep their stuff separate. All doable with existing tools.

That's it. That's cloud computing.

Amazon and Google just do it at a massive scale, with world-class branding, compliance teams, and sales reps who pick up on the first ring.

Those things have real value. I'm not dismissing that.

But once you see it for what it is — renting someone else's computers — you start asking different questions about how deep you really want to go.

The Month I'll Never Get Back

Here's where it got personal.

We had a simple B2B app running on AWS. Nothing fancy. A server, a few databases, a front-end, some supporting services. The kind of thing a small team builds in a few weeks.

We decided to move it to Google Cloud. Shouldn't be a big deal, right?

Same type of infrastructure. Same basic services. Should be a weekend project, maybe a week if we're being careful.

It took a month.

Three developers. Full-time. Migrating one piece at a time. Server first. Then settings. Then credentials. Then databases. Then the front-end.

Then service A, B, C, D — each one with its own quirks, its own format, its own way of doing things that didn't translate.

I remember sitting in a standup three weeks in, listening to my team debug yet another configuration issue, thinking: none of this is creating anything. We're not building features. We're not serving customers.

We're just moving boxes from one room to another, except the doors are different sizes and nothing fits.

A month of engineering time. For a simple app.

That's when I stopped thinking about cloud as a convenience and started thinking about it as a commitment.

The Help That Helps Them

I don't want to be unfair to either company. Both have good people.

An AWS team member once sat down with me, looked at my architecture, and told me straight — this is outdated, here's what's better, and it'll save you money.

Genuinely one of the most useful conversations I've had with a vendor. That kind of honesty is rare and I respect it.

Google Cloud's team was helpful too, but the energy was different. Less "how do we solve your problem" and more "here's how you can use more of our services."

Both teams are doing their jobs well. I just want you to understand what their jobs are.

Their job is to make you successful on their platform. Not successful in general. On their platform. That's a meaningful distinction.

The help is real. The direction it points you is also real.

Then AI Made It Ten Times Worse

After the migration disaster, I promised myself we'd be smarter. Keep things portable. Don't go too deep.

Then AI took off, and both platforms rolled out their own AI services. New ways to call AI models.

New ways to store data for AI. New ways to build AI-powered features. All tightly integrated with everything else on their platform.

We looked at these seriously. I had calls with both teams about it.

And then we walked away.

Here's what I realized. The old lock-in was painful but survivable. A database here, a function there — you could swap pieces out one at a time if you really needed to.

AI lock-in is different. It's not one piece. It's the entire chain.

Your documents get converted into a format only that platform understands. Your search logic uses their tools. Your security references their permission system.

Your compliance docs name their specific services. Everything connects to everything else, and all of it is proprietary.

I started asking founders who had gone deep on these platforms what it would take to leave.

The answers were sobering.

One friend running a mid-stage startup told me his CTO estimated a seven-figure cost just to scope the migration. Not do it. Scope it.

Another described it as "rebuilding the company's entire AI brain from scratch."

And the thing that really got me? During setup, the cloud engineers recommend exactly these services. And the recommendations are good. They'll get you running fast. They'll save you time upfront.

Want the full playbook? I wrote a free 350+ page book on building without VC.
Read the free book·Online, free

They just make it nearly impossible to leave later.

What We Do Instead

After all of this — the month-long migration, the AI lock-in research, the sobering conversations — we landed on a principle that now governs every infrastructure decision we make:

Rent the datacenter. Own the intelligence.

For the basic stuff — servers, file storage, databases — we use AWS and Google Cloud happily.

This is what they're great at. Commodity infrastructure. The kind of thing where, if we needed to, we could pack up and move to another provider in a weekend.

For the AI layer, we go direct.

We call Anthropic and OpenAI ourselves. No middleman. No cloud provider sitting between us and the model.

The markup for going through a platform's AI gateway can be 15-30% — and for what? The privilege of being locked in?

We run our own search tools on basic virtual machines.

We keep our data in open formats.

We use software that lets us swap providers by changing a settings file, not rewriting our codebase.

Is it more work upfront? Yes. Meaningfully more.

But every hour we spend building portably is an hour we'll never have to spend on another month-long migration. And I know exactly what that month feels like.

The rule of thumb: if we can pack it up and move it in a weekend, it's safe.

Everything else is a trap with a payment plan.

The Real Reason This Matters

People hear this and assume it's about saving money. And yes, going direct saves us around 20% on AI costs alone.

But that's not why we do it.

We do it because AI moves too fast to be stuck.

The best model today might not be the best model in six months.

The cheapest provider right now might get undercut next quarter.

Entirely new approaches show up every few months.

If you're cemented to one platform, you watch all of that happen from behind a wall. You can see the better option.

You just can't get to it. Not without months of work and a seven-figure budget.

We'd rather do more work upfront and keep the door open.

Every quarter we ask ourselves one question:

Can we realistically move our core systems to a different provider without a multi-month project?

The day that answer is no, we've gone too deep.

The Bottom Line

AWS and Google Cloud are great landlords. Competitive rates. Reliable hardware. Lights always on.

But they're not your partners. They're not even trying to be.

Their business model is to make you so comfortable, so integrated, so dependent that leaving feels impossible.

And the deeper you go into their AI platforms, the more true that becomes.

So use them for what they're genuinely best at. Rent the servers. Store the files.

But own your intelligence.

Call your AI providers directly.

Keep your data in formats you control.

Build everything like you might need to leave tomorrow.

Because in a world where AI changes everything every six months, the most valuable thing you can have isn't the best model or the cheapest compute.

It's the ability to move.