DEV Community

Arun Tyagi
Arun Tyagi

Posted on

What I Look For in a Laravel Project Before Writing a Single Line of Code

TITLE:
What I Look For in a Laravel Project Before Writing a Single
Line of Code

PUBLICATION: Submit to 'Level Up Coding' or 'The Startup'


After 10 years of joining projects mid-way — some clean,
most not — I've developed a codebase triage process I run
before touching anything. It takes 90 minutes. It has saved
me from several catastrophic commitments.

Here's exactly what I check and why.

1. The Migration History

php artisan migrate:status
Enter fullscreen mode Exit fullscreen mode

If this returns errors or shows migrations out of sequence,
the database schema is probably inconsistent between environments.
I've seen production databases with columns that no longer
exist in migration files — because someone edited a column
directly in production without creating a migration.

This is a 6-8 hour problem minimum. I price it before starting.

2. N+1 Query Detection

I install Laravel Debugbar for 15 minutes and click through
every major page. If any page triggers more than 50 queries,
there are N+1 problems.

The most common pattern I find:

// Triggers one query per user in the list
$users = User::all();
foreach ($users as $user) {
    echo $user->company->name; // N+1
}

// Fix
$users = User::with('company')->get();
Enter fullscreen mode Exit fullscreen mode

On one eCommerce project I audited in Delhi NCR, the orders
page fired 847 queries for a 50-order list. After eager loading,
it dropped to 4 queries.

3. Sensitive Data in .env.example

You'd be surprised how often I find actual API keys or passwords
committed to .env.example, which IS tracked in Git. This is an
immediate security incident — those credentials should be rotated
before anything else.

4. Authorization Coverage

grep -r 'authorize|Gate::allows|can(' app/Http/Controllers/
Enter fullscreen mode Exit fullscreen mode

If this returns very few results on a multi-user application,
there are likely unauthorized data access vulnerabilities.
I've audited projects where any authenticated user could
access any other user's data just by changing an ID in the URL.

5. Test Coverage

php artisan test --coverage
Enter fullscreen mode Exit fullscreen mode

Under 20% coverage on a production application means every
change I make carries unknown risk. I factor 30-40% of project
time into writing tests before adding features.

What This Triage Tells Me

After 90 minutes, I know whether the project is:

  • Dirty but fixable (most are)
  • Clean and ready to extend (rare, satisfying)
  • So compromised it needs a rebuild conversation

I've turned down projects after this check. Not often — but
it has protected clients from committing budget to codebases
that would have cost more to fix than rebuild.


If you're planning a Laravel project or need an audit of an
existing codebase, this is the kind of evaluation I do before
taking any engagement. You can see the types of projects I
work on at aruntyagi.com or connect
with me directly for a technical consultation.

— Arun Tyagi | Senior Laravel Developer | Noida, India

Top comments (0)