Conciseuuid Laravel Package

Product Decisions This Supports

• Identifier and URL strategy. Whether customer-visible resources (share links, permalinks, invite codes, order and ticket references) use 36-character UUIDs, guessable auto-increment integers, or ~22-character base62 strings. This is the primary decision the package serves.
• API contract shape. What id fields look like to external consumers: opaque and non-enumerable (defeats IDOR-style scraping and competitor enumeration) while staying short enough to paste in chat, print in a QR code, or read over the phone.
• Schema and cost-of-scale decisions. Primary key width and index footprint. Base62 over canonical hyphenated UUID text cuts key storage roughly 40%, which compounds across every foreign key and secondary index.
• Build vs buy vs use the framework. Laravel ≥9 ships HasUuids and HasUlids; this package is a small trait-plus-model. The real question is "vendor ~100 LOC, adopt a dependency, or use what's already in the box" — the package is one candidate in that comparison, not a foregone conclusion.
• Roadmap sequencing. Identifier format is effectively a one-way door once IDs appear in URLs, emails, exports, and partner integrations. This belongs in schema-design work for the current or next milestone, not in a later optimization epic.
• Retrofit cost estimation. If deferred, scope dual-write, redirect maps, and foreign-key rewrites explicitly — this is the number that justifies deciding early.
• Public vs internal ID separation. Whether to expose concise IDs externally while retaining native keys internally, or collapse the two.

When to Consider This Package

Consider it when:

• You are greenfield on Laravel/Eloquent and IDs are user-visible, where long UUIDs hurt UX (links, QR codes, SMS, verbal support).
• You need opacity — non-enumerable keys — but want shorter strings than canonical UUIDs.
• You want a drop-in Eloquent trait instead of owning encoding code and its edge cases.
• Your schema is still empty or pre-launch, so adoption cost is near zero.
• You value DB-agnostic string keys over database-native UUID functions.

Look elsewhere when:

• You are on Laravel 9+. Built-in HasUlids/HasUuids likely covers the need without a third-party dependency. This is the strongest counter-argument and should be checked first.
• You need RFC 4122 interop. External APIs, warehouses, SSO subject IDs, and webhooks expecting standard UUIDs mean transcoding at every boundary — permanent friction for a cosmetic gain.
• You need time-ordered keys at high write volume. Prefer a standard UUIDv7 implementation, ULIDs (lexicographically sortable), or a Snowflake/bigint approach rather than a small package.
• Production tables already exist at scale. Migration and foreign-key churn will outweigh byte savings.
• Supply-chain posture matters. 9 stars, 0 dependents, no ecosystem validation. Treat this as "copy the pattern," not "depend on the vendor" — the MIT license makes vendoring the trait into app/Concerns the low-risk path.
• Non-Laravel or non-Eloquent stacks, or teams relying on database-level UUID generation.

How to Pitch It (Stakeholders)

For executives: "We can make every customer-facing ID about 40% shorter and non-guessable, at essentially zero cost, by choosing our identifier format before we ship the schema. It's a small technical decision with a long tail — changing it afterward means rewriting URLs, redirects, exports, and partner integrations. Cost is a few engineering hours. Risk is low: the library is MIT and small enough that we can own the code outright if the maintainer walks away. This is not a roadmap item; it's a convention we settle during schema design."

For engineering: "Evaluate against Laravel's built-in ULID/UUID traits before adding the dependency — on Laravel 9+ this may be unnecessary. If we do adopt, vendor the trait rather than pinning a 9-star package, add collision and uniqueness tests, and assert ID length and format in the API contract test suite so the format can't drift silently. Decide now, while the schema is empty."

The ask: a 30-minute decision in the current design review — adopt, vendor, or use the framework's built-in trait — not a sprint of its own.