Following are lightly edited excerpts from Rob’s recent webinar (watch the recording here).
An optimization model can perform beautifully in development but struggle or fail when it reaches production. The reason is straightforward: production changes the rules.
A prototype often operates against a controlled dataset and can be given considerable time to find an answer. A production optimization system may have minutes or seconds to make a decision. Its inputs change continuously. New products, resources, locations and business rules increase complexity. The system has to keep working reliably long after its developers have moved on to other projects.
Production optimization runs on a clock. If the answer arrives after the business has to make the decision, it does not matter how good the answer is. It is like taking a basketball shot after the buzzer: it doesn’t count.
Over nearly 20 years building optimization systems, I have had to overcome many challenges across transportation, energy, e-commerce, healthcare and other industries. The applications varied greatly, but many of the lessons for making optimization work at production scale are consistent. Here are six that stand out.
1. Model the right problem before choosing the technique
It is tempting to begin an optimization project with a technology: MIP, constraint programming, QUBO, a particular solver—or increasingly, a new hardware platform. Instead, start with the business problem and the data.
My colleagues and I were working with a company developing a hardware accelerator. The client gave us a large scheduling problem already encoded as a quadratic unconstrained binary optimization (QUBO) problem. Instances ranged from 2,000 to 25,000 tasks, with some containing millions of precedence dependencies. Looking past the encoding, however, we recognized the underlying problem as a resource-constrained project scheduling problem (RCPSP), which changed our approach completely.
The dependency graph could be decomposed into complete bipartite subgraphs and collapsed into a much smaller graph of “supernodes.” We could then use a series of MIPs for the task groups and constraint programming for the simplified precedence problem. In one representative instance, more than 19 million precedence constraints were reduced to 16 edges. The MIPs took seconds, and the simplified RCPSP solved in a fraction of a second.
The broader lesson is important in an era of rapidly proliferating AI, optimization and computing technologies: the representation you are handed is not necessarily the problem you need to solve. Our preferred sequence is simple: Understand the business problem → understand the data → build the model.
2. Formulation can beat hardware
When a large model is running too slowly, adding computing power is an obvious response, and it sometimes helps. But the mathematics itself can have a much greater impact. Consider one of the most familiar constructs in mixed-integer programming: a big-M constraint.
In an electric-grid model, suppose a generator can produce up to 200 MW when it is operating and zero when it is off. You could write a logically correct constraint using an arbitrarily large number:
Power ≤ 99,999 × IsOn
That huge value creates a loose LP relaxation and gives the solver an enormous search space. Now write:
Power ≤ 200 × IsOn
The business logic has not changed. The feasible integer solutions have not changed, but the solver now has the actual physical capacity of the generator as its bound. The LP relaxation is tighter, bounds improve, and the branch-and-bound tree can become dramatically smaller. This principle extends beyond big-M constraints. We repeatedly look for opportunities to remove redundant constraints, break symmetry, decompose problems, use appropriate piecewise-linear formulations, and give variables the narrowest honest domains possible. These techniques share an underlying idea: give the solver as much useful information about the real problem as you can.
Optimization at this level is both mathematics and software engineering. We are not simply building mathematical models; we are building systems.
3. When the structure fights you, reformulate
Sometimes tightening the existing formulation is not enough. The model itself needs to change. Our work with Birchbox provides a striking example. The subscription e-commerce company needed to assign roughly 100 products across thousands of subscriber boxes while satisfying pairing, exclusivity, inventory and other rules. Its original monolithic MIP eventually required 30 to 50 hours to solve, and sometimes failed to produce a usable answer at all.
Two structural problems were especially important. First was symmetry. A box containing products A, B, C, D and E is the same box regardless of the order in which those products are represented. Yet the solver could repeatedly explore equivalent configurations. Second, several business goals were combined in a single weighted objective. Feasibility, box count and product minimums were effectively competing with one another. Incremental fixes such as perturbation and symmetry cuts did not solve the fundamental problem, so we reformulated it.
We developed an approach called Reciprocating Integer Programming (RIP), drawing on column-generation concepts and the capabilities of modern MIP solvers. Instead of directly assigning individual products to boxes, the formulation treated valid boxes as patterns. Subproblems generated those configurations as needed, eliminating the repeated rediscovery of equivalent boxes. Each restricted master was solved as a MIP, retaining presolve, heuristics and cuts. We also replaced the blended objective with hierarchical objectives: establish feasibility first, then address box count, then product minimums. MIP starts and small node limits kept the process moving.
As a result, solve times fell from days to roughly 10 minutes—a reduction of more than 99%. That improvement did more than save computing time. Operations executives could now experiment with business rules that previously could not even be tested because solving the model took too long. Speed had become a business capability.
4. Tune to the model and define “good enough”
Modern solver defaults are remarkably strong and designed to work across an enormous range of problems. A production system gives you something valuable that a generic benchmark does not: repeated exposure to your problem structure.
In one electric-grid application, adding energy-storage resources dramatically increased combinatorial complexity. A baseline solve took about 94 seconds; with 125 batteries represented, runtime climbed to more than 1,200 seconds. That was unacceptable inside the required operating window. We benchmarked solver configurations against real production scenarios, particularly the battery-heavy cases that caused the most difficulty. Changes involving presolve, MIPFocus and other solver settings reduced the hardest scenarios from approximately 20 minutes to about 55 seconds.
The lesson is that tuning is an engineering discipline, not a one-time configuration exercise. Production also forces the question: how optimal does the solution actually need to be?
Consider an e-commerce application that routed batches of 500 to 1,000 orders to fulfillment centers around the clock. For ordinary batches, we found that an absolute MIP gap of 50 produced solutions that were entirely adequate for the business. More sensitive runs retained tighter tolerances, which effectively turned tolerance into a business decision. Anyone who has watched a MIP solve knows the long tail that can occur while the solver works to prove the last fraction of optimality. In a high-throughput production environment, consuming minutes to prove an improvement with negligible business value can be counterproductive. “Optimal enough, on time” can be far more valuable than “optimal, too late.”
5. Architecture determines scalability
Optimization performance is also a software architecture problem. Older modeling workflows frequently follow the pattern: build the complete model, solve it, change something, rebuild the complete model, and solve again. To use the analogy of home construction, you wouldn’t build a house, then decide you want a garage so you tear down the house and rebuild everything, and then later decide you want a deck, so you tear it down again.
Modern solver APIs allow a much better architecture. Build the model object, solve it, modify coefficients or constraints, and re-solve while retaining useful state. Warm starts, staged solves and incremental model construction can dramatically reduce repeated work.
We applied this approach to an electric-grid capacity-expansion model used to evaluate billion-dollar decisions about plants, transmission lines and storage. The existing workflow took 4,073 seconds for 22 iterations. After restructuring the process so subsequent solves built on the existing model, total build-and-solve time fell to 184 seconds—roughly 22 times faster. The first solve accounted for most of that time. Additional iterations became comparatively inexpensive.
The business use of optimization changed. If planners can examine only a handful of scenarios, they may be making an informed guess. If they can examine hundreds, they can explore the decision space and build much greater confidence in a long-term investment strategy.
6. Treat production optimization as production software
Once an optimization model becomes operational, mathematical correctness is only part of the job. The system must be reproducible, diagnosable, maintainable and testable. That means:
- version-controlling parameter settings instead of scattering them throughout code;
- retaining reproducible model artifacts for runs that may need to be investigated later;
- Variables should have meaningful names;
- Bounds should reflect real operational limits;
- Mathematical formulations should be documented independently of the implementation so reviewers can confirm that the code actually implements the intended mathematics.
Major changes require regression testing. For one client upgrading from Gurobi 9 to Gurobi 13, we reran production models against hundreds of real scenarios and validated solution quality case by case before deployment. The upgrade ultimately produced 30–40% faster runtimes on the longest-running models, but speed alone was not enough. The new system had to earn trust. That is the standard for mission-critical optimization.
The +1 lesson: bridge optimization and operations
Across all these examples, the largest gains came from understanding what the organization actually needed to decide, and translating that knowledge into a structure the solver could exploit. Deep optimization expertise and deep operational knowledge by themselves are insufficient. The most valuable work happens where they meet.
That principle may become even more important as AI agents enter optimization workflows. Today, AI is unlikely to replace a mathematical optimization solver as the decision engine. But agents can potentially orchestrate the environment around it—sequencing models, routing scenarios, diagnosing infeasibility, suggesting solver settings from prior runs, explaining results to users and monitoring changes in model behavior. The mathematics remains at the core. AI can help make that mathematics easier to operate, understand and maintain.
As optimization systems become larger, more autonomous and more tightly integrated into day-to-day operations, the combination of business understanding, mathematical formulation, solver expertise, software engineering and AI-enabled orchestration will increasingly distinguish an impressive prototype from a production system the business can depend on.
To discuss this with Rob, contact us to set up a call.
