We're teaching new builders the wrong words

Thousands of people are building their first apps with AI right now, learning that "backend" means Supabase, that "your cloud" means accessing someone's service¹, that "production ready" means it deployed and seems to work.

I don't think this is malicious - it's just really good marketing meeting really bad timing.

These new builders aren't trying to become developers. They're solving problems they have by describing what they want while AI generates code. We're watching software creation become accessible to millions of people who would never touch a terminal, which is incredible.

But we're teaching them the wrong definitions.

In six months, some will try to scale their apps, customize their infrastructure, or migrate to a different provider. They'll discover they don't actually own what they built - they're just customers of a platform with terms they didn't fully understand. "Your cloud" never meant yours. "Backend" was an integration they can't modify. "Production ready" meant someone else's production environment with someone else's rules.

I'm not arguing we should teach everyone database normalization and OAuth flows (I wrote more about this in this article). Some builders don't need to know those things to build useful software. LLMs are getting better at translating "I want monthly subscriptions" into working Stripe integration. Most abstractions are good. Most complexity should be hidden.

But there's a difference between abstraction and misdirection.

When you tell someone they're deploying to "their cloud," they reasonably believe they own that infrastructure. When you say "production ready," they think it means what production has always meant: scalable, controllable, theirs. These aren't technical terms being simplified - these are ownership concepts being redefined.

Vocabulary shapes how these builders think about what they're building. When they need something their platform doesn't offer, they won't think "I need to add this to my backend." They'll think "I guess my app can't do that."

There's another path²: generating real backends - microservices, databases, APIs - and deploying them to your own AWS or GCP account. You own the infrastructure from day one. Is this harder to explain than "click to connect Supabase"? Yes. But honesty about what we're building matters more than clever marketing.

More people will start building software in the next few years than in the entire history of computing. Most won't be engineers. They'll be domain experts solving problems they understand deeply, using AI tools that translate their intent into code.

What vocabulary do we teach them? That integration equals infrastructure? That renting equals owning? Or do we build tools that match how they think while being honest about what those tools actually do?

The first path is easier to market. The second path is better for builders.

I might be wrong about all of this. Maybe in two years the distinction won't matter. Maybe ownership won't be something builders care about. But watching thousands of people build their first apps while learning vocabulary that doesn't match reality - that's a problem worth solving.

---

¹ Recent examples include Bolt's Cloud and Lovable's Cloud.

² This is what we are doing at Leap.