You can often build it yourself

For eight years I built optimization software at Flowty, a solver for planning and scheduling in logistics. Every problem a customer brought us had to fit our solver. That’s what having a product means. But what customers needed was rarely one model handed to a solver. It was usually a heuristic for their own problem, a few steps chained together, with a solver inside one of them.

Looking back, there were plenty of times when the answer to “should we buy this?” could have been “you probably don’t need to”. Once we said it: a pharma company was already solving a large problem with an LP (linear programming) solver, and we suggested how to speed it up with the ideas behind Flowty but without its code. Another time the customer said it first: a logistics company ran a trial that never took hold, and decided to build it themselves. At the time we thought ours was usually the better choice. In hindsight that wasn’t always true, and it’s less true with the open solvers and coding agents we have now. I build on those myself now, and most of what follows comes from that.

By building I mean your own algorithm, or the layer around an open solver. Sometimes even a new solver, though that’s rarer.

What’s on the shelf

There are roughly three kinds of thing you can pick up:

• Exact solvers, MIP (mixed-integer programming) and the like. They give you a solution and a bound, so you know how far from optimal you might be.
• Heuristic solvers, local search and friends. No guarantee, but good answers fast, often on problems a MIP solver would choke on.
• Products built for one problem, a planner or a dispatcher, with a solver hidden inside that you never touch.

The first two come in both open source and commercial versions, and the lines between them blur.

What you get when you buy

There’s support. When something breaks there’s someone to call, and a vendor has most likely seen a lot of problems like yours. But you’re one customer among many, so a feature you ask for gets built when it fits their plans.

The vendor also maintains the solver. Your model, integration and data are still yours, and so are their problems.

Then there’s continuity. Your model gets written against the vendor’s interface, the pricing can change, and vendors get acquired or disappear.

Why I think this now

This is how it looks as of autumn 2026.

Open solvers got good enough for a lot of problems. Not for all of them: on hard MIPs at scale, where you need a bound that tells you how far off you can be, the best commercial solvers are still clearly ahead, and if you need that, pay for it.

Since they’re open you can also extend them when the defaults aren’t enough, though most problems never get that far. I’ve patched HiGHS for cptp and mip-heuristics. A patch is yours to keep in step with upstream, which is fine if you know what you changed and why.

And building got cheaper, because of coding agents. The risk in building was always maintenance: owning it for years after the person who understood it had left. An agent can read an unfamiliar codebase and explain it to you. My own projects are greenfield and months old, so I haven’t seen how they age yet. I expect maintenance to get cheaper too, but only if what you built is written down, someone on the team knows the domain well enough to see when a change is wrong, and there are tests that fail when something breaks. Otherwise it can drift fast.

A commercial solver has been tested on far more models than yours. But even when you buy, you build the layer around it, and that layer needs the same checks.

Why projects stall

What I saw, from the vendor’s side, came from projects, trials and meetings in energy, logistics, shipping, pharma and safety equipment. In the projects that stalled, the software was almost never the reason. It was the same few things every time, and they’d have been there whether the software was bought or built.

First, the business case. Optimization problems often live in operations: technician scheduling, routing, maintenance planning, production scheduling. Operations is measured on uptime and on things running smoothly. But those KPIs don’t connect to finance, so the department that has the problem has a hard time making the case for solving it. The savings are real, but they land on someone else’s budget, often a few years out.

When a customer told us “we have an obvious business case”, it was a good sign: someone senior enough to own the outcome had already decided this was their problem. Most of the projects I saw land had that person. The one I knew best, at an energy company, was like that, and even there most of the work was on their side: getting it adopted internally, building it into their own product, and making the case inside the company.

Then defining the problem to solve and modelling it.

Next is data. The algorithm needs a data feed that’s correct and kept up to date, and that was usually where most of the work went.

Then deployment: getting the thing into the path where decisions are made.

And adoption, which isn’t a technical problem. The users typically sit in another department, they’ve been working in Excel with a set of rules they trust, and they’re not especially technical. Optimization has a hard time explaining itself to them. You can answer “why not my way?” by re-solving with their alternative and showing the difference. That works, but it costs a solve per question. Agents that explain a solution, including why the plan someone asked for isn’t feasible, are starting to appear. It’s early.

Most of the cost is your own people’s time: modelling, data work, deployment, and months of getting a department to trust an answer it can’t check. You pay that whether you build or buy. A license on top of that is worth it when it buys something you can’t get otherwise.

When I’d build and when I’d buy

If an open source tool fits as it comes, use it. If it doesn’t, build the chain yourself around an open solver. Write the model so the solver can be swapped, and try the open one against a commercial trial on your own data before deciding. Buy a solver when you need a bound you can trust on hard problems at scale. Buy a product when your problem is standard enough that someone has built it well, because then its interface and the people who’ve rolled it out before take real work off you.

Either way you need people who understand optimization to steer the work. Agents have made implementation cheaper, not easy, and someone still has to ask the agent whether it’s solving the problem you meant, and ask the business whether it’s worth solving. A software engineer with a feel for the mathematics can get a long way on the algorithms.

And whichever way you go, check a few things first. Where does the data come from, and who keeps it right? Who has to change how they work for this to land? The fewer people the better. Does someone senior own the business case? If nobody owns the case, I’d sort that out before deciding whether to build or buy.

I’m a builder, so of course I’d build. Read the above with that in mind.