Engineering
Build vs Buy a Cartonization Engine
The build-vs-buy question for a cartonization engine is not “can we multiply length × width × height?” It is whether you will own 3D placement, orientations, collisions, multi-box splits, leftovers, and deterministic scoring in production—while the warehouse changes SKUs every week. Most internal projects stall at a volume table. Carriers still bill the air.
What you think you are building
A weekend prototype: sort items big-to-small, greedily drop them in the first box that has leftover volume. Demo well on one SKU. Fail on mixed carts, rotation locks, and “this 8 kg item cannot sit on the mailer.”
Volume fit is necessary and nowhere near sufficient. Two 10 cm cubes do not occupy 20 cm of a 12 cm carton just because 2×1000 < 12³.
What a production cartonization engine must do
If any of these are missing, you do not have an engine—you have an estimator:
- Legal orientations per SKU (not every item may tumble)
- Bounding-box collision checks and container bounds
- Box weight limits and tare
- Multiple boxes and explicit leftovers—never silent drops
- Deterministic candidate scoring (same input → same plan)
- Exact coordinates the pack station can inspect in 3D
The hidden cost of building
The algorithm is the visible tenth. You also need tenant-scoped product and box masters, rule targeting, explainability so packers trust the plan, idempotent APIs, and years of edge cases (ship-alone, mailer exclusions, unit conversion). Talent that can maintain a bin-packer is expensive and rarely on-call for Black Friday.
Meanwhile WMS, Shopify, and OMS still need a stable contract: optional master data, inline items, ITEM_REFERENCE_NOT_FOUND instead of guessed geometry. See the WMS integration checklist.
When buying (or API) wins
Buy when packing quality is a margin lever but not your product. Brands, 3PLs, and WMS vendors should own workflows—not the NP-hard geometry. An API like POST /api/v1/pack returns packages, coordinates, utilization, and leftovers. You keep labels, rates, and inventory.
Build only if cartonization is the product, you will staff it for years, and you accept that “good enough volume math” will ship wrong boxes at scale.
A 30-day decision test
Run this before you staff a packing team:
- Take 50 real orders. Can a spreadsheet name the carton a packer would actually use?
- Force a weight-limit split. Does your prototype emit a second package or a shrug?
- Lock one SKU upright. Does it still rotate because the code treats every item as a cube?
- Replay the same request twice. Are coordinates identical?
- Show the plan to a packer. Can they see why—or do they reach for the usual mailer?
How WiCartonize positions the buy
WiCartonize is carrier-independent packing intelligence: a pure 3D engine, product and box libraries, rules, Inspector, and Gateway API. It is not a TMS. You do not rewrite collision detection to get a pack plan on a Shopify order.
Talk to engineering: book a demo.
Isn’t 3D bin packing a solved library problem?
Research helpers exist. Production needs rules, tenancy, units, leftovers, explainability, and an operations UI—not a gist.
Can we wrap Paccurate or another solver?
You can prototype against a reference, but a production SaaS should not depend on a competitor’s proprietary engine.
What if we only ship one SKU in one box?
A map is enough until the second SKU arrives. The build-vs-buy pain starts at mix, not at volume.
Does buying lock us to one carrier?
It should not. Cartonization answers geometry. Labels and rates stay in your stack.