Product Decisions This Supports
- Instant quote / checkout feature: Lets the platform show filament length (meters), weight (grams), and estimated material cost the moment a user uploads a
.gcode file — a concrete, user-visible win for print-on-demand and quoting flows without building a slicer.
- Build vs. buy / adopt vs. build for cost estimation: Provides a ready parser for G-code metadata and extrusion moves. Adopting avoids weeks of parsing edge cases (Cura vs. PrusaSlicer vs. Simplify3D dialects, relative vs. absolute extrusion, firmware flavor quirks) for a non-differentiating capability.
- Roadmap item — "transparent job costing": Enables a pricing surface that breaks down material cost separately from machine time and labor, which supports margin instrumentation and customer trust ("why does this cost $X?").
- Print-farm / maker-space management use case: Batch-ingest uploaded jobs and aggregate estimated material consumption per queue, per printer, or per customer for capacity and procurement planning.
- Cost-per-job analytics and reporting: Feeds a small data model (job → filament grams → cost) that powers dashboards, invoices, and reorder/procurement signals without a hardware or telemetry dependency.
- Cheap experiment / discovery: Low adoption cost makes it viable to prototype a "get a quote in 10 seconds" flow, measure conversion impact, and only invest in a deeper production-grade solution if the metric moves.
When to Consider This Package
Consider it when:
- The product already (or will soon) accept
.gcode uploads and needs a pre-print material estimate; the alternative is slicing server-side, which is a much larger commitment.
- The requirement is specifically length / weight / cost of filament — not print time, not support generation, not failure prediction.
- You can tolerate a low-maintenance dependency: ~15 stars, last release February 2020, MIT license. It is effectively a small utility library, not a vendor-supported product.
- You'll wrap it behind your own interface (a
FilamentEstimator contract/adapter) so the underlying parser is swappable if accuracy or PHP compatibility becomes a problem.
- You need a fast prototype or an internal tool where a wrong-by-a-few-percent estimate is acceptable and recoverable.
- You can pin the version and run it through your own test matrix of real G-code produced by the slicers your users actually use.
Look elsewhere when:
- Estimates are billing-critical and must be defensible to customers — you'll need validation, tolerances, and likely a maintained parser or slicer integration.
- You need STL/3MF slicing, multi-material/multi-extruder handling, purge/prime tower accounting, or print-time estimation — out of scope here.
- Your stack requires a modern, actively maintained, security-reviewed dependency (PHP version floors, Composer audit, CVE response). A 2020 release is a real risk to flag, not wave away.
- You need support, SLAs, or a roadmap from the maintainer — this is a community utility.
- The real question is machine time / scheduling / telemetry, which is a different (and heavier) problem than filament cost.
- Your input surface is dominated by non-G-code formats or vendor-encrypted/obfuscated G-code that the parser can't reliably read.
How to Pitch It (Stakeholders)
For executives (30 seconds): There's a small MIT-licensed PHP library that reads a 3D-printing G-code file and returns filament length, weight, and cost. It lets us ship an instant material-cost estimate — the headline number in a quote — in days rather than building a slicer. It's a component, not a platform: it's low-risk to trial, easy to wrap and replace, and it should be scoped as a prototype/enhancement, not as the sole basis for billing.
For engineering: It's a standalone PHP utility, not a Laravel package — no service provider, so we add a thin adapter behind our own interface and keep the dependency isolated. Last release was Feb 2020, so we pin the version, verify PHP compatibility on our runtime, and build a regression suite over real G-code from the slicers our users actually use. If accuracy or maintenance becomes an issue, the adapter boundary lets us swap it for a maintained parser or a slicer-based approach without touching product code.
Recommendation: Adopt behind an interface for a bounded use case (estimate/quote display, internal costing), with an explicit accuracy and maintenance-risk note in the ADR; do not make it the source of truth for invoicing until validated against ground-truth prints.