Contents
In brief
Everything felt fast in staging — then real users arrived and APIs slowed, dashboards lagged, and the team looked for a bigger server. Spice Factory Philippines shared six recurring Laravel mistakes from client work on Dev.to: from Eloquent misuse to undervaluing cache and upfront communication. Nearly every issue lived in application code, not infrastructure.
What happened
Eloquent accelerates early development but hides query cost. The team hit classic N+1 patterns: relationships loaded inside loops, endpoints firing dozens of SQL round-trips, responses carrying fields nobody needed. Explicit with('roles') and checking queries with Telescope or logs often fixed latency without touching hardware.
The second myth: “slow API means weak VPS.” More often the culprits were missing indexes, repeated fetches of the same rows, and unnecessary joins. Cleaning schema and queries improved response times on the same host.
Cache felt optional until reports and dashboards saw daily traffic. A simple Cache::remember with a short TTL for heavy aggregates noticeably reduced database load.
As features grew, controller logic stopped fitting in one head. They did not big-bang refactor — logic moved into services when a feature started to sprawl, which helped multiple developers work in parallel.
Client deadlines reshuffle priorities: working and stable first, polish later. And unclear requirements cost more than clever code — clarifying scope early saved weeks of rework.
Why it matters
Tutorials teach Laravel syntax, not how the stack behaves under steady load. The ORM is not the enemy; convenience masking round-trips to PostgreSQL or MySQL is. The same pattern shows up in Django, Rails, and TypeORM.
Cache matters on read-heavy screens. Code structure and business alignment decide whether you ever get time to optimize before the deadline hits.
In practice
- Count SQL queries per new endpoint; plan eager loading for list views.
- Before upgrading servers, audit indexes, payload size, and duplicate queries in one HTTP request.
- Cache expensive dashboard aggregates with short TTL and explicit invalidation on writes.
- Move growing logic out of controllers into services when pain appears, not “someday.”
- Write requirements down before the sprint — cheaper than rewriting APIs.
Takeaway
Six lessons, one theme: production Laravel performance is query discipline, cache where reads dominate, and clear communication. Hardware helps last, after the app is measured and simplified.