So my frontend never trusts the stored token. On every reload, the AuthProvider calls /me and lets the backend decide who this is:

public function me(Request $request): JsonResponse
{
    return response()->json(['user' => new UserResource($request->user())]);
}

One line. auth:sanctum resolves the token to a user or rejects it; the method just answers "this is who you are" — through UserResource, so the shape matches every other endpoint. And on the React side:

useEffect(() => {
  const stored = localStorage.getItem('saas_token');
  if (!stored) {
    setLoading(false);
    return;
  }
  client
    .get('/auth/me')
    .then((res) => {
      setUser(res.data.user);
      setToken(stored);
    })
    .catch(() => {
      localStorage.removeItem('saas_token');
      setUser(null);
      setToken(null);
    })
    .finally(() => setLoading(false));
}, []);

Three paths, all deliberate:

1. No token stored — skip the request entirely, mark loading done. Don't fire an API call you know will 401; the catch block would clean it up anyway, but a request you never send is a request you never debug.
2. Token valid — the user object comes from the server, not from memory. Role changes, name changes, account deletions all resolve here, on the first paint. The isAdmin checks downstream read user.role from this fresh object — so revoking someone's admin role takes effect on their next reload, not "whenever the frontend feels like it".
3. Token dead — the catch wipes everything: localStorage, user, token. A dead token never lingers. The app lands on the signed-out state honestly, instead of showing a dashboard shell that 401s on every widget.

Note the ordering in the catch: remove from localStorage first, then clear state. If the component unmounts mid-cleanup or something throws, the next reload still starts clean. Persistent storage is the source of the ghost session; clear the persistence before anything else.

This is also why login and register don't need a separate "fetch the user" step — they get the user object in the same response as the token, through the same resource. But a reload has no fresh login response. /me is the re-validation that fills the gap.

The rule is simple: the token is a key, not an identity. Keys get you to the door; the person who answers decides who you are. One endpoint, called once per reload, and the ghost session never happens.

This session-restoration pattern ships in my Laravel + React SaaS Starter Kit ($19 one-time) — Sanctum auth, the /me re-validation, and an AuthContext that never trusts a stored token.

Here's the attack it enables: feed the endpoint a list of harvested emails. Every response of "incorrect password" confirms that address has an account; every "user not found" doesn't. After a few thousand requests, the attacker owns a verified list of your users' emails — perfect raw material for credential-stuffing and targeted phishing. You gave it away one helpful error message at a time.

My login deliberately can't tell you which half failed:

public function login(LoginRequest $request): JsonResponse
{
    $user = User::where('email', $request->validated('email'))->first();

    if (! $user || ! Hash::check($request->validated('password'), $user->password)) {
        return response()->json(['message' => 'Invalid credentials'], 401);
    }

    $token = $user->createToken('auth-token')->plainTextToken;

    return response()->json([
        'user' => new UserResource($user),
        'token' => $token,
    ]);
}

One condition, one response: Invalid credentials, 401. Unknown email and wrong password are indistinguishable from the outside — there is no timing channel in the message and no field-level hint. The React login page renders exactly this string under the form, so the frontend can't accidentally leak the distinction either.

What about honest validation?

This isn't the same thing as validation errors. If the email isn't an email, or the password field is empty, the LoginRequest still returns proper 422 field-level errors — that's honest, fixable input feedback, and it reveals nothing about the database. The silence only starts where the database gets involved. The line is: tell the user what's wrong with what they typed; never tell them what's in your users table.

There's a second, quieter benefit: the response shape is identical on both paths, which keeps the frontend's error handling boring. One string, one status code, one render branch. The axios interceptor treats any 401 as a session problem uniformly — this endpoint's 401 fits that contract perfectly.

Security through less information isn't obscurity; it's just not handing out free reconnaissance. Every SaaS login I build gets this treatment, and it's a five-line decision.

This login-discipline pattern ships in my Laravel + React SaaS Starter Kit ($19 one-time) — honest 422 validation on the form fields, a single silent 401 for bad credentials, and a Sanctum token on success.

{
  "name": "Attacker",
  "email": "attacker@example.com",
  "password": "password123",
  "password_confirmation": "password123",
  "role": "admin"
}

If your controller does User::create($request->validated()) and role passes through validation, you just handed a stranger an admin account. No exploit, no SQL injection — just a form field your endpoint shouldn't have been listening to.

My register method doesn't read role from the request at all:

public function register(RegisterRequest $request): JsonResponse
{
    $user = User::create([
        'name' => $request->validated('name'),
        'email' => $request->validated('email'),
        'password' => $request->validated('password'),
        'role' => 'user',
    ]);

    $token = $user->createToken('auth-token')->plainTextToken;

    return response()->json([
        'user' => new UserResource($user),
        'token' => $token,
    ], 201);
}

Two things make this airtight. First, RegisterRequest has no role rule — so validated() never carries a role through, even if one was sent. Second, 'role' => 'user' is hardcoded server-side at creation. The attacker can post "role": "admin" all day; the value never reaches the model. Privileges are assigned, never requested.

Where role assignment actually lives

Role assignment does exist in the kit — it just lives behind the admin gate. StoreUserRequest validates 'role' => ['required', 'string', 'in:admin,user'], and that request is only used by UserController, whose routes sit behind auth:sanctum plus the role:admin middleware:

Route::middleware(['auth:sanctum', 'role:admin'])->group(function () {
    Route::apiResource('users', UserController::class);
});

So the rule of the system is simple: the only way a role value enters the database is through an admin's hands, on an admin-only route, validated to exactly admin or user. The public register path cannot express the concept of a role at all — not by omission, but by construction. That's the level you want: not "we check it" but "there is nothing to check".

One line of hardening you can steal today: in your own register handler, find where the role comes from. If the answer is anything other than a server-side constant, fix it.

This is the role-guard pattern I ship in my Laravel + React SaaS Starter Kit ($19 one-time) — registration always creates a regular user, and only admins behind the role middleware can promote accounts.

My kit handles it in about thirty lines across two files. Here's the whole thing.

The catch-all route

In App.jsx, the last route in the list is:

<Route path="*" element={<NotFound />} />

React Router matches routes top to bottom, so the wildcard sits last and catches everything unmatched. The NotFound page is a full-screen, branded dead end — big "404", "Page not found", the honest line "The page you're looking for doesn't exist or was moved", and one indigo "Go home" button linking back to /. No stack trace, no developer furniture. The user did nothing wrong; don't make them feel like they did.

The explicit /404 route

Right next to it:

<Route path="/404" element={<NotFound />} />

Why have both? Because sometimes you want to send someone to the 404 on purpose — a user profile that no longer exists, a resource your loader can't find. Having a real, linkable 404 route means "not found" is a destination your code can navigate to, not just a fallback the router trips over.

The redirect that cleans up after itself

Old habits die hard, so the kit keeps one alias:

<Route path="/home" element={<Navigate to="/" replace />} />

/home sends you to /, and the replace prop is the important part: it replaces the history entry instead of pushing. Without replace, the dead alias sits in the browser history — the user presses back and lands on /home again, which bounces them forward again. An infinite loop of politeness. replace means the alias never existed as far as the back button is concerned.

The basename trick for sub-path deploys

The router gets its basename from Vite's build config:

const basename = import.meta.env.BASE_URL.replace(/\/$/, "") || "/";

This is the line that lets the same build run at the domain root and under a sub-path like GitHub Pages (/my-app/). Vite's base option bakes the sub-path into BASE_URL; the router reads it at runtime, so every <Link> and every route works in both deployments. Strip the trailing slash, fall back to /. Without this, your 404 page works locally and breaks the moment the app is deployed under a prefix — exactly the kind of bug you discover from a client's screenshot.

The honest version

None of this is clever. That's why it belongs in a starter kit: dead-end handling is the kind of thing every developer agrees is important and nobody writes on day one. Ship it on day one. A user who hits a friendly 404 with a way home still trusts your product; a user who hits a blank tab does not.

The 404 page, the redirect map, and the sub-path-safe router setup ship in my Laravel + React SaaS Starter Kit (https://kamranofficial.gumroad.com/l/mhekoig), a $19 one-time starter with Sanctum auth, role-based access, and an admin dashboard.

In my kit, the entire authenticated shell is one component: Layout.jsx. Every protected page renders inside it through react-router's Outlet. New page, same chrome, zero duplication.

One wrapper for all protected routes

In App.jsx, the layout itself sits behind the auth guard:

<Route element={<ProtectedRoute><Layout /></ProtectedRoute>}>
  <Route index element={<Dashboard />} />
  <Route path="/users" element={<AdminRoute><Users /></AdminRoute>} />
</Route>

Notice what this buys: the sidebar, the header, the user chip, and the logout button are all inside ProtectedRoute. A signed-out visitor never sees any of them — not even a flash — because the layout is a child of the guard, not a sibling. And the admin-only /users page gets a second, tighter guard (AdminRoute) around just that route. Two layers, each in exactly one place.

The header knows what page you're on

The top bar shows a title, and the layout maps the current pathname to a title with a plain object:

const pageTitles = {
  '/': 'Dashboard',
  '/users': 'Users',
};
const title = pageTitles[location.pathname] || 'SaaS Kit';

No route config to thread through, no context to provide, no prop drilling. Adding a page later means adding one line here, one route, one nav link. The fallback ('SaaS Kit') means an unlisted route still gets a sane header instead of an empty one.

The nav link that hides itself

The sidebar's Users link renders only for admins:

{isAdmin && (
  <NavLink to="/users" className={linkClass}>Users</NavLink>
)}

with isAdmin = user?.role === 'admin' read straight from the auth context. This is the visual twin of the AdminRoute guard on the route itself — the guard is the security, the conditional link is the manners. Never rely on hiding the link alone (anyone can type the URL), but never skip it either: a link to a page you're about to be bounced from is just a broken promise.

Active links get their styling from a single function:

const linkClass = ({ isActive }) =>
  isActive ? 'bg-indigo-600 text-white ...' : 'text-slate-300 hover:bg-slate-800 ...';

One function, one definition of "active". Six months from now, when a client asks for the active colour changed, there's one line to change.

The user chip and logout, done once

The bottom of the sidebar shows the signed-in user: an initial avatar, their name, and their role as a badge:

const initial = (user?.name || 'U').charAt(0).toUpperCase();

And logout is a small async handler:

const handleLogout = async () => {
  await logout();
  navigate('/login');
};

It awaits the context's logout (which hits the API and clears the token) before navigating. Fire-and-forget navigation here is a classic bug: you land on /login while the token is still being revoked, and a quick back-button press resurrects a half-dead session.

The honest version

A single layout component sounds boring, and it is. That's the point. The shell is the part of your app users see on every single screen — it's the last place you want five slightly different implementations. One Layout, one Outlet, one title map, one link style. Add pages freely; the chrome never drifts.

This shell — layout, protected routes, admin-gated nav, logout flow — ships in my Laravel + React SaaS Starter Kit (https://kamranofficial.gumroad.com/l/mhekoig), a $19 one-time starter with Sanctum auth, role-based access, and an admin dashboard.

In my SaaS kit, the dashboard is fed by exactly one endpoint, and that endpoint does four COUNT(*) queries. Nothing else. Here's why that design survived every client project I've put it in.

The endpoint: GET /dashboard/stats

The controller is the whole story, so here it is in full:

public function stats(): JsonResponse
{
    return response()->json([
        'total_users' => User::count(),
        'new_users_this_week' => User::where('created_at', '>=', now()->subWeek())->count(),
        'admins_count' => User::where('role', 'admin')->count(),
        'active_tokens' => PersonalAccessToken::count(),
    ]);
}

Four numbers, four queries, each one an aggregate the database computes without loading a single row into PHP. That's the principle: the frontend renders numbers, the database counts them. The moment you ship full user collections to the frontend and count them in JavaScript, you've coupled your UI to a payload that grows with every signup.

A few deliberate choices in there:

• It's behind auth:sanctum, not role:admin. These are cheap aggregates — any signed-in user can see them. The heavier, paginated users list stays behind the admin-only route. Don't gate cheap things; gate expensive things.
• now()->subWeek() for the "new this week" window — the boundary is computed server-side at request time, so there's no timezone argument between frontend and backend about what "this week" means.
• Active tokens come from Sanctum's own personal_access_tokens table. No extra tracking infrastructure, no events to fire. Sanctum already knows how many tokens exist; just ask it.

The frontend: one fetch, one loading state, no zombie updates

The dashboard page fires the stats request and — for admins only — a second request for five recent users, in parallel:

const [statsRes, usersRes] = await Promise.all([
  client.get('/dashboard/stats'),
  isAdmin ? client.get('/users', { params: { per_page: 5 } }) : Promise.resolve(null),
]);

Non-admins skip the second request entirely instead of fetching it and hiding it. That matters: don't burn a database query on rows the viewer is never allowed to see.

And because the dashboard unmounts when you navigate away mid-fetch, there's a cancelled flag in the effect cleanup:

useEffect(() => {
  let cancelled = false;
  async function load() {
    try {
      // ...requests...
      if (cancelled) return;
      setStats(statsRes.data);
    } catch (err) {
      if (!cancelled) setError(...);
    } finally {
      if (!cancelled) setLoading(false);
    }
  }
  load();
  return () => { cancelled = true; };
}, [isAdmin]);

Every setState is guarded. Without that, you get the classic React warning — a state update on an unmounted component — the first time a user clicks away before the spinner finishes. It's three lines. Write them every time.

The error path deserves the same care: a failed stats fetch renders a rose banner with the server's message (err.response?.data?.message), falling back to "Failed to load dashboard data." Never a blank dashboard. A dashboard that fails silently is worse than no dashboard — your client will stare at zeroes and assume they have no users.

The cards: one component, four accents

The stat cards are a single StatCard component taking label, value, icon, and accent. The accent maps to a Tailwind colour pair (indigo, emerald, amber, rose), and the value falls back to 0 when stats haven't loaded:

<StatCard label="Total Users" value={stats?.total_users ?? 0} icon={usersIcon} accent="indigo" />

Uniform cards mean uniform dashboards. When a client later asks for "one more metric", the change is a new key in the JSON and a new <StatCard> line — the component never changes shape, so the design never drifts.

The honest version

I've shipped dashboards where the numbers came from a cache, from a queue, from a materialised view. All fine at scale. But at the starter-kit scale — dozens to thousands of users — four indexed COUNT(*) queries run in milliseconds and are never stale, never out of sync, never "recomputed nightly". Start honest, optimise when the query log tells you to.

All of this — the stats endpoint, the parallel fetch with the cancelled guard, the StatCard component — ships in my Laravel + React SaaS Starter Kit (https://kamranofficial.gumroad.com/l/mhekoig), a $19 one-time starter with Sanctum auth, role-based access, and an admin dashboard that reads real rows from day one.

Register: strict, because the stranger is untrusted

// RegisterRequest
return [
    'name' => ['required', 'string', 'max:255'],
    'email' => ['required', 'string', 'email', 'max:255', 'unique:users,email'],
    'password' => ['required', 'string', 'min:8', 'confirmed'],
];

Everything required — a new account with no name or no email is a broken record. unique:users,email because a duplicate registration is either a confused user or an account-squatting probe; either way the API should say no. And confirmed: the stranger types the password twice, because a typo at registration means a permanently locked-out account and a support email. The cost of the extra field is one input; the cost of a mistyped password is a lost user.

Note what's not here: no role field. The register handler hardcodes 'role' => 'user'. A role field on the registration request would be a privilege-escalation form with extra steps — the strictest validation rule is the field that doesn't exist.

Login: minimal, because the check happens elsewhere

// LoginRequest
return [
    'email' => ['required', 'string', 'email'],
    'password' => ['required', 'string'],
];

No min:8. No confirmed. No unique. Login isn't creating anything, so there's nothing to constrain about the shape of the data — the only question is whether the credentials match, and that's the controller's job:

if (! $user || ! Hash::check($request->validated('password'), $user->password)) {
    return response()->json(['message' => 'Invalid credentials'], 401);
}

Adding min:8 to the login password would be actively harmful: a user whose old password is 7 characters (from before a policy change) would get a validation error instead of an authentication attempt — confusing, and it leaks the password policy to anyone probing the endpoint. Login validation should accept anything shaped like credentials and let the hash check decide.

The 401 message is deliberately flat: Invalid credentials, whether the email doesn't exist or the password is wrong. Distinguishing "email not found" from "wrong password" is an account-enumeration gift to attackers. The frontend renders the same message either way; the user who mistyped their email figures it out on the second try.

The rule

Match the strictness to the trust level of the actor, not the shape of the form. Strangers creating records get the full gauntlet: required fields, uniqueness, confirmation. Returning users proving identity get the minimum viable validation — then the real check. Two forms, two threat models, two rule sets. Anything else is either annoying your users or informing your attackers.

These are the exact FormRequests in my Laravel + React SaaS Starter Kit ($19 one-time) — Sanctum auth with validation that matches the threat model, plus roles and an admin dashboard.

I don't return models from my API. Every user-shaped response goes through one resource:

class UserResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'email' => $this->email,
            'role' => $this->role,
            'email_verified_at' => $this->email_verified_at,
            'created_at' => $this->created_at,
            'updated_at' => $this->updated_at,
        ];
    }
}

Seven fields. That's the entire public contract for "a user" in my API — and it's a whitelist, not a blacklist. The difference matters: $hidden on the model is a blacklist ("don't show these"), which means every new sensitive column you add to the users table is exposed by default until someone remembers to hide it. The resource is a whitelist: a new column is invisible to the API until you deliberately add it. New things should be private by default.

One shape everywhere

The resource isn't just used on one endpoint. The auth responses use it too:

return response()->json([
    'user' => new UserResource($user),
    'token' => $token,
], 201);

Register, login, /me, the admin users list — all return the same seven-field user object. That consistency is a frontend feature: the React app has one user shape to model, one TypeScript-ish expectation, no "this endpoint includes the role but that one doesn't" surprises. When the frontend team is you, you still benefit — you stop defensive-coding around shape differences that shouldn't exist.

It also composes with pagination for free. UserResource::collection($users) wraps the paginated result and applies the same whitelist to every row, so the admin users table gets fifteen consistently-shaped users per page with zero extra thought.

The part people skip: the resource is also documentation

When someone asks "what does the user object look like?", I point at one file. Not a wiki page, not a Postman collection that drifted three months ago — the actual code that produces the response. If the shape changes, the file changes, and the documentation is never stale because it is the implementation.

Seven fields, whitelisted, in one file, used on every endpoint. That's the whole discipline. APIs leak through their shapes long before they leak through their auth.

This is the response-shaping discipline I ship in my Laravel + React SaaS Starter Kit ($19 one-time) — every user endpoint returns the same resource, behind Sanctum auth and role middleware.

The seam: one branch in the client factory

The axios client is created in one place, and that place has exactly one fork:

const client = isDemoMode() ? createDemoClient() : axios.create({
  baseURL: `${import.meta.env.VITE_API_URL || 'http://localhost:8000'}/api`,
  headers: {
    Accept: 'application/json',
  },
});

isDemoMode() reads the build-time flag VITE_DEMO_MODE. When it's true, every API call the app makes goes to createDemoClient() — an in-memory mock that mirrors the real Laravel endpoints and response shapes. When it's false (the shipped product), it's the real axios client against the real API.

The key decision: the mock mirrors response shapes, not just endpoints. It returns the same JSON the Laravel API returns — same fields, same pagination envelope — so the React components can't tell the difference. Login "works" (any credentials, or the seeded admin), the dashboard shows stat cards, the users table paginates. A screenshot can't show you the 401-interceptor redirecting on an expired token; the clickable demo can.

Why a seam, not a separate demo build

The alternative is maintaining two frontends: the real app and a demo variant with hardcoded data. That rots in a week — every feature you add to the real app has to be re-faked in the demo, so the demo quietly becomes a lie about what the product does.

The seam inverts the maintenance burden. Components call client.get('/users') either way; the only thing that changes is what client is. New feature, new endpoint? You add it to the mock once, in the same file as the real client, and the demo stays honest. The demo is never more than one endpoint behind the product, because they're the same codebase.

The sample data is seeded in code — an admin (admin@demo.io) plus a handful of users — so the demo is deterministic. Every visitor sees the same dashboard, the same users table. Deterministic demos are debuggable demos: if a buyer reports something weird in the preview, I can reproduce it exactly.

The rule

If your product's best sales pitch is "try it", make "try it" cost you nothing to maintain. One branch at client-creation time, a mock that respects your real response shapes, and your demo is a build flag away — always current, always clickable, never a separate codebase to babysit.

The kit this comes from is my Laravel + React SaaS Starter Kit ($19 one-time) — Sanctum auth, roles, admin dashboard, and the demo seam above, which is exactly what powers the live preview: https://kamran1272.github.io/laravel-react-saas-starter-kit/

The whole setup

In the axios client:

const client = axios.create({
  baseURL: `${import.meta.env.VITE_API_URL || 'http://localhost:8000'}/api`,
  headers: {
    Accept: 'application/json',
  },
});

And in .env.example:

VITE_API_URL=http://localhost:8000

That is the entire mechanism. The React app calls the Laravel API directly, cross-origin, and everything else follows from that one decision.

Why not a proxy

A Vite proxy (server.proxy: { '/api': 'http://localhost:8000' }) makes dev feel tidy — same origin, no CORS. But it is dev-only stagecraft. The moment you deploy, the proxy is gone and you need real cross-origin behaviour anyway: proper CORS headers, absolute API URLs, credentials handled explicitly. I would rather deal with the real setup on day one than debug the difference between "works behind the proxy" and "works in production" at 1am during a launch.

So the kit does the honest thing instead:

• CORS is configured on the backend, not hidden by the dev server. config/cors.php covers the api/* paths, with allowed origins derived from the frontend URL — so the browser permits the cross-origin calls in development and you control exactly which origins are allowed in production.
• Accept: application/json is set on every request at the client level. This is the quiet one. Without it, a validation failure or an unauthenticated request can come back as a Laravel HTML error page or a redirect to /login, and your React code is left parsing HTML it never expected. One header guarantees the API always speaks JSON to the frontend.

The env var contract

VITE_API_URL with a localhost fallback means a fresh clone works with zero configuration — php artisan serve on one terminal, npm run dev on the other, and the app talks to the API. When you deploy, you set VITE_API_URL to the live API URL before building. (Vite bakes env vars in at build time, so this is a build setting, not a runtime one — set it in your build environment, not on the server afterwards.)

One variable, one contract: the frontend always knows where the API lives, in every environment, with no dev-server magic that evaporates in production.

Boring infrastructure is good infrastructure. The clever proxy setup impresses nobody after the first deploy.

The kit this comes from is my Laravel + React SaaS Starter Kit — Sanctum auth, roles, admin dashboard, and the dev wiring to run it all in five minutes. $19, one-time: https://kamranofficial.gumroad.com/l/mhekoig

I fixed this once, properly, and now it ships in every starter I touch. It is three lines in the controller.

The guard

In my kit's UserController@destroy, the first thing that happens is not the delete. It is a self-check:

public function destroy(Request $request, User $user): JsonResponse
{
    if ($request->user()->is($user)) {
        return response()->json(['message' => 'You cannot delete your own account.'], 422);
    }

    $user->tokens()->delete();
    $user->delete();

    return response()->json(null, 204);
}

$request->user()->is($user) uses Eloquent's model comparison, so it is a real identity check, not a loose == on IDs that could be spoofed by type juggling. If the admin targets themselves, they get a 422 with a plain-English message.

Why 422 and not 403? Because 403 says "you are not allowed to do this" — but the admin is allowed to delete users. The request is well-formed and authorised; the action just makes no sense for this particular resource state. 422 (Unprocessable Entity) is the honest status: I understood you, and the answer is no. Your frontend can then show the message verbatim instead of a generic "forbidden" toast.

Clean up the tokens first

The second line most people skip: $user->tokens()->delete() before $user->delete().

This kit uses Laravel Sanctum personal access tokens. If you delete the user row without revoking their tokens, the token rows sit orphaned in personal_access_tokens. They will never authenticate again (no user to resolve to), but they pollute the table — and in my case they would inflate the dashboard's "active sessions" count, which is a straight PersonalAccessToken::count(). One line keeps the data honest.

Return nothing on success

A successful delete returns 204 with no body. There is nothing to say. The frontend already removed the row optimistically; a 204 confirms it. I see APIs returning the deleted user object "for confirmation" — that is a habit from tutorials, not something any client I have built actually needed.

The frontend half

On the React side, the users table renders Edit and Delete buttons per row from the same endpoint. The backend guard is the real protection — never trust a disabled button alone, because anyone can call the API directly. But the backend returning a clear 422 message means the UI can display exactly what happened instead of guessing.

This is the kind of unglamorous detail that separates a demo from a product. Nobody will praise your self-delete guard. They will only ever notice its absence, at the worst possible moment.

I keep a running collection of these small, load-bearing decisions in the Laravel + React SaaS Starter Kit I sell — Sanctum auth, role-based access, the admin dashboard, and the seed data to demo it all in five minutes. It's $19, one-time, here: https://kamranofficial.gumroad.com/l/mhekoig

My starter kit ships the middle path, and I want to defend it, because the middle path is almost always the right call.

What the endpoint does

public function index(Request $request): AnonymousResourceCollection
{
    $users = User::query()
        ->latest()
        ->paginate(15)
        ->withQueryString();

    return UserResource::collection($users);
}

Four decisions in four lines:

1. latest() — newest users first. In an admin panel, you almost always care about who just signed up. Default chronological order (oldest first) is a database habit, not a product decision.
2. paginate(15) — fifteen rows per page. Not ten, not fifty. Fifteen fits a viewport without scrolling fatigue and keeps every query cheap. Do not bikeshed the number; pick one and move on.
3. withQueryString() — the pagination links carry the current query string forward. Today that barely matters. The day you add ?role=admin filtering, your page-2 link will not silently drop the filter. It is a one-word investment in your future self.
4. UserResource::collection() — the response shape is controlled by an API resource, not by whatever columns happen to be on the model. The day you add a last_login_at column, it does not leak into the admin table until you decide it should.

What it deliberately does not do

There is no search. No filters. No sortable columns.

This is not laziness; it is sequencing. Pagination is load-bearing — without it, the page breaks the moment a client imports their customer list. Search is a feature you add when an admin says "I can't find someone," which in my experience happens around month two, not day one. Every hour you spend building filters nobody requested is an hour your SaaS is not launched.

The honest version of "MVP" is not "broken." It is "complete for what it does."

The frontend stays dumb

The React table is a plain presentational component: name, email, a role pill, created date, and Edit/Delete actions per row. It takes users, onEdit, and onDelete as props and knows nothing about pages, totals, or API shapes. The page component that wraps it owns the fetching and the pagination controls.

This split matters more than it looks. When I add search on day thirty, the table component does not change at all — only the data-fetching layer grows a query parameter. Presentational components that do not know about the API are components you never have to rewrite.

Ship the boring table first. Make it correct, paginated, and stable. The fancy table can wait until someone is paying you to build it.

This is the same pragmatic sequencing I baked into my Laravel + React SaaS Starter Kit — auth, roles, and an admin dashboard with user management that works on day one, not day thirty. $19, one-time: https://kamranofficial.gumroad.com/l/mhekoig

The pattern I use now: one middleware, one alias, zero role checks in controllers.

The middleware itself is tiny. It takes a variadic list of allowed roles, grabs the authenticated user off the request, and returns a JSON 403 if the user's role isn't in the list:

public function handle(Request $request, Closure $next, string ...$roles): Response
{
    $user = $request->user();

    if (! $user || ! in_array($user->role, $roles, true)) {
        return response()->json(['message' => 'Forbidden'], 403);
    }

    return $next($request);
}

Registered once as the role alias, it's used at the route level, never in controller code:

Route::middleware(['auth:sanctum', 'role:admin'])->group(function () {
    // every user-management route lives here
});

Three details worth stealing:

1. Variadic roles, not a boolean. role:admin today, role:admin,moderator tomorrow — no new middleware, no new alias, no controller changes. The day a client asks for a second privileged role, you change one line in the routes file.

2. JSON 403, not a redirect. For an API, a non-admin hitting an admin endpoint gets {"message": "Forbidden"} with a 403 status — something the frontend can actually handle. A redirect to a login page (Laravel's default for web routes) would be nonsense for an API consumer. This only works because the whole API is JSON-first: no HTML error pages anywhere, so the frontend never has to guess what it received.

3. Middleware order is the contract. auth:sanctum runs first, so by the time the role check executes, $request->user() is guaranteed to exist or the request was already rejected with a 401. The role middleware never has to think about unauthenticated requests as a separate case — it just also handles a null user defensively.

Then the frontend mirrors it. An AdminRoute component wraps every admin page: while auth is still loading it shows a spinner; with no user it redirects to /login; and if user.role !== 'admin' it redirects to / — the admin pages simply don't exist for regular users. Backend enforcement is the real security (never trust the frontend), but the frontend guard is what makes the product feel right: users never see pages they can't use.

The principle: authorisation logic lives in exactly one place per layer. One middleware on the backend, one route guard on the frontend, and the controllers stay blissfully unaware that roles exist.

This exact setup — the variadic role middleware, the admin route group, and the matching AdminRoute guard — ships in my Laravel + React SaaS Starter Kit ($19 one-time). Roles done properly on day one, not refactored in month three.

The fix is unglamorous: one axios client module that every API call goes through. Mine is a single client.js, and it does four jobs:

1. One base URL. baseURL comes from VITE_API_URL with a localhost fallback, plus /api. Every request in the app is relative to it. Moving from local dev to production is one environment variable, not a find-and-replace across the codebase.

2. JSON everywhere. A default Accept: application/json header. This matters more than it looks: when something goes wrong server-side, you get a JSON error you can render — never an HTML error page crashing your .json() parse. (My Laravel side holds up its end too: clean JSON 401/403/404/422 responses, no HTML anywhere.)

3. Bearer injection via a request interceptor. Before every request, the interceptor reads the token from storage and sets Authorization: Bearer <token>. Components never touch headers. They just call client.get('/users') and auth is handled.

4. 401 auto-logout via a response interceptor — with one guard that matters. On a 401, the interceptor clears the stored token and sends the user to /login. But it skips this when the user is already on /login or /register. Why? Because a wrong password on the login form also comes back as a 401. Without the path check, a failed login would wipe your (already empty) state and bounce you in a redirect loop instead of showing "invalid credentials." That guard is the difference between a pattern that works in the demo and one that works in production.

One more thing this buys you: a clean seam for demo mode. My client checks a VITE_DEMO_MODE flag at startup. When it's on (public preview builds), it swaps the real axios instance for an in-memory mock that mirrors the real API's endpoints and response shapes. The rest of the app can't tell the difference — same client.get, same shapes. The preview site is fully clickable with no backend running, and the shipped product defaults to the real Laravel API. One conditional at the boundary, zero conditionals in the components.

The rule I follow: if two files both import axios directly, that's a bug. There is one client, it owns auth, and everything else is just business logic.

This exact client — interceptors, the 401 path guard, and the demo-mode seam — ships in my Laravel + React SaaS Starter Kit ($19 one-time). Wire it up once and never think about auth headers again.

I used to handle this badly. My early SPAs re-fetched the user on every route change, or kept the user object only in memory so a refresh wiped it. Both are wrong. The pattern I ship now is simple and boring, which is exactly what auth plumbing should be:

1. The token lives in localStorage. When login succeeds, the API returns { token, user } and the token is stored under a single key (saas_token in my case). One key, one place, no exceptions.
2. On app mount, the token is validated — not trusted. AuthProvider reads the stored token and calls GET /auth/me. If the token is dead (revoked, expired, garbage), the API says so, the token is deleted from storage, and the user is genuinely logged out. Never trust a token you haven't checked.
3. A loading flag gates every route. This is the part people skip. While the restore check is in flight, protected routes render a spinner — not the login page, not the dashboard. ProtectedRoute only decides once loading is false: no token or no user → redirect to /login. That single flag is what kills the login-page flicker.

The logout side deserves the same discipline. My logout function calls POST /auth/logout but treats it as best-effort: even if the request fails (server down, network dead), the local token is removed and the user state is cleared. The user's session is over the moment they say so, not the moment the server acknowledges it. A logout button that spins forever because the API is unreachable is a bug, not a feature.

A few things this pattern gets you for free:

• No prop-drilling auth state. useAuth() exposes { user, token, loading, login, register, logout } anywhere in the tree.
• Register and login share one path. Both store the token and set the user the same way — one code path to get right instead of two.
• Dead tokens can't linger. Any failed /auth/me wipes storage immediately, so you never have a "logged in but every request 401s" zombie state.

The whole thing is maybe 60 lines. Auth plumbing should be boring enough that you never think about it again — that's the test. If your auth code is exciting, something is wrong.

I ship this exact AuthContext — token persistence, /auth/me restore, the loading gate, best-effort logout — in my Laravel + React SaaS Starter Kit ($19 one-time). Clone it and your auth is done on day one instead of week two.

The register tests: guarding the front door

public function test_register_returns_token_and_user(): void
public function test_register_cannot_self_assign_admin_role(): void

The second one is the interesting one. Registration accepts a name, email, and password — and nothing else. The test tries to sneak role: admin through the register endpoint and asserts it fails. This is a privilege-escalation guard: mass-assignment is one of those bugs that works perfectly in every demo and ruins you in production. The test makes sure the role can never be set by the person signing up.

The login tests: the 401 has to be JSON

public function test_login_returns_token_and_user(): void
public function test_login_with_wrong_password_returns_401(): void

The kit is a JSON-first API — there are no HTML error pages anywhere. That matters more than it sounds: a React frontend that gets an HTML login page back from a 401 will happily try to parse it as JSON and die in a confusing way three layers from the actual problem. There's a dedicated test for exactly this:

public function test_me_without_accept_header_returns_json_401(): void

It calls the authenticated /me endpoint without an Accept: application/json header and asserts the 401 comes back as JSON anyway. APIs get called by mobile apps, scripts, and forgetful frontends; the error format shouldn't depend on the caller being polite.

The permission tests: admins see users, users don't

public function test_non_admin_cannot_list_users(): void
public function test_admin_can_list_users(): void
public function test_me_requires_authentication(): void

The users list endpoint is admin-only. The negative test — a regular user getting rejected — is the one that matters. Positive tests ("admin can list users") tell you the feature works. Negative tests tell you the lock works. When I'm reviewing auth code, I look for the negative tests first; a permission system with only positive tests is a lock nobody tried to pick.

What this discipline buys you

Ten tests run in seconds with php artisan test. They don't prove the absence of bugs — nothing does. What they do is make the scary changes safe: refactoring the middleware, touching the register controller, reordering routes. Each test names a specific disaster (privilege escalation, HTML error leak, data exposure to non-admins) and asserts it stays impossible. When a future me — or a buyer of the kit — changes the auth code at 2 AM, these tests are the colleague looking over their shoulder.

If you're building a SaaS API, write the negative tests first. test_non_admin_cannot_list_users will catch more real-world damage than any happy-path test ever will.

These tests ship with my Laravel + React SaaS Starter Kit ($19 one-time) — Sanctum auth, role-based access, and an admin dashboard, all covered. Ten tests, zero excuses.

So when I built my Laravel + React SaaS starter kit, I set one hard rule: a stranger on a fresh machine should go from zip file to a logged-in dashboard in under five minutes. Here's exactly what that took.

Ship the database pre-seeded

The biggest friction killer was embarrassingly simple: the kit ships with a pre-seeded database/database.sqlite. SQLite needs zero config — no MySQL server, no Docker, no credentials — and the demo data is already inside. The quick-start docs say this explicitly:

Do NOT run php artisan migrate --seed. The kit ships with a pre-seeded database, so the demo works out of the box.

Re-running the seeder is harmless (it's idempotent — more on that in a second), but the point is you never need it for the first boot. migrate:fresh --seed exists only for when you want a clean reset.

Make the seeder idempotent anyway

First-boot and day-thirty are different people. On day thirty, a buyer runs the seeder on a half-populated database and nothing should break. So the seeder uses firstOrCreate for the demo admin (admin@demo.io) instead of blind inserts, and it tops the demo users up to nine total rather than inserting a fixed batch:

User::firstOrCreate(
    ['email' => 'admin@demo.io'],
    ['name' => 'Admin', 'password' => 'password', 'role' => 'admin'],
);

// Top the demo users up to 9 total (1 admin + 8 users).
$missing = 9 - User::count();
if ($missing > 0) {
    User::factory($missing)->create();
}

Existing records are left untouched; only missing demo data is created. Safe to run on every deploy, every restart, with zero fear.

Keep the two-server dance to four commands each

The actual setup is two blocks. Backend:

cd backend
composer install
cp .env.example .env
php artisan key:generate
php artisan serve --port=8000

API is live at http://localhost:8000/api. Frontend:

cd frontend
npm install
cp .env.example .env   # VITE_API_URL defaults to http://localhost:8000
npm run dev

Open http://localhost:5173 and log in with admin@demo.io / password — or register a fresh account, which gets the user role automatically. That's the whole ceremony. No seed commands, no queue workers, no "now open three terminals and a database GUI."

Delete the demo furniture before production

One honest detail: the login page ships with a "Demo credentials" hint box so evaluators find the admin account instantly. That's a feature during evaluation and a liability in production. The README tells the buyer exactly what to remove — the <div> rendering the demo credentials in frontend/src/pages/Login.jsx — before deploying. Little touches like this are what separate a kit someone evaluates from a kit someone ships.

The real lesson

None of this is clever engineering. Pre-seeded SQLite, idempotent seeders, four-command setups, a documented cleanup step — it's all just respecting the evaluator's time. The first impression of your product isn't the landing page. It's how many minutes pass before they see it working.

I packaged all of this — the pre-seeded database, the idempotent seeders, the five-minute setup — into my Laravel + React SaaS Starter Kit ($19 one-time). If you'd rather skip the two weeks of boilerplate, it's there.