I spent three years at a company building an API that began beautifully. The first endpoint was perfect. We had a pattern. Everyone understood it. Then we hired two more developers.
One skipped resources and returned raw arrays. Another validated inline because FormRequests felt “too abstract.” Someone wanted DTOs everywhere for “type safety,” which led to different response shapes. Another wrapped Eloquent in repositories “just in case we switch databases.”
No one was wrong. Each choice made sense on its own.
Collectively, we built an API where you couldn’t read two endpoints and understand the third. Every new feature started with, “How did we do this last time?”, and the answer kept changing. One endpoint cached aggressively. Another didn’t cache at all. One returned proper status codes; another buried errors inside 200 responses.
By month six, we weren’t shipping. We were reading our own code to find out what it did. Adding an endpoint took days where it had taken hours. Code reviews became architecture debates. Junior developers slowed down because they had to learn a different pattern for every endpoint instead of one.
Pull requests that should have taken an hour sat for days. Not because the logic was wrong, but because every endpoint triggered a new argument. And no argument ever resolved, because we had no foundation, only contradictory precedent.
The irony was that we had no performance problems and no scaling problems. The “flexible architecture” we thought we were building became the most inflexible thing possible. You couldn’t change anything, because no one understood why it was done that way.
We eventually rewrote the API, not because it was broken, but because consistency had collapsed.
The second time, we picked one pattern. FormRequests for validation. Resources for responses. One error structure. No exceptions. No “this endpoint is special.”
We debated once, committed, and moved forward.
Within a few weeks we were shipping faster than we had in the first month, and each endpoint made the next one cheaper. When you’re not working out how to do something, you’re solving the actual business problem.
Since then I’ve used the same approach across several production APIs, and the result has been the same each time: clarity first, velocity second, scale third. The checklist hasn’t changed either: use what Laravel already gives you, delete before adding, and keep the solution boring.
That’s why this book exists. Not because I found “the best way,” but because I lived through what happens when you don’t decide upfront, and saw what consistency unlocked.