Most of the platforms we build end up with the same shape: a Next.js front end for the parts customers see, and a Laravel API for the business logic, queues and admin tools. It is not the only way to build a product, but it has held up across CRMs, marketplaces and payments dashboards.
Why two halves
Next.js gives us server rendering, image optimisation and routing that search engines like. Laravel gives us a mature ORM, queues, scheduled jobs, auth and an admin ecosystem that saves weeks. Each does its job well, and neither has to pretend to be the other.
Rule one: the API contract is the product
We write the contract before the screens. Every endpoint has a typed request and response, generated into TypeScript for the front end, so a renamed field breaks the build rather than production.
// generated from the Laravel API spec
export type Invoice = { id: string; total: number; status: 'draft' | 'sent' | 'paid' }Rule two: one deploy pipeline
Both halves live in one repository and ship through one pipeline. A pull request that changes the API and the page that uses it gets reviewed, tested and deployed together.
Rule three: the same people touch both
Splitting the code is fine. Splitting the team into front-end and back-end silos is where projects slow down.
Our engineers work across the stack, so the person building a screen can add the endpoint it needs. That keeps features moving and keeps the contract honest.