Taking over a Laravel app from another vendor, or about to sign with a new one? Laravel itself is rarely why projects end up rebuilt. The usual causes are structural, and you can spot most of them in an afternoon of review.

1. Version and support window

Per the official Laravel docs, each major release gets bug fixes for 18 months and security fixes for 2 years. Laravel 13 shipped in March 2026, and Laravel 12 security support runs until February 2027. Note the PHP version too, and put upgrades in the maintenance plan.

2. Where the business logic lives

  • Rules, calculations and queries crammed into controllers make every change risky.
  • Look for service classes, form requests, policies and queued jobs instead.

3. Tests

  • Laravel supports PHPUnit and Pest out of the box.
  • Check whether feature and unit tests exist and run on every change. "We checked it manually" is a warning sign.

4. Database access

  • Look for N+1 queries: a list of 100 orders that fires 101 queries looks fine with test data and slows down with real volume.
  • Check for eager loading, caching and queues for heavy work.

5. Security basics

  • CSRF protection left on, no unsafe raw queries, Blade output escaping intact.
  • APP_DEBUG off in production.
  • No secrets committed to the repository.

6. Review and deployment

  • Does a second developer review each change?
  • Separate staging and production, with a repeatable deploy. FTP uploads to live are a red flag.

7. Ownership

  • Repository, cloud or hosting accounts and domain should be in the client's name from day one.

8. Prove it with a pilot

  • A sanitised code sample reviewed by an independent developer, then a paid two to four week pilot on one real module.

More detail: how to choose a Laravel web development company without a costly rebuild

Written by the team at Affix Center, an IT services company in Lower Parel, Mumbai.