Formulate Laravel Package

Product Decisions This Supports

• Feature enablement — configurable business logic. A formula/expression engine lets you ship "user-editable math" once (pricing tiers, commission splits, tax and premium calculations, lead-scoring, KPI/derived metrics, dynamic form fields) instead of a code change and deploy per rule tweak. That is a product capability decision — who owns the numbers — not just a library choice.
• Build vs. buy vs. borrow. This package is only a credible answer to the "borrow" option: MIT-licensed, small, and readable, so it works as a reference implementation or fork candidate for the parsing/evaluation layer. It is not a "buy and forget" dependency at 12 stars, no release since 2016, and a 0.28 health score.
• Scope boundary for the roadmap. Adopting a 2016-era expression evaluator effectively freezes you at PHP 5.6/7.x semantics and gives you no security posture for evaluating user-supplied formulas. If formulas will be authored by customers or tenants, that is a security and audit decision, and it should push you toward a maintained, sandbox-capable engine rather than this one.
• Use cases it genuinely maps to: internal pricing/quotation calculators, insurance or lending premium estimators, scoring/ranking rules, payroll and invoicing line-item math, derived-metric definitions in reporting, and "advanced mode" fields where a power user enters an expression.
• Use cases it does not support: money math requiring decimal precision and unit safety, compliance/audit-trailed rule evaluation, or anything you'd have to explain to a security reviewer.

PM recommendation: fund a 1–2 day spike to validate the capability (formula-driven rules behind your own FormulaEngine interface), not a commitment to this package.

When to Consider This Package

Consider it when:

• You need a formula DSL for a prototype, internal tool, hackathon, or one-off script, and shipping in days matters more than longevity.
• You are on a legacy PHP 5.6/7.x stack that already pins old dependencies, so its age adds no new risk.
• You want a compact, readable example of tokenizing/parsing/evaluating math expressions to inform your own implementation or a fork.
• You will wrap it behind your own abstraction so it can be replaced without touching product code.

Look elsewhere when:

• You target PHP 8.x or need an actively maintained dependency with security advisories — this project has had no release since May 2016 and effectively no maintainer (bus factor ≈ 1, tiny user base).
• End users or tenants author the formulas — you need sandboxing, timeouts, allow-listed functions, and rate limits; do not hand-roll this around an unmaintained evaluator.
• You need money-grade precision, units, localization of number formats, or deterministic rounding.
• You want Laravel-native integration — there is no service provider, facade, config, or queue/cache integration here; you would write that glue yourself.
• Your rules are complex enough to want a rules engine (decision tables, chained rules, explainability) rather than a single expression evaluator.

Practical alternative to evaluate in the same spike: symfony/expression-language (maintained, registerable functions, cacheable parsed expressions, works fine inside Laravel) — and keep this package as the design reference.

How to Pitch It (Stakeholders)

To executives: "We can let the business change pricing, scoring, and fee rules without an engineering release — the engine evaluates a formula instead of us hardcoding each rule. That shortens the loop from a pricing decision to a shipped change from days to minutes. The specific open-source package we found is a 2016 artifact with a tiny user base and no maintainer, so I'm recommending we validate the capability with a short spike and adopt a maintained engine underneath our own interface — same product outcome, without betting the roadmap on an abandoned dependency."

To engineering: "rezzza/formulate is a small MIT PHP library for building and evaluating math expressions — useful as a spec and a fork candidate, not as a dependency: no Laravel bindings, no PHP 8 support, no releases in ~9 years. Proposal: define a thin FormulaEngine contract in our domain, backed initially by symfony/expression-language; allow-list functions, validate variable names, cache parsed expressions, and never eval() user input. This package's API informs the contract; it does not ship to production."