People usually guess wrong when I tell them this.
Most people think I check the tests first, since no tests is supposed to mean bad code. Some think I read the README to see if anyone bothered explaining the project. Others guess I check the git history, looking for one huge, messy commit at the end.
Those are all good guesses, and they're all wrong.
Here's what I actually do. Before I read any code, I look for one file. Most of the time, it's missing. That file is called .env.example.
What that file actually is
You've probably never heard of it, and that's fine. Here's what it does.
Every app needs a few secret settings to run, things like a link to its database, a password, or a key for sending emails and taking payments. These are secrets, so they can't just sit out in the open in the code, where anyone could find them.
That's why most real projects keep those secrets in a separate file called .env. That file stays hidden. Nobody shares it, and nobody uploads it to GitHub.
But smart teams also keep a second file, called .env.example. It lists what secrets the app needs, without giving away the real values, something like this:
DATABASE_URL=
STRIPE_SECRET_KEY=
SMTP_HOST=
No real passwords, just the shape of what's needed. Think of it like a packing list for a trip. It doesn't pack your bag for you, it just tells the next person what to bring.
That sounds like a small thing, but it isn't. It's the single best clue I've found for how seriously a codebase was actually built.
Why one boring file tells you this much
To write that list, someone had to stop and think about what the app truly needs to run, and then write it down clearly enough for someone else to follow. You only do that when you expect someone else to need it, whether that's a teammate or your own future self on a different laptop.
That expectation is the whole signal. A project with a real .env.example has been run somewhere other than the original coder's own machine, at least once, by a second person.
A project without one has usually only ever run in one place, set up by one person, who never had to explain it to anyone else. So before I read a single line of logic, I already know a few things: nobody has checked that this app truly runs from scratch, the secrets probably aren't handled the safe way, and I'm about to spend my first hour untangling a setup that was never really planned, just pieced together over time.
What's usually sitting there instead
When that file is missing, the secrets don't just disappear, they show up somewhere worse.
I've opened files with a Stripe secret key typed straight into the code. I've found a database password sitting in a settings file like it's nothing special. More than once, I've found real, working secret keys buried in old GitHub commits, because nobody added .env to the ignore list in time. Even if that file got deleted a few commits later, those old keys are still sitting there in the history, and every one of them should be treated as already leaked.
None of that shows up if you're just skimming the business logic. It shows up in about five seconds, once you know which file to check first.
This is almost always missing from AI-built apps too
A lot of apps get built today by typing one sentence into a tool like Lovable, Bolt, Replit, v0, or Base44. These tools are fast, and genuinely good at what they do, but I've almost never seen a real .env.example come out of one.
That's not really their fault. The app only ever runs inside that tool's own hosting, so nobody ever had to hand it to a second developer or explain what it needs. The one thing that usually forces a project to grow this file, a second person needing to run it, just never happens.
That matters if you're planning to take one of these apps further, onto your own hosting, in front of real users, with real money attached. The gap between what these tools show off and what they quietly skip tends to follow this same shape. It stays invisible until someone other than the person who wrote the prompt actually tries to run it.
A few more quick checks, if you want more than one
Check whether .env is actually in the ignore list, and whether it got added on day one or three commits too late. That tells you if secrets were a real decision or an afterthought.
Check the database folder too. One giant file at the start and nothing since usually means the database has been changed by hand, live, with no record of what changed or when.
And check whether the list of installed packages actually matches what the code uses. If it doesn't, "it works on my machine" is doing a lot of heavy lifting in that sentence.
Each of these checks takes less time than opening a single code file, and none of them require you to understand what the app even does.
Why this beats reading the code first
Reading the code shows you what a developer meant to build. These small, boring files show you how they actually worked, when nobody was checking their homework, and I trust the second one more.
This is close to the very first thing we check at EnactOn, before we open a single file in a codebase someone hands us, whether it came from a freelancer, an agency, or a prompt. Most real projects go through this same growing-up process eventually, the only question is whether it happened before you inherited the app, or is about to happen on your watch.
Next time you open code you didn't write, try this first. Look for the file that isn't there. It usually tells you more, faster, than the code ever will.
What's the one thing you check first in code that isn't yours?
Top comments (0)