Product Decisions This Supports
- Build vs. buy for authentication-adjacent work. The kit lands with working profile/password management, two-factor enrollment (QR code, manual secret fallback, recovery codes, and a confirmation step), and a pre-registered email-verification screen. That is a class of work that is expensive to build, easy to build wrong, and invisible to users when it works — a strong candidate for "start from a known-good baseline, spend the savings on the differentiating feature."
- Security posture as a launch requirement, not a later hardening sprint. Two-factor arriving on day one changes the conversation from "when can we afford 2FA?" to "do we turn it on for all users, admins only, or leave it optional?" The kit also re-asks for the password on the 2FA screen, mirroring what Fortify enforces server-side — a small detail that signals the flows were built against the framework's own expectations rather than invented.
- Feature-flag decisions with a real cost attached. Email verification is wired up but switched off, and turning it on is described as a single uncommented line. That gives us a concrete, low-effort lever for a policy decision (do we gate the product behind verified email before we have abuse problems?) rather than a scoping exercise.
- Roadmap sequencing for passwordless auth. Passkeys are explicitly not included, with a stated reason: Fortify supports them, but the WebAuthn browser ceremony isn't in the kit. That's an honest gap that maps directly to a roadmap line item — "passkeys" is now a scoped spike with a known missing piece (JS ceremony work), not a vague aspiration.
- Risk assessment on the codebase we're inheriting. 24 tests plus GitHub Actions running the suite on every push (with assets built first) is the minimum credible signal that this scaffold is maintained and that regressions get caught. For a starter kit, this is the difference between adopting a maintained baseline and adopting a snapshot.
- Onboarding and demo timelines. A single
laravel new --using=bluestarsystem/aura-starter-kit command means a new engineer or a stakeholder demo can reach a working authenticated app with settings and 2FA without a setup project. Useful for prototypes, internal tools, and evaluating whether a direction is worth pursuing.
When to Consider This Package
Consider it when:
- You are starting a new Laravel application and authentication, profile management, and 2FA are table stakes rather than the product. This is a greenfield, project-start decision — a starter kit is scaffolded once, not tracked as a dependency.
- You want Fortify's behavior without hand-rolling the UI. The flows are thin views over a framework-maintained backend, which is the lowest-risk shape for auth code.
- 2FA for admins or all users is on your near-term roadmap, and you'd rather ship it in week one than schedule it.
- You want a maintained rather than frozen baseline. CI on every push plus a meaningful test count suggests the template is exercised, not just published.
- You are prototyping or building an internal tool where time-to-first-feature dominates and a slightly opinionated UI is acceptable.
Look elsewhere when:
- Passkeys or full passwordless are a launch requirement. They are not here, and the gap is JavaScript/WebAuthn work you would own. If passkeys are the differentiator, either budget that spike explicitly or evaluate a kit that ships the ceremony.
- You need enterprise identity — SAML, SCIM, OIDC against a corporate IdP, granular RBAC, audit logging, session/device management. That is a buy decision (managed identity provider), not a starter-kit decision.
- You need a formal support contract, LTS guarantees, or a versioned upgrade path. A starter kit is a template: you copy it, you own it, and upstream improvements do not flow to you automatically. If that ownership model is a problem, stop here.
- You are adding auth to an existing application. The value is the scaffold; retrofitting a template into a live codebase is mostly cost.
- Your team already has a house auth pattern (an internal kit, Breeze/Jetstream conventions, a shared package). Two competing baselines is worse than one imperfect one.
How to Pitch It (Stakeholders)
For executives: This is a template that gives a new Laravel app a working account system — sign-up, login, profile, password change, and two-factor authentication — on day one, instead of a multi-week build. The commercial argument is time-to-first-feature: we skip the part users never notice and can't differentiate us, and spend that budget on the product. The security argument is that two-factor, recovery codes, and re-authentication on sensitive screens come from patterns the framework itself enforces, rather than from code we wrote under deadline pressure. The risk argument is modest and bounded: it's a starting point we copy and own, not a dependency we're locked into, and the project ships with an automated test suite that runs on every change.
For engineering: It's a starter kit (laravel new --using=...), so treat it as a one-time scaffold — we inherit the code and own it thereafter. The auth surface is thin views over Fortify, which keeps us on the framework's upgrade path. v0.3.0 adds the settings area (profile, password, 2FA with QR code, manual secret for users who can't scan, recovery codes, confirmation step), re-asks for the password on the 2FA page to match Fortify's server-side enforcement, wires up the email-verification screen while leaving the feature off behind a single line, and adds a GitHub Actions pipeline that builds assets before running the suite. 24 tests. Two things to flag going in: passkeys are deliberately absent — Fortify supports them but the WebAuthn browser ceremony isn't in the kit, so if passwordless is on the roadmap that's a scoped piece of JavaScript work we should size rather than assume; and because this is a template, upstream fixes won't arrive automatically, so we should decide early how much we intend to track it.
Ask: approve adoption for greenfield work where auth is not the differentiator; approve a timeboxed passkey spike only if passwordless is genuinely on the roadmap; and confirm email verification as a product decision (on or off) rather than leaving it as an unset default.