Everyone's a Developer Now. Nobody's Managing the Secrets.

Let me tell you about Alex. Alex is a founder - scrappy, ambitious, moving fast. Two years ago, Alex couldn't write a single line of code. Today? Alex has a SaaS product with 200 paying customers, a Next.js frontend on Vercel, a Postgres database on Supabase, Stripe handling payments, Resend firing off emails, and an OpenAI integration powering the AI features that customers can't get enough of.

Alex built all of it in a weekend using Cursor and v0. Seriously. One weekend.

Alex also has a .env file sitting in a public GitHub repository. It's been there for three months. It contains the production Stripe secret key, the Supabase service role key, and the OpenAI API key. Alex has no idea what a .gitignore is. The AI agent that scaffolded the project did create one, but when Alex asked the AI to "clean things up" during a late-night reorganization, the .gitignore got rewritten and .env quietly disappeared from it.

Alex isn't careless. Alex just doesn't know what they don't know. And there are thousands of Alexes shipping code right now.

The new developer class

At CES 2025, Jensen Huang dropped a line that's been living rent-free in my head ever since:

Everybody in the world is now a programmer. This is the miracle of artificial intelligence.

— Jensen Huang, CEO of NVIDIA

Sam Altman's been saying the same thing for a while now. The idea is simple: AI makes software creation accessible to everyone. You don't need to understand syntax, data structures, or system architecture anymore. You describe what you want, and AI builds it for you.

And this isn't some far-off future - it's happening right now. Product managers are spinning up internal tools. Designers are shipping prototypes that somehow become production products. Marketers are building landing pages with functional backends. Founders with zero technical background are launching complete SaaS products and getting paying customers.

Honestly? The results are often really impressive. But the security posture of these projects? That's a whole different story.

The .env file: your app's master key

If you grew up writing code, you just know. The .env file holds your secrets. You don't commit it. You don't share it in plaintext. You add it to .gitignore before you do anything else. It's muscle memory at this point - reflexes built over years of making mistakes and learning from them.

But for someone who started building software six months ago with AI tools? That intuition simply doesn't exist. To them, the .env file is just another config file. It looks like package.json or tsconfig.json. There's no lock icon. No scary warning banner. It's just a file with some values in it. Why would it be special?

Here's the thing - that file is the master key to the entire application. It typically contains:

• Database credentials - full read, write, and delete access to every record you've got.
• Payment API keys (Stripe, PayPal) - can process charges, issue refunds, and access customer payment data.
• Email service keys - can send emails as your app to literally any address.
• OAuth secrets - can impersonate your app when talking to third-party services.
• AI API keys (OpenAI, Anthropic) - can rack up thousands in charges if someone gets hold of them.

If any one of these gets compromised, you're looking at anything from financial loss to a full-blown data breach to regulatory violations. And the person most likely to accidentally expose them? Someone who doesn't fully understand what they are.

The five most common failure modes

Based on GitHub security scanning data, GitGuardian reports, and patterns we've seen over and over in the community, here's how non-developer builders most commonly leak their secrets:

1. Committing .env to a public repository. The big one. The classic. Someone doesn't add .env to .gitignore, or the .gitignore gets misconfigured, and the file ends up on GitHub for the whole world to see. And even if you delete it later - too late. It's in the git history forever. Bots scan GitHub in real-time looking for exactly this. They will find it before you do.

2. Sharing secrets via email or messaging apps. You're working with a co-founder, a freelancer, a contractor - what do you do? You send the env file over email, Slack, Discord, or WhatsApp. It's the most natural thing in the world. It's also terrible. All of these store messages permanently, they're searchable, and none of them encrypt at the message level.

3. Storing secrets in Notion, Google Docs, or spreadsheets. This one actually feels responsible because it's "organized," right? Except these docs have no field-level encryption, no access logging, and the sharing permissions are probably set to "anyone with the link." One misclick on those sharing settings and every secret is exposed to the open internet.

4. Hardcoding secrets in deployment configurations. Docker Compose files with plaintext passwords. CI/CD configs with API keys as string literals. Environment variables dumped into the Vercel or Netlify dashboard once and never touched again. It worked the first time, so why would anyone go back and revisit it?

5. Never rotating secrets. Most non-developer builders don't even know that secret rotation is a thing. That Stripe key from the initial setup? Still the same key a year later. If it got compromised at any point during that year, the exposure window is the entire year. That's terrifying.

The scale of the problem

This problem isn't going to fix itself. Every month, more people start building with AI tools. Every month, more .env files get created. And every month, more of those files end up somewhere they absolutely shouldn't be.

Look, the security community's traditional answer has been education - "developers should know better." But that falls apart when the person building isn't a developer. You can't expect someone who learned to build software three months ago to have the same security instincts as someone with ten years of battle scars. That's just not realistic.

Guardrails, not gatekeeping

The answer isn't to tell non-developers to stop building. That ship has sailed - and honestly, good riddance. The democratization of software creation is genuinely a good thing. More people building means more problems getting solved, more businesses getting off the ground, more weird and wonderful ideas becoming real products.

But we desperately need guardrails. Tools that just do the right thing by default, so the person using them doesn't need to become a secret management expert to stay safe.

That's the whole idea behind SlickEnv. When you run slickenv init, three things happen automatically:

• Your .env gets added to .gitignore if it isn't already there.
• A secure project is created that encrypts every variable with AES-256-GCM before anything leaves your machine.
• Sharing happens through encrypted push and pull - not through Slack messages or email threads.

The person using it doesn't need to know what AES-256-GCM is. They don't need to understand what a .gitignore does or why it matters. They just use slickenv push and slickenv pull, and the security happens in the background. No thinking required.

That's what good security tooling looks like. Not tools that require expertise to use correctly - tools that make the secure path the path of least resistance.

Security should not require a security degree

The era of everyone being a developer is here. Jensen Huang was right about that. But the era of everyone being a security engineer? That's not here, and it probably never will be. The gap between "I can build an app" and "I can secure an app" is real, and it's only getting wider as more people join the builder side without picking up the security instincts along the way.

We need better defaults. Better tools. Better guardrails. Tools that assume the user might not know the risks - and protect them anyway. That's what we're building with SlickEnv.

Because everyone deserves to build. And everyone deserves to build without accidentally handing their Stripe keys to the entire internet.