Gender Laravel Package

Product Decisions This Supports

• Shipping an inclusive gender field without owning the taxonomy. v1.1.0 adds an optional extended set (Facebook-derived) alongside the existing/default set. This lets product choose per surface and per market: minimal set for low-friction signup, expanded set for profile editing or markets where users expect it.
• Progressive disclosure and self-description on the roadmap. An opt-in extended list is a stepping stone to "self-describe" free text and pronoun fields; treat the package as the option catalogue, not the whole identity model.
• Build vs. buy. The value here is the curated option list plus Laravel glue (config, validation rule, casts/accessors) — cheap to adopt, cheap to replace. v1.1.0 is additive and non-breaking, so it can be trialled behind a flag with near-zero switching cost.
• Data-model decision: store gender as a string (or JSON), not a DB enum. The extended set is explicitly mutable — Facebook's own list has changed over time. A column enum or check constraint would turn a composer update into a migration, and every future taxonomy change into a release.
• Segmentation and personalization decisions. Decide whether gender feeds analytics, recommendations, or matching, and document it; the package supplies the vocabulary, not the policy.
• Compliance and wording. Gender is sensitive personal data in many regimes (GDPR special-category arguments, children's data rules). Collect optionally, minimize, state purpose, and never use it for eligibility or pricing decisions. "Prefer not to say" and field-optionality are product decisions the package should not make for you.
• Market rollout. Which locales get the extended set, whether labels are translatable, and whether the list is shown as a select, radio group, or searchable picker.

When to Consider This Package

Consider it when:

• You are on Laravel and need a validated gender field in signup/profile forms, with a sane default list and an opt-in expanded list.
• You want the extended set to be a configuration flag, not a fork — v1.1.0's additive, opt-in design is exactly the low-risk shape you want.
• You store gender as a string and want validation rules and casting handled once rather than copy-pasted across models and form requests.
• You want to defer building and maintaining a taxonomy until product has actually decided the policy.

Look elsewhere (or build a small internal config + enum) when:

• You need legal sex for KYC/AML/ID verification. That is a separate, regulated field with its own retention rules; do not conflate it with gender identity.
• You need a full identity model (pronouns, multiple identities, self-describe text, per-locale labels) — that is a domain model, not an option list.
• You need audited data handling, DPIA support, or a vendor with a support contract; a single-maintainer utility package is not that.
• You are not on Laravel, or you want the option list to be governed by your own editorial process.
• You cannot verify basic hygiene: license, test coverage, maintenance cadence, whether the extended set is translatable, and whether unknown/legacy stored values are handled gracefully on read.

How to Pitch It (Stakeholders)

For executives: We can ship an inclusive gender field in days instead of designing an option taxonomy from scratch. The new v1.1.0 release adds an opt-in expanded option set — it is a minor, backward-compatible change with no migration and no user-visible impact until we enable it. The cost is a small open-source dependency. The real decisions are policy ones: which markets get the expanded list, whether the field is optional, how we word it, and how long we retain it. Risk is low and reversible; pinning the version and gating it behind a feature flag keeps it that way.

For engineering: Additive release, opt-in via config; no breaking changes. Requirements: keep storage as a string/JSON column so taxonomy updates never force migrations; wrap the option set in a feature flag; add a form test asserting accepted values, rejection of out-of-set values, and handling of previously stored values (including values dropped from a later list); confirm label translation support and license before adoption. If the package proves too thin, the fallback is a config array plus a validation rule — roughly a day of work — so this is not a lock-in decision.