How would you choose the UI approach for a startup's Laravel scheduling SaaS with a small team, a public booking page, a drag-and-drop staff calendar and a possible mobile app?
answer
- start from team skills
- which screens must feel instant
- public pages need indexable HTML
- mobile means an API either way
- mixing approaches in one app is allowed
basics
~20 sStart from team skills and the hardest screen. A drag-and-drop calendar favours client-side state (Inertia), the public booking page favours server-rendered HTML, and a future mobile app needs a token API anyway, so it does not force a separate SPA.
solid answer
~50 sI would score the options against four facts. **Team skills**: a PHP-only team ships fastest with Blade and Livewire; a team fluent in React or Vue ships fastest with Inertia. **Hardest interaction**: dragging appointments on a calendar needs instant client-side feedback, which Inertia or a JS widget inside Livewire handles better than a round trip per move. **Public booking page**: it must be fast and indexable, so either Blade routes in the same app or Inertia with SSR. **Mobile later**: that needs a Sanctum token API whatever the web uses, so it does not justify a separate SPA and a second repository now. For a small team my default would be one Laravel app with Inertia for the staff app, Blade for public pages, and an API added when the mobile app is real, revisiting if the team is PHP-only.
go deeper
Know the four options and that team skills and the hardest screen shape which one a project picks.
Explain how a calendar's interactions, a public page's indexing and a mobile client each push the choice.
Propose a concrete split, Inertia or Livewire for staff screens and Blade for public pages, and an API only when mobile is real.
Present criteria, a default, and the evidence that would reverse it, recognising the choice is costly to change later.
## Why this is a judgement call There is no correct stack for "a scheduling SaaS". The decision is made **before** the product exists, with a team of a certain shape, and it is expensive to reverse: switching a large Livewire app to Inertia (or the other way) means rewriting the UI layer. The goal is a choice that fits today's team and keeps tomorrow's likely needs cheap. ## The facts that drive it | Factor | Pushes towards | Why | |---|---|---| | Team writes PHP, little JavaScript | Blade + Livewire | one language, no front-end build discipline to learn | | Team fluent in React, Vue or Svelte | Inertia | component ecosystem, client state, still one repo | | Heavy client interaction (calendar drag, live previews) | Inertia, or JS islands in Livewire | no round trip per movement | | Public, search-indexed pages | Blade routes, or Inertia with SSR | indexable first response | | Several clients (web, mobile, partners) | an API alongside the web app | tokens and JSON contracts are needed anyway | | Separate front-end and back-end teams | separate SPA on an API | independent release cycles | | Very small team | one repository, one deploy | coordination cost dominates | ## Applying it to this startup 1. **Team**: small; assume one or two full-stack developers. Their strongest language decides velocity more than any benchmark. 2. **The staff calendar** is the hardest screen: dragging appointments, resizing slots, instant conflict hints. Round-tripping each movement through Livewire would feel sluggish at distance, so it needs client-side state — Inertia pages, or a JavaScript calendar component embedded in a Livewire page with Alpine and a save action at the end of a drag. 3. **The public booking page** must load fast for customers arriving from search or shared links, so its first response should contain real HTML: Blade routes (possibly with Livewire for the slot picker), or Inertia with an SSR process. 4. **The mobile app** is "possible". When it arrives, it will need JSON endpoints authenticated with Sanctum tokens. That work is the same whether the web app is Livewire or Inertia, so it is not a reason to build the web as a separate SPA today. ## A defensible default - One Laravel application and repository. - **Inertia with the team's framework** for the authenticated staff app, where the calendar lives — or Livewire everywhere if the team is PHP-only, with the calendar as an embedded JavaScript component. - **Blade routes** for public booking and marketing pages, avoiding an SSR process until the product needs one. - Business logic in actions and services the controllers call, so a later `routes/api.php` for mobile reuses them. - Session authentication for the web; Sanctum tokens only when the mobile client exists. ## What would change the answer - A dedicated front-end team, or a plan to sell API access to partners, makes a separate SPA on a first-class API more attractive. - A team with no JavaScript experience makes Livewire the pragmatic default, with the calendar isolated as the one JavaScript-heavy piece. - Strict SEO needs across rich interactive pages make Inertia SSR worth its operational cost. ## Costs that are easy to forget - **Build tooling**: Inertia means a JavaScript build, type checking and a component library to maintain; Livewire keeps most of that out of the codebase. - **Testing**: Livewire components are tested from PHP; Inertia pages need JavaScript tests for client logic, on top of Laravel feature tests for controllers. - **Hiring**: the chosen stack decides who can be productive on day one. - **Reversal cost**: moving later is screen-by-screen work, which is tolerable only because both approaches coexist as routes in one app. ## How to present it Name the criteria, apply them to the product's hardest screen and its public surface, state a default, and say explicitly what evidence would flip it. That is the principal-level signal: not a favourite tool, but a decision with its reversal conditions written down.
- Six months later the team is PHP-only after a hire leaves, and the app is on Inertia with React. What do you do?Avoid a rewrite. Keep Inertia for existing screens, build new CRUD-heavy screens as Blade or Livewire routes in the same app, and budget React knowledge for the calendar. Both approaches coexist as routes in `routes/web.php`, so the migration can follow the team's skills screen by screen.
- When would you start with a separate SPA and an API from day one?When independent clients are certain and near-term — a mobile app and partner integrations at launch — or when separate front-end and back-end teams need their own release cycles. Then the API is the product's contract, and a separate SPA is one more consumer of it rather than an extra cost.
saying these in an interview costs you the question
- A possible mobile app means the web front end must be a separate SPA now
- Livewire can never be used for any interactive screen
- Inertia makes public pages impossible to index
- The fastest framework in benchmarks should decide the stack
- One Laravel app must use a single UI approach everywhere