← Back to blog

What I Check in the First 15 Minutes on a Project That's Already on Fire

People call me when things are already broken. The developer disappeared. The deadline is tomorrow. "Just a few tweaks" turned into "we have no idea what's happening anymore."

Over eight years I've built one reflex: the first 15 minutes on someone else's project are the most honest. After that, you start adapting. Context arrives, self-justification kicks in, your eyes adjust. An hour in, you're already thinking like the person who wrote it.

Below is my quick audit protocol for a troubled project — not a code review, not onboarding. Fifteen minutes of cold assessment while your first impressions still work.

Why the first 15 minutes are the most honest

Pattern matching is sharpest when there's no context. Your first look at a codebase works like a first look at an architecture diagram — you see structure, not details.

After 30 minutes you start rationalizing. "There was probably a reason for this." "Maybe it's legacy." "I can figure it out." That's normal adaptation. But it closes off the initial signal.

So I set a timer and follow the protocol. 15 minutes. Then I write down my first impression — before I start "understanding" things.

The first screen: before code

I don't open the IDE first. Three things you can see without credentials.

curl -I https://site.com. I check what the server returns: PHP version, server type, presence of X-Powered-By. PHP 7.4 in 2026 is already a question. CMS version in headers means someone didn't read basic security checklists.

robots.txt and sitemap. Whether they exist at all. Whether admin panels are blocked from indexing. Not an SEO question — a question about how much attention the team pays to details.

How they deploy. If there's CI/CD, I look at the pipeline. If not, I ask. "FTP manually" — one type of project. "Script on the server" — another. "We don't know" — a third.

Three minutes, three screens. You already have a read on process maturity before you've touched a line of code.

The repo: three signals in 60 seconds

If I have repo access, I open it and look for three things in this order.

composer.lock committed? If not, dependencies aren't pinned. composer install on production can produce different results than on staging. This is where "but it worked on my machine" comes from.

Secrets in git history. git log --oneline --all | head -20 plus searching for .env in commits. If a .env with real credentials ever landed in the repo, the security question is open — even if the file is in .gitignore now.

Age and frequency of commits. Last commit three months ago while the project is "on fire"? It's been on fire for a while. Nobody was fixing it. Chaotic commits with no message convention mean a team that worked without discipline.

60 seconds — and you know whether basic engineering practices are present.

Production config: four markers

Next five minutes are the production side.

Sessions. For PHP projects on Bitrix, I check where sessions are stored first. File-based sessions under load means blocked FPM workers. I've watched a server go down at 11pm because of exactly this. One grep -r "session" /etc/php* or a look at php.ini — immediately clear.

OPcache. Is it enabled at all. What's in opcache.revalidate_freq and opcache.validate_timestamps. If validate_timestamps=1 and revalidate_freq=0 in production, the cache checks every file on every request. Someone set this up locally and never changed it when they deployed.

Error logs. tail -100 /var/log/php_errors.log. If there are 400 lines per hour, something is consistently broken and the site is running "in spite of" the errors. No logs at all usually means display_errors = On and log_errors = Off. Development-mode settings running in production.

Cron. crontab -l. In troubled projects, cron often dies quietly: jobs are in crontab, but the scripts have been failing for months and nobody noticed. Especially if email notifications were going to a developer who left.

Five minutes — and you know whether production is actually working or just not crashing.

One question for the team

After the technical pass — a conversation with whoever is closest to the project. The owner, PM, or last surviving developer.

One question: "What do you know for certain still works — and what are you afraid to touch?"

If they name a specific function or integration, it's critical. If they say "we don't know" — either there's no documentation, or nobody dug in deep enough. "We don't know" from the owner is its own diagnosis.

Second question if there's time: "When did this last work normally?" That gives you a baseline.

I don't ask more. Two questions maximum. Each additional question gives less signal and more context that starts shaping your perception.

What this tells you about the cost of rescue

By the end of 15 minutes I have a signal, not an estimate.

Good signal: composer.lock committed, Redis sessions, OPcache configured, error logs clean, cron monitored. A specific problem is fixable in scope.

Bad signal: file sessions, no composer.lock, display_errors = On, logs either empty or flooding with errors, cron dead. "Fix one thing" probably means opening several related ones. Multiply the estimate by 2-3.

Very bad signal: secrets in the repo, PHP 7.2, no git history, the owner doesn't know what works. That's a different conversation — not about repair, but about whether to take the project at all. I screen difficult clients before starting. The same skill applies to projects: sometimes the right answer is to walk away.

Think of it like a mechanic's walk-around before a used car sale. Fifteen minutes outside gives 80% of what you need to know. The rest comes out in the teardown — and that costs money.

If you're curious what a pre-project checklist looks like before you inherit a troubled project — the version where there's still time to assess — see three checks before any headless project. This protocol is for when there's no time left.

The checklist: 15 checks in 15 minutes

Before code (3 min):

  1. curl -I — PHP version, headers, X-Powered-By
  2. robots.txt — are admin areas blocked from indexing
  3. How do they deploy (CI/CD, script, FTP?)

Repo (2 min):

  1. composer.lock committed — yes/no
  2. Secrets in git history — search for .env
  3. Age and frequency of recent commits

Production (5 min):

  1. Where sessions are stored — files or Redis
  2. OPcache — enabled, validate_timestamps, revalidate_freq
  3. Error logs — present, empty, or flooding
  4. crontab -l — what runs, where do notifications go
  5. df -h — disk space (troubled projects often = 99% full)
  6. free -m — how much memory, what's consuming it

Team (5 min):

  1. "What do you know still works — and what are you afraid to touch?"
  2. "When did this last work normally?"
  3. Write down your first impression — before discussing the details

The protocol won't tell you everything. What it gives you is that first honest read — before you start adapting and rationalizing. From there, close risks, not tickets. But first you need to know which risks you're actually looking at.

The decision gets made in the first 15 minutes. After that, you're already inside — and getting out is harder.