The site was written. Seven pages in Next.js, a Laravel API behind it, a back office. All that was left was putting it online — and that is where the project really began.
The constraint arrives after the code
The hosting was a shared plan: PHP, MySQL, FTP access, a control panel. No SSH depending on the tier, no permanent Node.js server, no global web server configuration.
This is not an exotic constraint. It is what a small business pays for its first website, and it is often discovered after the stack has been chosen.
What Next.js assumes
Next.js renders its pages with a Node server. On hosting that runs none, the application simply does not start. Two ways out:
- Change host — a virtual server, a monthly bill, and system administration nobody on the client side will take on.
- Remove the need for a server.
The first was not in the budget. It also had a less visible flaw: it moved an operational burden onto someone who did not want it.
Three parts, three subdomains
The site moved to a static export. Next.js can produce a folder of HTML, CSS and JavaScript files that an ordinary web server serves as they are — and shared hosting does exactly that.
The rest was split up:
| Part | Where | How |
|---|---|---|
| Public site | main domain | static files uploaded over FTP |
| API | subdomain | Laravel, ordinary PHP deployment |
| Back office | subdomain | Filament, served by the same PHP |
All three share the MySQL database, and API access is held by Sanctum. The site calls the API from the browser: everything dynamic moves client-side, precisely where the server can no longer do anything.
What a static export costs
This has to be said, or the solution looks free.
- No more server rendering. Changing data arrives after the first paint, not with it.
- No more routes computed on the fly. Every page must be known at build time.
- Search indexing changes in nature. Static content is indexable; content fetched from the API is not indexable the same way.
For a seven-page site whose content rarely moves, those three costs are acceptable. For a catalogue of ten thousand items, they would not be. The solution is not good in itself — it is good here.
What I take from it
Hosting constraints are part of the architecture, exactly like the choice of framework. Discovering them at deployment time is discovering them too late.
And a constraint is not always an obstacle to work around. This one produced a site faster than it would have been with a Node server on a shared machine, and an operation the client can run alone.