Levenify Bundle Laravel Package

Product Decisions This Supports

• Feature: fuzzy search / "did you mean" recovery. String similarity is the primitive under every typo-tolerant lookup. Whether we ship a two-sprint internal helper or buy a search platform (Algolia, Meilisearch, OpenSearch) is a real roadmap decision — and evaluating the primitive early stops us from buying a platform to solve a string-comparison problem.
• Feature: import dedupe and entity resolution. Bulk contact, supplier, and catalog imports generate duplicates. Weighted edit distance (cheaper transpositions, custom substitution costs) directly moves precision/recall on that flow — a measurable product metric, not a nice-to-have.
• Roadmap scoping. If native levenshtein() is sufficient for our data (ASCII, short fields, under 255 chars), fuzzy matching is a config change, not a roadmap line item. If our data is multilingual, accented, or has long free-text fields — or we need a normalized 0–1 score — it becomes real scope.
• Build vs. buy vs. borrow. MIT license plus a single algorithm means the realistic outcome is borrow: copy the scoring routine into an internal Support\StringSimilarity helper behind an interface. This package is most valuable as a reference implementation and benchmark baseline, not as a dependency.
• Use cases worth scoping now: typo-tolerant product/parts-number lookup, address and company-name normalization, KYC/sanctions name screening, autocomplete, CSV-import duplicate detection, "no results" fallback recommendations.
• Framework mismatch is itself the decision. Despite the "Laravel/PHP" framing, this is a Symfony 5 bundle. Laravel won't auto-discover it, and installing it risks pulling Symfony components that conflict with the versions Laravel already uses. That tilts us further toward vendoring the algorithm rather than composer require.

When to Consider This Package

Consider (as a spike or as source material):

• Native levenshtein() is genuinely insufficient: strings over 255 characters, UTF-8/multibyte input (accents, CJK), a need for a normalized 0–1 score, or non-uniform insert/delete/substitute weights (e.g., transposition should be cheaper than substitution for typing errors).
• You need an accuracy/latency baseline to compare against similar_text(), soundex(), metaphone(), Postgres pg_trgm/fuzzystrmatch, or a managed search engine — the package gives you a ready-made reference point.
• You are comfortable extracting the algorithm under MIT and owning ~100 lines internally with tests.

Look elsewhere / do not adopt as a production dependency:

• Maturity signals are disqualifying on their own: 3 stars, 0 dependents, single maintainer, no community vetting, no CVE-response expectation, no compatibility guarantee.
• Symfony 5 is end-of-life. A bundle pinned to it will not track framework or PHP upgrades, and its Composer constraints may conflict with the target Laravel version.
• It is one primitive, not a solution. No indexing, no scaling story, no multi-field or weighted-record matching, no tokenization — we build all of that ourselves regardless.
• If matching runs over a database or index, use the datastore's native fuzzy matching (Postgres trigram/GiST, OpenSearch/Meilisearch fuzzy queries) rather than N×M app-layer loops that won't survive our data volume.
• If you need an ensemble (phonetic + token + edit distance + normalization), use a maintained library, not a single-function bundle.
• Adoption gate: it must beat PHP's native levenshtein() / similar_text() on both accuracy and p95 latency against a labeled pair set from our own corpus. If it doesn't, there is no case.

How to Pitch It (Stakeholders)

For executives (one paragraph): "Fuzzy matching and duplicate detection are on the roadmap for imports and search. The cheap path is a small internal utility — roughly one to two sprints — not a vendor contract or a search-platform purchase. I evaluated this open-source package as a shortcut: it's MIT-licensed, so we can legally copy the algorithm into our own codebase. I recommend we do not take it as a dependency — it has three GitHub stars, zero downstream users, one maintainer, and targets Symfony 5, which is end-of-life. The risk isn't code quality; it's that nobody is accountable for it. The upside is identical either way: the algorithm is small enough to own, and owning it removes the supply-chain, licensing, and upgrade risk entirely."

For engineering (the ask): Run a bounded spike — two days, no production dependency.

1. Wrap the candidate behind a StringSimilarity interface with a native-PHP implementation as the default, so nothing couples to the bundle or its Symfony glue.
2. Build a labeled pair set (~500 real pairs: names, addresses, SKUs) with expected match/no-match labels.
3. Benchmark candidates — native levenshtein(), similar_text(), this routine, and Postgres pg_trgm — on precision/recall and p95 latency.
4. If a candidate wins, copy the MIT-licensed routine into our own namespace with attribution and unit tests for Unicode, emoji, combining characters, empty strings, and long inputs; if not, keep native and close the ticket.

Framing to use: "This is a $0 dependency decision with measurable upside, gated on evidence." The package earns its place as a benchmark baseline and a source of an algorithm we may legally adopt — not as a line in composer.json.