Core Laravel Package

Product Decisions This Supports

• Build vs. buy for a backtesting capability. If the roadmap includes strategy simulation, historical replay, or "would this strategy have made money" features, this package is a candidate to short-circuit a 3–6 month build. The decision it informs is narrow and concrete: do we write our own order/portfolio simulation engine, or adopt one?
• Feature scoping for a research/analysis surface. A backtesting engine implies a downstream product shape — strategy definitions, parameter sweeps, run history, result comparison, equity curves. Adopting it commits you to a data model (strategies, runs, metrics) that will leak into your schema and UI. Make that decision deliberately, not as an implementation detail.
• Internal tooling vs. customer-facing feature. The realistic near-term use case is an internal research console for analysts/quant-curious stakeholders, not a shipped, SLA-backed customer feature. This framing changes the risk calculus substantially.
• Roadmap sequencing. If backtesting is a "someday" item, this is a cheap way to run a timeboxed spike and answer "is there demand?" before committing engineering headcount.
• Buy/build/borrow for adjacent capabilities. This package addresses simulation only. It does not answer market data ingestion, exchange connectivity, live execution, or portfolio accounting — those remain separate build/buy decisions and are likely the larger cost centers.
• Not a decision this supports: anything involving real capital, live order routing, or regulated reporting. Nothing here is positioned for that.

When to Consider This Package

Consider it when:

• The need is internal, non-customer-facing, and non-production-critical — a research tool where a wrong number is annoying, not litigating.
• You are PHP-first and want to avoid introducing a Python service (backtrader, vectorbt, zipline) plus its deployment, data-sharing, and on-call surface. Keeping the engine in-process with the app is a genuine architectural win.
• You need a proof of concept in weeks, not quarters, and are prepared to treat the package as a starting point rather than a dependency.
• You have Symfony literacy on the team (or tolerance for it). Laravel sits on Symfony components but is not a Symfony app — expect to run this as a separate console process or boot a Symfony kernel/container alongside Laravel rather than composer require and forget.
• You are willing to vendor/fork under MIT and own patches. With 14 stars and zero dependents, assume single-maintainer risk and no support contract.
• The alternative is genuinely worse — i.e., your team would otherwise hand-roll event loops, slippage models, and commission accounting badly.

Look elsewhere when:

• The capability is customer-facing or revenue-bearing. Thin community + zero dependents + no maintainer SLA is not a foundation for something you'll be paged about.
• You need exchange/broker integrations, live market data, or execution. Scope this package as simulation-only and evaluate connectivity separately — do not let it imply a trading platform.
• You need performance at scale (large parameter sweeps, tick-level data). A PHP engine will be the bottleneck; a Python/NumPy stack will win decisively and the cost of the extra service is usually cheaper than the cost of rewriting.
• Laravel-idiomatic developer experience matters. Forcing a Symfony bundle architecture into a Laravel codebase creates a permanent seam that every new engineer has to learn. That's a real, recurring tax.
• You need vendor support, security review, SOC2, or a maintenance commitment. None of that exists here.
• The team has no quant/trading domain expertise. The framework provides primitives; it will not tell you whether your backtest methodology is sound, and a plausible-looking wrong backtest is worse than no backtest.

Non-negotiable adoption hygiene: wrap it behind an internal interface (a BacktestEngine port with an adapter). The integration cost is a few days; the option value is that swapping to a Python engine later is a refactor, not a rewrite.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a candidate open-source component — stochastix/core, an MIT-licensed backtesting engine — that could let us demonstrate a strategy-simulation capability in weeks instead of the quarter-plus a from-scratch build would take. The trade-off is maturity: 14 GitHub stars, no downstream dependents, and a single-maintainer profile, which means no support and a real chance we end up maintaining it ourselves. My recommendation is to treat it as a timeboxed spike (2–3 weeks) behind an internal interface, not as a production dependency. That buys us a working demo and hard data on whether backtesting demand is real, at low cost and near-zero lock-in, and preserves the option to replace the engine later without touching product code. It does not address live trading, market data, or execution — those remain separate decisions we should not conflate with this one.

For engineering:

• Integration shape: run it as an isolated console/worker process rather than embedding a Symfony kernel inside the Laravel app. Communicate via a queue job + result table. Keeps dependency risk, boot cost, and version conflicts contained.
• Seam: define our own BacktestEngine interface; the package sits behind an adapter. Our domain models (Strategy, Run, Result, Metric) must not mirror the package's.
• Ownership: vendor the source or pin a commit SHA. Do not rely on dev-main. Assume we patch it and budget accordingly.
• Correctness: backtest results are persuasive and easily wrong. Require at least one hand-verified reference scenario (known strategy, known fills, known P&L) as a regression fixture before anyone puts a number in front of a stakeholder.
• Exit criteria for the spike: measurable — a strategy defined in our own schema runs end-to-end, results match the reference fixture, and we can state with evidence whether we'd rather maintain this or stand up a Python service.