Some things just belong together.

Timefold’s PlanningAI engine optimizes complex, large-scale scheduling problems in real time. Bryntum visualizes these into beautiful, interactive schedules that are ready to use. Put them together and you finally have the intelligent scheduling solution you always needed.

Why this partnership matters

• See the magic: When optimization becomes visible, it earns trust. Clear, interactive schedules show exactly what changed and why.
• Adopt at speed: Visualization democratizes the complexity of optimization, accelerating buy‑in across your organization.
• Deliver real‑world impact: Lower costs, a greener footprint and higher service levels, now with proof your stakeholders can watch unfold.

A mission, super‑charged

From day one, we set out to free the world from wasteful scheduling. Enterprises across the globe already rely on PlanningAI to slash overtime, cut driving time and delight customers. Yet the biggest barrier to scaling optimization has always been perception: “It’s too complex.” That ends here. With Bryntum’s polished components seamlessly wired to Timefold’s APIs, complexity becomes clarity.

Embed once, optimize forever

Whether you're managing a workforce, running logistics, or routing field teams, our optimization models drop straight into your system with a single API call. And if you add Bryntum, you get fast, clean and responsive Gantt charts, resource calendars, and task dependencies. While our engine handles hundreds of constraints, thousands of tasks, and real-time changes effortlessly, Bryntum brings the clarity.

For the real world

It’s time to pull planning optimization out of the specialists’ corner and put it in the hands of every team that needs it. Together, Timefold and Bryntum are turning algorithmic power into everyday productivity.

Want to learn more? Contact Bryntum, or talk to us!

Stuck in the past

Despite the billions poured into digital transformation, most companies still schedule the same way they did in the '90s. I’ve seen manufacturers, governments, hospitals,… with mission-critical operations still relying on Excel. Or worse: paper.

Really, I am not exaggerating. I’ve witnessed it firsthand multiple times. When they showed me their production scheduling, they:

• Handed me a stack of paper.
• Or showed me several Excel files, none of which actually visualize the schedule in a Gantt or timeline chart.
• Or introduced me to their chief planner, who spends 12 hours a day manually moving around post-its on a giant piece of paper until a feasible schedule magically appeared. This was the prime reason they couldn’t scale operations.

Madness.

And every time it gets to me: Automation is not a given, let alone optimization. Not even close. We have the technology to explore space, while some still haven’t reached the Cape of Good Hope. But in order to catch up, we need to understand the complete timeline.

I broke it down into 4 stages.

Level 1: Freeform manual scheduling

Planning on paper, or in spreadsheets. No guardrails, no validation. If someone assigns two tasks to the same person at the same time, or exceeds the capacity of a machine, it’s all good. Until it blows up in execution. Your schedule is only feasible because of  the human planner behind it. When that planner leaves or goes on vacation? Chaos. Retirement? Disaster.

Level 2: Verified manual scheduling

This is the drag-and-drop utopia many ERP vendors promise: the planner does the thinking, and the software nods politely. It might scream when hard constraints are violated (“You can’t schedule John for two shifts at once!”), but it never lifts a finger to help assign the shifts itself. Your schedule is still only as efficient as the human planner behind it. And when they are absent, production efficiency noticeably decreases.

Level 3: Automated scheduling

This is the first real leap. Press a button, and the software assigns work. Sounds perfect until you realize it’s just a glorified greedy algorithm, assigning tasks one by one in isolation. It’s still only as good as your human planner. Or even worse. There’s no understanding of the true complexity. You’re still leaving a lot of money on the table.

Level 4: Optimized scheduling

Now we’re talking. This is where PlanningAI steps in. Instead of myopically assigning tasks one at a time, it takes a holistic approach. It juggles your hard constraints (skills, time windows, overtime limits) and your soft goals (fairness, fuel costs, customer satisfaction) to deliver a globally optimized schedule. All with one button.

And even then, real-world planning is messy. Some schedules still benefit from manual overrides. Or goal tweaking. That’s why our PlanningAI platform supports mixing and matching verification, automation, and optimization seamlessly. Because planning is not a one-size-fits-all operation. It’s a living, breathing process that needs to adapt in real time.

If you feel like it's time to level up, let's talk.

Over the past few weeks, I’ve had a lot of great conversations with developers, planners, and other professionals at various conferences. Usually, they’re pretty impressed by what PlanningAI (and Operations Research in general) can do and has been doing for decades. However, there is one particular question which always bubbles up: “What if something happens and the plan no longer works?”

Excellent question!

One of my university professors imprinted the following quote into my brain: “Change is the only constant”, which is a quote often attributed to the Greek philosopher Heraclitus, who figured it out way back around 500 BC. Yes, dealing with change has been ruining carefully crafted plans since humans first tried organizing anything.

In the realm of planning and optimization, change can present itself in different ways: An employee calls in sick, a truck decides today is a great day for a breakdown, or a customer ghosts their appointment. Suddenly that beautifully optimized solution becomes irrelevant, sometimes before you’ve even finished your morning coffee.

We are forced to face reality: the real world doesn’t care about our perfectly optimized schedules. Or as another philosopher and occasional boxer put it: “Everyone has a plan 'til they get punched in the mouth” - Mike Tyson

Rolling with the punches

The quote “change is the only constant” isn’t just a sad pointing out of facts. It basically calls upon us to stay flexible in our plans and adapt to new circumstances, because change will come.

That sounds nice doesn’t it… “just adapt to change”. It’s a bit more involved than that.

The first thing we should do is an impact analysis: “What does a certain change mean for our business”? In the case of an employee getting sick, we should ask ourselves, “How critical is this employee?” and “What if we do not replace them?”

The simplest option is to not solve the problem at all, but that often isn’t a feasible path forward. Usually, the plan needs to be adapted, which leads us to the next question.

How much can the plan change?

When a plan is already in motion, abrupt changes can cause chaos. For example, if field technicians are out solving issues, you can't just send them racing off to handle emergencies every hour.

One approach to deal with this is to freeze a part of the plan and let a solver re-optimize the schedule. This will make sure that as much of the plan as possible stays the same. In the field technicians case, we might freeze any assignments for the next hour.

Freezing assignments isn’t always the best approach as it’s sometimes difficult to determine what should and should not be ignored when re-planning. Instead, we could use a Minimize Disruption Constraint. This constraint will compare any newly generated solution with the previous active plan and penalize that solution for each change. This approach nudges the solver to keep as much of the original plan intact as possible.

These disruption constraints can be flexible, penalizing immediate schedule changes more heavily than those further out. That means you can smoothly adapt schedules while keeping your team happy.

These two mechanisms, Freezing and Minimize Disruption Constraints, could also be used together, where you might freeze the next hour as you absolutely want no abrupt changes but do accept some disruption afterwards. This combines minimal immediate chaos and manageable long-term adjustments, the best of both worlds.

Communicating changes

Adapting the schedule is only the start. You still need to communicate the changes clearly to everybody involved. If you have on-call staff, the phone-call to come to work shouldn't be a surprise. If you need to call upon someone who normally wouldn’t be working, that’s another thing.

In these situations, 2 things are fundamentally different from regular planning.

1. If people are unexpectedly going to be asked to work, you should probably call them first if they are ok with that before planning them in. They might be out of town or otherwise engaged.
2. In these situations, achieving an optimal plan becomes secondary to maintaining clear communication and avoiding chaotic changes.

In Timefold Solver this use case is a first-class citizen. With the Assignment Recommendation capability, Timefold Solver combines a greedy algorithm with incremental score calculation to swiftly identify the best available options for fitting the change in the existing schedule.

The recommendations also give some insight into the impact on the overall schedule, so a manager can make an informed decision on who to call into work. This human-in-the-loop approach brings together the power of AI with human intuition which is essential for successful planning.

After the crisis has been resolved the new plan could be re-optimized using the freezing and disruption minimizing constraints.

Embracing change

The move to real-time planning isn’t just technical. It’s philosophical. It means embracing change not as a problem to be avoided, but as a constant to be managed.

In a way, this is the real power of PlanningAI. Not just building smart plans but building resilient plans that stay smart, even when the world decides to punch you in the mouth.

Let’s make plans that adapt.

Operations Research is, and has always been, about solving one of the world’s toughest challenges: planning problems. Finding the best way to allocate resources, schedule shifts, or route deliveries under an abundance of real-world constraints. It is widely accepted that optimizing those problems will make the world a better place, the potential value has never been in question. But the road to real-world adoption has been rough. With PlanningAI, we can alter the narrative.

What is PlanningAI?

PlanningAI is a reckoning for Operations Research. A much needed rejuvenation of the OR space driven by refocusing efforts towards solving real-world complexity at scale, fulfilling all business requirements. It’s a type of Artificial Intelligence that automates and optimizes complex planning, scheduling and routing problems for production use.

Why we believe PlanningAI is a blessing for Operations Research

The unfulfilled promise of OR

For decades, applying OR in practice has been slow, expensive, and risky. It requires niche expertise, complex code, and months to deliver a good POC, only to require some more months to integrate, customize and scale. Additionally, there’s onlly a small pool of hyper-specialized experts that can actually optimize complex planning problems.

Is it because of its sheer complexity, poor marketing, or lack of perceived value that a lot of businesses don’t even think about starting OR projects? We can only make assumptions.

Time to value

However, clarity on and proof of value has always been one of the obvious pain points of OR. PlanningAI solves that. In the first place by translating optimization gains into business KPIs, and in the second place by proving value early. With standardized models that factor in 95% of common constraints, the time-to-value PlanningAI offers is unprecedented. Integration becomes a glue-code job, not a multi-month POC/build/integration saga.

That’s what makes PlanningAI such a shift. It takes the deep rigor of Operations Research and makes it practical, scalable, and ready to plug into real operations.

Risk reduction

As mentioned above, traditional OR projects are long, complex, and expensive. On top of that, the biggest risks show up late. Businesses typically only find out near the end whether the model can actually handle the full set of constraints at scale. By then, you’ve already burned months of budget and resources, often amounting to millions of dollars.

PlanningAI flips that risk profile. Because it starts with prebuilt models that cover the common constraints, implementation is shorter and more predictable. Customization happens quickly, in weeks, so the technical risk is front-loaded. That means less uncertainty, faster validation, and a far lower chance of failure down the line.

Complexity without compromise

The time-to-value and risk-reduction don’t compromise the ability to handle complexity. On the contrary. PlanningAI doesn’t dilute the science but operationalizes it. It works across domains and scales with problem size. Whether you’re planning 50 or 50,000 deliveries, it handles complexity without compromise.

Replanning in real-time

It brings automation where there used to be manual work, optimization where there used to be automation, and speed where there used to be delays. Planners can now generate optimized schedules in minutes, test different strategies, and adapt on the fly. Replanning becomes real-time, not rework.

Results, not in a distant future

Reduced costs, better resource utilization, lower emissions, and higher employee satisfaction… The results from a PlanningAI project are the same as from traditional OR projects. The difference is their accessibility. By using predefined constraints, enterprises can tweak their solution to reach their business KPIs. And importantly, gains show up across industries, from healthcare and logistics to manufacturing and government.

Planners empowered

And it’s more than better outcomes, it’s also about better tools for planners, dispatchers, or other people in charge of allocating resources. Human planners will gain superpowers. With PlanningAI, they can test ideas faster, adapt to last-minute changes, and deliver better plans in a fraction of the time. In some cases companies save hundreds of millions per year.

Democratization of OR

The results of PlanningAI are accessible, and so is the technology behind it. What used to be locked away in cryptic equations and niche academic papers is now packaged in standardized, production-ready models. PlanningAI translates optimization logic into readable, maintainable code, and makes it understandable in thorough documentation. That means teams no longer need a PhD in constraint programming to build or adapt a planning solution. Any developer can understand the model, tweak it, and deploy it. This shift democratizes OR. It opens the door to a much broader group of builders, even onboarding  and support are straightforward.

Mature technology for production use

Unit tested, peer-reviewed, versioned, and production-ready. PlanningAI integrates cleanly with existing systems through a standard REST API, so no need for custom middleware or black-box magic. It fits into your architecture, not the other way around. Without the months-long consulting projects, enterprises go from idea to implementation fast. No brittle glue-code. Just powerful optimization, standardized and ready to plug in.

PlanningAI makes Operations Research operational

In short: PlanningAI delivers what OR always promised. It takes the crown jewels of academic optimization and puts them in the hands of the people running operations every day.

Origin

The term "Planning AI" emerges naturally from the versatile root word "planning," originally from the Old French plan meaning "ground plan" or "map." Historically, planning implied detailed thinking ahead, encompassing both short-term logistics and long-term strategy.

Over time, especially in multilingual and global business contexts, "planning" has expanded to naturally cover various operational scopes, from immediate scheduling and routing to broader strategic foresight.

Practical

In practice, modern organizational needs blur distinctions between short-term schedules, operational logistics (routing), and strategic decision-making. Consider scheduling: it directly impacts daily efficiency, customer service quality, and staff morale. Routing is a close sibling to scheduling. It integrates geographic constraints, logistical decisions, and real-time adaptability. Together, scheduling and routing form the tactical layer of organizational efficiency.

Strategy

At the strategic layer, PlanningAI helps give insight into larger-scale decision-making challenges, such as resource investment, market entry timing, and capacity planning. The strategic horizon defines parameters within which tactical operations like scheduling and routing are optimized.

Critically, restricting "PlanningAI" solely to long-term strategy ignores this practical, linguistic, and historical reality. Its inherent versatility makes it an intuitive, logical term to encapsulate a spectrum of intelligent decision-making processes.

Intention

Therefore, PlanningAI, as a term, intentionally captures scheduling, routing, and strategy because businesses naturally function across multiple timeframes and complexities.

Recognizing this breadth enables organizations to leverage comprehensive AI-driven solutions for greater agility, foresight, and sustained competitive advantage. Ultimately, embracing Planning AI in its broader meaning aligns closely with how organizations practically operate and how language organically evolves to reflect real-world use cases.

In other words: We believe PlanningAI is the world's best solution to complex, large-scale planning problems.

It seems like you can’t scroll through a tech feed these days without hearing about Generative AI. From ChatGPT writing blog posts, to AI-generated art taking over Instagram, GenAI is everywhere. And just to be clear, we’re hardcore users ourselves. But there’s a misconception we want to clarify. Not every AI falls under the GenAI banner. Our DevRel Tom Cools already wrote a compelling blog post on the different kinds of AI, and how each kind has different capabilities. However, in this blog post, we’ll explain 6 major differences between PlanningAI and GenAI. Both powerful, both AI, but fundamentally different.

1. Black box vs. explainable

• Generative AI often relies on deep neural networks that are incredibly complex. The model’s inner workings can be difficult to interpret, hence the “black box” label. Even developers can struggle to explain exactly how the system arrived at a certain output.
• Planning AI, on the other hand, uses methods that are more transparent. It’s built on well-established algorithms (like constraint programming, linear optimization, or rule-based systems) that are easier to trace. Users can see how decisions are made, step by step, which is especially important in industries where compliance and explainability are paramount.

In many business applications, stakeholders demand to know why a decision was made. Planning AI delivers that explainability. Generative AI is incredible for creative or less regulated contexts, but in scenarios requiring a clear rationale (think supply chain, workforce scheduling, or compliance-heavy fields), an explainable system wins every time.

2. Non-deterministic vs. deterministic

• Generative AI is non-deterministic. That means it can produce different outputs even when given the same prompt. This variability can be great for creative applications, but it can also lead to inconsistencies.
• Planning AI is deterministic. Give it the same inputs, and you’ll get the same outcome every single time. This consistency is crucial for businesses that rely on predictable results, like production scheduling, logistics planning, or financial forecasting.

Predictability is often the key to operational success. When you need reliable, repeatable results, deterministic models are more appropriate. If you’re aiming for creative inspiration or novel outputs, non-deterministic models shine.

3. New tech vs. proven tech

• Generative AI feels like the “new kid on the block.” While deep learning has been around for a while, the explosion of large language models and image generators is relatively recent. This newness excites people but also means there’s still a lot to figure out: best practices, regulations, ethical frameworks, etc.
• Planning AI has been around for decades. Methods like optimization, constraint programming, and rule-based systems are proven in countless real-world scenarios. They’ve been tested and refined over time, offering reliability that’s hard to beat.

Mature, proven technologies often come with extensive documentation, robust user communities, and well-established integration paths. If your business requires stability and a track record of success, Planning AI can offer peace of mind.

4. Generating new content vs. optimizing what exists

• Generative AI is about creating. Be it text, images, or even code snippets. It’s an amazing fit for brainstorming, content creation, and personalized marketing materials.
• Planning AI focuses on optimizing existing resources and processes. Instead of inventing a new image or paragraph of text, Planning AI schedules your workforce more efficiently, optimizes complex routing problems and helps allocate resources across multiple projects.

If your biggest challenge is to streamline operations, cut costs, or improve your workflow, Planning AI is designed for those optimization tasks. Generative AI can create fresh ideas, but it might not be the best fit for strictly operational goals that need a laser focus on efficiency.

5. Large training datasets vs. manually programmed algorithms

• Generative AI: Creating an LLM requires massive amounts of training data. These large datasets consume enormous computational power (and, yes, electricity) to reach impressive accuracy and capabilities.
• Planning AI uses optimization algorithms that are preprogrammed by experts. While some data may be involved, it doesn’t require training. Instead, Planning AI relies on logical constraints, heuristics, and well-defined optimization strategies.

Collecting, cleaning, and maintaining huge datasets can be expensive and time-consuming. If your business doesn’t have that kind of data. Planning AI can be far more practical to implement and maintain.

6. Environmental impact: “Burns” vs. “Saves”

• Generative AI is computationally heavy. Training large models can consume tons of energy, which raises environmental concerns.
• Planning AI requires less compute power. It’s more about applying targeted, efficient algorithms rather than brute-forcing through billions of data points. As a result, it tends to have a smaller carbon footprint. Additionally, planning AI is used to optimize issues like vehicle routing, which has a massive impact on CO² emissions.

Sustainability is becoming a core metric for many organizations. While it’s not always a direct apples-to-apples comparison, if your company values a lower environmental impact, Planning AI is often more resource-friendly.

Where does Timefold fit?

We’ll be the first to admit we’re big fans of Generative AI, some of us are even using it to help write code or jump-start content. However, our product is built on PlanningAI principles. It’s explainable, deterministic, and designed to optimize existing processes rather than create new content. This makes it ideal for businesses that need reliable, repeatable, profitable, and environmentally conscious solutions.

Our takeaways

• Generative AI and Planning AI are both “AI,” but they solve very different types of problems.
• Generative AI shines at creating new content and inspiring innovation, whereas Planning AI excels at optimizing complext processes at scale and delivering predictable results.
• Both have unique strengths, but if you need transparency, consistency, and a smaller environmental footprint, Planning AI may be the better fit.

As a cat person, I’m very happy the internet has embraced cats as the “ultimate feel-good” subject when it comes to pictures and videos. And now with LLMs and GenAI the fun is endless! Want a cat sitting on a crocodile while playing the banjo? Boom!

Generated by ChatGPT

Or a cat in a tiny top hat hosting a stand-up comedy show for a crowd of impressed goldfish, here you have it!

Generated by ChatGPT

Of course this is purely for entertainment. LLMs have proven themselves to be very valuable tools that help us brainstorm, proof-read e-mails or even help us rewrite texts for specific audiences. The progress in the past few months has been mind-blowing, which might suggest they're the answer to everything. At least, if you believe the hype machine.

But when it comes to solving practical, real-world problems, they’re not there yet.

LLMs and everyday planning problems

My neighbor Jamie works at a hospital and creates the work schedule for the nurses and doctors. It’s a logical nightmare juggling availabilities, contracts, and other employee preferences. Every week, she spends hours creating the schedule, but there is always somebody who thinks they got the short end of the stick.

Our local plumber, Robert, is always in high demand, constantly driving around the neighborhood. His services are in high demand, but he wastes valuable time on the road because he isn't tackling jobs in the most efficient order. Smarter scheduling would mean helping more customers and spending less time driving.

With all the power that people subscribe to tools like ChatGPT, creating such schedules should be a walk in the park? Right?

Reality is however disappointing: LLMs can’t deal with these tasks very well. Most of it comes down to the sheer size of the problem space: the total number of possible combinations of input parameters. Even a seemingly simple problem like assigning shifts to 10 Employees for a week has a problem size of 10⁶³ combinations. That takes a lot of processing power to solve even with specialized algorithms, let alone trying it with a general language model.

7 days, 3 shifts per day, on average 3 employees per shift, yes that’s a 1 with 63 zero’s behind it!

Sometimes LLM models do find a feasible solution. This is especially true for the newer reasoning models. Those seem to think through the problem and can create a feasible schedule on very small datasets. As these models can reason about discrete steps, they break down the creation of a schedule to smaller steps, just like a human would.

Recent updates have given LLMs to replicate human reasoning.

When you try medium sized datasets, LLMs run both into the problem space issue and in some cases even context window limitations due to the amount of tokens in the input. Although we do believe the latter is a temporary problem as the technology evolves (looking for example at Gemini with a context window of 2 Million Tokens!), the former is going to be much harder to overcome… at least without some help.

A solved problem, almost forgotten

By their very nature, LLMs just predict the next token and “the next token” isn’t what we are looking for when trying to solve planning problems. Luckily, for most gaps in current LLM capabilities, we can look back at “older” forms of AI which resolve these gaps.

The different layers of AI, Timefold fits into the outer layer of old-school AI.

When looking at our problem, we have to peel back the layers of AI evolutions. As mentioned, LLMs and GenAI aren’t the solution here.

Deep Learning and Machine Learning are excellent at pattern recognition and learning from data. Unfortunately, the learning part is often the problem.

ML solutions require large volumes of high quality data to learn from. Real world planning problems usually have their own unique nuances and are often still being done manually… so there is no large amount of high quality data available. No training data, no training, no Machine Learning model.

We need to go even further back, to the origins of AI. In the “old-school” AI layer, we find a pretty unassuming part of AI called Mathematical Optimization. This blob of techniques has been a proven way to solve planning problems for the past 30 years. Here you’ll find techniques such as Linear programming and our personal favorite at Timefold: Metaheuristics.

These algorithms don’t need a big upfront training set to build a model, as the models are programmed manually by domain experts. They work with enormous datasets and find (near) optimal solutions to your planning problems.

It’s frankly a wonder Metaheuristics and friends are so undervalued and get overshadowed by the commoditization of GenAI. By our estimations, 95% of these planning problems remain unresolved while the answer has been out there for decades.

Maybe it got lost in history? It’s time to rebrand this part of our industry and start our own hype machines. It’s time for #PlanningAI.

What is PlanningAI?

PlanningAI is a type of artificial intelligence designed specifically to handle complex planning and scheduling tasks, and to satisfy the constraints of planning problems. It helps you make better decisions by sorting through countless possibilities to find the best solutions. Solutions that save you time, reduce costs, and improve efficiency.

This form of AI can be a bit unwieldy and overwhelming to operationalize. We realized that and removed as many barriers as possible to make it as simple as it can be. We’ve created pre-built models for common use-cases, ready for consumption through a REST API interface on our Platform.

Using these APIs, we can generate a shift schedule for my neighbor Jamie, or calculate an optimized route for our local plumber Robert, without even needing to know anything about solving these complex planning problems. It’s basically our decade long planning expertise in a box.

Not one or the other, but together

While LLMs can’t handle planning problems efficiently, nobody can deny that they’re an amazing enabler. So instead of staying in our respective corners of the AI-Ecosphere, let’s start being a big happy AI family and leverage each other's strengths for the betterment of all!

PlanningAI can leverage Custom GPT models to help domain experts build better PlanningAI models and help explain them to a larger audience. It can also help transform data into information and translate complex ideas into something even the most technophobic person can understand.

LLMs from their part can leverage the capabilities of PlanningAI through “Tool Calling” functionality or the Model Context Protocol, giving LLMs access to advanced algorithms specialized for solving these kinds of problems.

The fusion of AI technologies is reshaping how we solve planning problems, opening up new and innovative solutions. What a time to be tackling these challenges!

On this day, 3 years ago, my world fell apart. It was a Thursday. I just finished my second meeting that morning, looked at my inbox and realized it was over. My life’s work was over. OptaPlanner, the popular open source solver we had developed and refined for more than a decade, was going to die. Despite worldwide success on thousands of projects.

I curled into the sofa. Two hours later, my wife found me there, still catatonic.

This is the story of Timefold AI.

This is the story of how I turned a doomed open source project into a fast-growing PlanningAI company.
With commercial success. Without sacrificing our open source values. With a clear goal: free the world from wasteful scheduling.

The hobby project

19 years ago, a colleague showed me his shift rostering project. To make it fast enough, his code had become unreadable and unmaintainable. It wasn’t his fault. The solver software forced his hand. I envisioned a better Solver API design that would prioritize ease-of-use. So in the summer of 2006, I created an open source project to solve planning problems. Nothing serious, just a hobby.

I released it under the Apache License and kept improving it. Over the years, I added more features, examples, documentation and testing. Good engineering practices. Marketing matters too, so I published articles and presented at conferences about it.
It turns out that good documentation is a superpower for open source projects.

By 2012 my hobby project had grown into a software library with deep tech algorithms for vehicle routing problems (VRP), employee rostering, job shop scheduling, and many other Operations Research challenges. Enterprise projects started using it. Even a NASA supplier for satellite scheduling. But it was far from perfect.

Meanwhile, I got married, renovated an old house and struggled to find time for my hobby project. With kids underway, I quickly started running out of spare time to work on it…

You can’t build a world-class product as a hobby.

The day job

By contributing to open source projects, I landed a job at Red Hat, the open source company. I loved working there. By 2013, they wanted to productize my work, so we renamed it to OptaPlanner and Red Hat started selling support for it.

My hobby became my work.

Customers needed help. I honed my talent for modeling enterprise planning problems. I got to work on all kinds of cases, such as routing thousands of field service technicians, scheduling maintenance of airplanes and planning production in factories across the globe. This feedback also shaped my software immensely.

Regularly talking to real users is critical. One real business problem is worth a thousand academic ideas.

The dream

I realized that the world is full of planning problems. Some are automated. Few are optimized.

I still estimate that 95% of companies use a drag-and-drop scheduling UI or mess around in Excel. Great algorithms have existed for decades. But they are too hard to use. I made it my life’s mission to fix that.

Because real-world planning problems are complex. To solve them with ease, my software needed to evolve faster and broader. I needed a team.

You can’t build a world-class product alone.

The engineering team

Luckily the OptaPlanner team grew organically as Red Hat sold support subscriptions. Great minds like Lukas, Radek and Chris joined me. We didn’t always agree immediately, so we worked out a meeting process to fine-tune design proposals, without drama.

In hindsight, alignment was easy: we were all engineers.

Lukas became my right hand. He probably answered more StackOverflow questions than me. As I (slowly) learned to share ownership, to let go, the project started taking big leaps forward. Our solver finally became easy to use.

Meanwhile, users reported ROI (return on investment) numbers that surpassed our wildest dreams…

The gold vein

Most companies don’t expect big gains from planning optimization. They think their manually planned schedules are near-optimal. But they’re wrong. In vehicle routing cases, our solver helps planners to reduce their fleet’s travel time by 25%. For big companies, this saves a hundred million dollars per year. And ten million kg of CO² emissions per year. It gives the world extra time.

So clearly, there’s money to be made with this technology. But our software was 100% open source: Red Hat only sold support. That’s a weak Value Proposition. Especially if there are almost no bugs, support is worthless. I estimate 0.01% of our users paid. Enough to keep the lights on. But not enough to free the world from wasteful scheduling.

Without a proper business model, an open source project doesn’t change the world.

We needed repeatable sales. A great engineering team is not enough. To turn the gold vein into a gold mine, we needed a commercial team focussed on selling to Planning Optimization customers. But that wasn’t the corporate strategy…

You can’t build a world-class product without sales and marketing.

The acquisition

IBM acquired Red Hat in 2019. Initially, everybody got nervous, especially because they owned a competing solver. But after a year, everything seemed normal.

At the end of 2021, I distinctly remember telling my team: “We’re safe. OptaPlanner pays for itself. Red Hat would be crazy to kill our project.” But our project’s revenue was part of a broader product subscription…

The breakdown

By then it was February 2022 - that fateful week three years ago.

On Monday, they told us that the product subscription would move to IBM, without us. It didn’t fit in the strategy.

The first stage is Denial.

On Tuesday, they told the entire company. Every Red Hat sales with an OptaPlanner deal in the pipeline contacted me. They needed a product to sell. But I had no answers.

The second stage is Anger.

On Wednesday, I wanted to rescue the sales pipeline. Months of work. I pleaded with management to move us into another product and to announce it immediately. But it’s not that simple.

The third stage is Bargaining.

On that fateful Thursday, I looked at my inbox and crashed.

The fourth stage is Depression.

Much later, I realized Red Hat made the right decision. A company needs focus. When your company strategy is Hybrid Cloud, your marketing, sales and support teams aren’t experienced (nor incentivized) to deal with scheduling or routing problems too.

The last stage is Acceptance.

The marriage conversation

After my wife found me there, curled up on the couch, I had to get healthy first. When I was back on my feet, I regressed through those stages a few times. It was my life’s work hanging in the balance. But by July 2022 all hope died: it was clear that OptaPlanner had no future.

What if I start my own company around the open source project? Without thinking too much about it, I floated the idea to my wife…

My wife grew up with self-employed parents that worked day and night. She knew the sacrifices to run your own business. She never wanted that for our family. And with two kids and a big mortgage, my salary was needed to pay the bills. So imagine my surprise when - without batting an eyelid - she replied:

“Go for it! We can handle a year without your income.”

No doubt. No resistance. Only optimism. She knows this is my life’s work and she respects that. She mentally even took the leap faster than I did. She’s truly a wonderful woman.

To create a successful startup, you need support from your spouse.

The business model

By then, my reputation as a planning expert preceded me. I could automate any scheduling problem and make it scale (on our solver). So I could start a consulting company and sell my time by the hour. Easy money. But then I would be working on the solver in my spare time again.

“You can’t build a world-class product as a hobby.”

Instead, I had to build a product company. One that offers a subscription on top of the open source project. With a strong value proposition. Support alone wasn’t enough, so I decided to go for the open core business model: keep developing the open source solver, but sell proprietary services on top of it. I couldn’t build all that alone. And software developers don’t work for free.

“You can’t build a world-class product alone.”

Bootstrapping would take too long. I needed an investor. Not an Angel Investor that wants a reliable return, but a VC firm that’s in it for the long run and wants to take an ambitious, big risk. But I didn’t know how to build a startup. Nor fund it.

“You can’t build a world-class product without sales and marketing.”

Luckily, I live in Ghent - a strong startup hub in Europe.

The advice

A solo entrepreneur advised me: “Don’t do it alone”. Purely for mental reasons. You need someone to not just share, but also understand the hardship and complexity. A cofounder. Not an employee, not an adviser, but someone who’s all-in. He was right.

A few dozen people had asked me to start a company before. They all dreamt of riches and success, but none had startup experience. Neither did I.

I started reading books. The Founder’s Dilemma was highly informative. I realized I needed a CEO. Someone with experience on how to run a company. Someone with a very different skillset and different mindset than myself. The science is clear: cofounders need to complement each other. Balance each other out. And challenge each other.

So how could I find an experienced startup CEO?

The investor

A friend of mine put me in contact with Thomas, an investor of Smartfin.

I sent him a convincing email and we met up at a local coffeehouse for a 30 minute meeting. There are rules on how to pitch to an investor. I didn’t know any of them. I followed none and I don’t recommend that. Yet, he kept listening and recognized the value. After talking for two hours, I asked him to connect me to a potential CEO.

It turns out that Smartfin is the biggest seed-stage VC investor in Belgium.

After that meeting, Thomas called Maarten - a serial entrepreneur mastermind - and told him “I’ve just heard an interesting pitch from a technical guy, but this is not investment ready.”

In hindsight, I was clueless on how to build a company.

The cofounder

In September 2022, I met Maarten for the first time. Through some freak coincidence he lives three streets away from me. He’d probably call it destiny.

I wanted a CEO with expertise in sales and administration.
I found a CEO with expertise in venture building, hiring, funding and a bit of sales.

I didn’t get what I wanted, I got what I needed. As a founder, he had built 3 companies from the ground up already. That left wisdom and battle scars.

Because a seasoned founder doesn’t look at a startup idea like normal people. They see the pain. They question the Product Market Fit. They are brutally critical and despise wishful thinking, because without revenue, the startup dies. Ideas are cheap, execution is expensive.
Maarten’s favorite line: “Assumption is the mother of all fuckups.”

In our sparring sessions, we worked out a plan and focussed on the pain points. I didn’t always understand him. Nor did he me. We often still don’t. I haven’t led a company through financial hardship before and he hasn’t seen how technical debt compounds on long-term software like terminal cancer. But we learned to trust each other. To listen to each other, especially when we don’t agree.

After a month, we took the leap.

The leap

Every founder needs to take the leap: exchange predictable income for uncertainty.

For me, that came in October: I resigned from Red Hat and invested part of our family’s savings in the company. The rest of our savings steadily eroded each month. The clock was ticking. Work-life balance went out the window.

Fun fact: 90% of startups fail.

The company

On December 8th, 2022 Maarten and I registered our company. We named it Timefold, because we like to say that our algorithms fold space and time.

Afterwards we got breakfast and Maarten announced to the entire restaurant: “We just got married!” There’s truth in that.

One of our first expenses went to a designer to create an elegant logo:

The AI hype

After ChatGPT came out, every company needed an AI story. Including our potential customers. Investors loved it too. Should we ride the AI wave?

Timefold’s algorithms are categorized as Artificial Intelligence. But its core is not a Large Language Model or even Machine Learning. It doesn’t use training data. It will never evolve into an AGI. But it’s unrivaled at optimizing planning and scheduling.

I’d even argue it’s a superintelligence because the results leapfrog human capabilities:

We decided to capitalize on the buzz and registered timefold.ai. Later we coined the term PlanningAI.

The pre-seed funding

We needed money to hire a team. Maarten got us in front of every notable VC investor in Belgium.

VC firms collect a large pool of money and invest it in startups. They prefer startups with billion dollar potential, to cover losses on startups that go bankrupt. High risk, high reward. They play the long game. They’ve seen first-hand the growth challenges and impact of strategic decisions for dozens of companies at various stages. Their advice is invaluable. So is their network.

Here’s how it works: a VC typically takes a 20-25% stake. The amount of money varies. They don’t mind a 10% ESOP pool for employee shares. Founders might get a wage to avoid personal financial stress, but then also need skin in the game, typically by investing personally. The VC takes a seat on the board, but doesn’t meddle in day-to-day management. They mainly advise on C-suite hires and strategic company direction. It’s a good deal, but they won’t do the work for you.

What about open source? I didn’t want to end up with a bait-and-switch on my hands. Not every VC gets it, but many VCs respect the distinct advantage of open core companies in the developer API market.
Smartfin did. They offered us the most money and a wise, experienced director for the board. So we accepted their term sheet and went through the due diligence period.

At this point, we were basically two guys with an idea. In March 2023 - six months after I resigned - we closed the deal and they gave us a cool 2 million euro.

Afterwards we got lunch and Maarten asked them:
“How many cases do you get per year?”
“About 1200.”
“And how many do you fund?”
“Two. Maybe three.”

Maarten and I looked at each other. Only 0.25%. I still remember the expression on his face: flabbergasted.

The fork

In May, we came out of stealth. We forked OptaPlanner as Timefold Solver and told the world. Soon after, we talked to prospects and by the end of summer we landed our first big customer.

Meanwhile, the original OptaPlanner team joined Timefold. We were back in business!

The Product Market Fit

But sales were rare. We had plenty of inbound - companies using our open source solver in production - but few that saw enough reason to buy. Our Value Proposition was still too weak.

Companies fail because they fail to achieve Product Market Fit.

PMF is almost holy for startups. Maarten obsessed on these two questions:
1) Do people want to use it?
2) Do people want to pay for it?

Most founders fool themselves on these simple questions. I assumed because our solver saves our users a ton of money, they’ll happily pay for it. But assumption is the mother of … Well, I was wrong.

To become viable, we needed a stronger proprietary offering on top of the open source solver. Without crippling the solver.

The platform

The obvious answer was to build a cloud SaaS platform. Almost every other successful open source company did that. But the devil is in the details.

One of our first hires was magic: a next level cloud architect that helped me deliver Employee Shift Scheduling as a docker REST service for an early customer. He started building an efficient architecture to orchestrate solver runs in the cloud. This became the Timefold Platform.

But customers aren’t looking to buy a platform. They’re looking to buy a solution for their problem. Their planning problem. So we created REST APIs for common planning problems - such as Field Service Routing and Employee Shift Scheduling - and deployed them as PlanningAI models on our platform:

As we were building up these teams - Solver, Platform, Models and Solutions - we needed to become a real company.

The startup team

Every aspect of building a startup is a world of expertise on its own. And if you mess up one part, it affects the whole startup. I had many roles and I wasn’t an expert at most of them. Maarten too. So we hired bright leaders who did it better, mostly from the Ghent tech scene.

For me personally, this started one of the hardest periods of my career.

Over the course of a year, one by one, many of my responsibilities were taken away and given to new hires.

I felt like I was losing control.
I wasn’t.
I felt like I could do those jobs better myself.
I couldn’t.

My role was cut up into our:

• Head of Engineering that organizes a steady pace of progress and doesn’t even blink under stress
• Head of Product that tracks everything and deeply understands that a product is more than code
• Head of Customer Success that groks complex constraints and speaks business too
• Head of Marketing that wrote the most crisp copy on what my tech does that I’ve ever seen

Maarten went through this too, but he had gone through this several times.
He delegated responsibilities to our Chief Commercial Officer (CCO) and Chief Financial Officer (CFO).

Smart, experienced people - each and everyone of them - but still our new leadership team went through growing pains. For me personally, alignment felt hard: they were not all engineers. Luckily! Otherwise the company wouldn’t thrive. Or even survive.

With this leadership in place, we’ve handpicked a team of 30+ specialists, each experts in their domains, dedicated to share our planning solutions with the world:

Together, we've built Timefold.

The seed funding

By mid 2024, our cloud product took shape. It was still a beta version, but a few select customers already used our scheduling and routing APIs in production.

Yet, revenue was still low. There was no real sales organization yet. We needed to build the product, before we could sell it. To continue that, we needed extra funding.

There is no middle ground between Bootstrapping and VC funding. Once you take the VC path, it’s natural to raise multiple rounds of funding, such as seed, series A and series B. The ambition is to grow and carve out a path to profitability.

This time, we pitched internationally. As an AI SaaS platform with deep tech, we got a good deal of attention. We ended up signing with Lakestar, one of Europe’s top VC firms. This got us another 6 million euro in the bank and an extra board director who can hustle us an intro to strategic customers and advisors.

The circus

Up to that point, our office was an orangerie, an old greenhouse building in Maarten’s garden. Good enough for a remote-first company. Better than a garage. But between the thorny plants, we ran out of space.

So in September 2024, we moved to the Wintercircus, a huge 130-year old building in the center of Ghent that is now the heart of the startup scene in Belgium.

The SaaS launch

In October 2024 we launched our SaaS platform app.timefold.ai, with REST APIs for Vehicle Routing Problems and Employee Rostering. Soon we’ll add Production Scheduling. And it never crashed. Even now, as enterprise customers hammer it daily to solve big datasets with tens of thousands of employees.

Meanwhile, our solver team made the open source solver remarkably faster, based on feedback from the community and our models team. It’s amazing what “eating your own dog food” can do for a company.

The Go To Market

We also began our outbound marketing campaigns. Meanwhile, our account and solutions teams worked out how to make our customers successful quicker.

Personally, I started posting on my LinkedIn account on how to approach complex scheduling and routing in the real-world. In a just few months, I became a well-known voice in the Operations Research community.

But honestly, we’re still fine-tuning our Go To Market. When it's fully polished, maybe I can write another article about that? It’s good marketing!

The future

This isn’t the entire story of Timefold. This is just my part of the story. Others did far more for Timefold than I could depict here. And our users made the real impact, by applying our technology on thousands of cases.

This is only the beginning.
Our technology is ready.
Our company is thriving.
Our roadmap is ambitious. More on that coming soon.
Our community is geared up. Join us, and subscribe to the newsletter in the footer.
Our APIs are thoroughly documented. Explore it for yourself.
Now is the time to free the world of wasteful scheduling!

Merry Christmas everyone!

We are getting extremely close to Christmas and Santa’s preparations are in full swing. Santa is running a very serious enterprise!

• The gifts needs to be constructed and nicely packaged
• Elves need a work schedule so they know when and where they should help
• And then there is the big question of “how do I visit everyone as efficiently as possible?”

These planning problems are typically tricky to solve… but we can all do this using the power of Java and Timefold, an Open Source AI Solver. So put on your Christmas hats, open your laptops and let’s see how we can use these tools to optimize Santa’s road trip! (or is that a sky trip,…​ I don’t know).

Video walkthrough

This blogpost is also available as a step-by-step video.

Step 1: Model our domain

First, we model our domain, just like we’d do with any other application. With Timefold Solver you can model your domain in Plain Java Objects. Our class diagram will look something like this.

The class structure is pretty straightforward. We got the jolly big man on one side and we have the children Santa wants to visit on the other. They both have a link to the Location object, which is nothing more than a POJO containing the latitude and longitude.

Next we need to order the Visits so Santa can be home again as soon as possible. This is where Timefold Solver comes in. The solver will find a near-optimal order of those visits to keep Santa’s travel time to a minimum.

Timefold Solver needs a little bit more information than a plain POJO. Much like the Java Persistence API (JPA), we need to add a few annotations to our classes for the magic to work. In our case we need to add some annotations to our Santa class. The Visit and Location classes remain untouched.

@PlanningEntity
public class Santa {

   private Location homeLocation;

   @PlanningListVariable
   private List<Visit> visits;

   // excluded constructor getter/setter
}

@PlanningEntity indicates the solver should make changes to instances of the annotated class. Anything which is changeable is typically called a planning variable. An entity can have multiple planning variables, but in this case we only want the solver to change the list of visits Santa will use. To indicate this, we annotate the visits with @PlanningListVariable.

The solver will first fill the list with visits using a greedy algorithm. Greed isn’t good, especially not during Christmas times, so this initial solution will be far from optimal. To improve the situation, Timefold Solver moves the items in the list, looking for a combination which results in a better solution.

Step 2: Add Constraints

We have however not defined what a “good” or “better” solution is. Next, we define a constraint.

A constraint is a business rule expressed in code which modifies the score for a given solution. In our example, the best solution minimizes total travel time. We model this in Timefold Solver using Constraint Streams.

public class SantaConstraintProvider implements ConstraintProvider {

   // NOTE: Normally you'd want to calculate a Distance Matrix before starting the solver.
   DrivingTimeCalculator drivingTimeCalculator = DrivingTimeCalculator.getInstance();
   public static final String MINIMIZE_TRAVEL_TIME = "minimizeTravelTime";

   @Override
   public Constraint[] defineConstraints(ConstraintFactory factory) {
       return new Constraint[]{
               minimizeTravelTime(factory)
       };
   }

   /**
    * Creates a constraint which will reduce the SOFT score by 1 for each second driven by a Santa.
    */
   Constraint minimizeTravelTime(ConstraintFactory factory) {
       return factory.forEach(Santa.class)
               .penalizeLong(HardSoftLongScore.ONE_SOFT,
                       santa -> drivingTimeCalculator.getTotalDrivingTimeSeconds(santa))
               .asConstraint(MINIMIZE_TRAVEL_TIME);
   }
}

In this example for constraint minimizeTravelTime, we select all Santas (yes, in some situations there might be some helpers) and we calculate the total driving time for each Santa. Every second a Santa needs to drive to deliver the gifts will be penalized, decreasing the score of the solution. The solver uses an advanced algorithm to optimize this score.

Santa is a bit weird when it comes to calculating travel time. He doesn’t need roads, so we calculate the distance “as the crow flies”, using the Haversine formula. To convert the distance to total travel time, we’ll assume Santa’s average speed is half the speed of light. You can find the full implementation of this calculation in the DrivingTimeCalculator class on GitHub. In most cases, you should calculate a distance matrix before starting the solving process.

Step 3: Initialize the problem and run!

Now it’s time to bring it all together. The SantaPlan class is once again a POJO, this time collecting all the elements Timefold Solver can work with. It’s annotated with @PlanningSolution and holds all problem facts, planning entities, and a score.

@PlanningSolution
public class SantaPlan {
   @PlanningEntityProperty
   private Santa santa;

   @ProblemFactCollectionProperty
   @ValueRangeProvider
   private List<Visit> visits;

   @PlanningScore
   private HardSoftLongScore score;

    // excluded constructor getter/setter
}

This class contains:

• Our Santa as a @PlanningEntityProperty. This indicates that for this solution, Santa is a planning entity, aka an object which will be changed by the solver.
• A list of Visits. These are the visits which will be assigned to Santa. It’s annotated both with @ProblemFactCollectionProperty to indicate it’s a collection of facts which don’t change while solving, and @ValueRangeProvider to indicate this field provides a range of values the solver can use to assign to Santa, specifically to his @PlanningListVariable field shown earlier.
• A score field annotated with @PlanningScore, which the solver will update with the score of the solution after it has evaluated the constraints.

Next we need a Solver instance which will accept this @PlanningSolution and start working its magic (aka math) on it. While Timefold Solver works in any Java application, when using the Spring or Quarkus extensions, a SolverFactory is autoconfigured based on your configuration properties and classes found on the classpath, like the SantaConstraintProvider we showed before.

In this example I’ll use Quarkus, mainly because the logo looks like a star and has the most Christmas-y colors out of the 2 frameworks.

public class SantaResource {

   private final SolverFactory<SantaPlan> solverFactory;

   // CDI Injected solverFactory
   public SantaResource(SolverFactory<SantaPlan> solverFactory) {
       this.solverFactory = solverFactory;
   }

   /**
    * Uses a solver to sort a list of visits
    * @param visits the locations santa needs to visit
    * @return an optimized plan
    */
   public SantaPlan solve(List<Visit> visits) {
       // This is the location of Santa's village in Rovaniemi, Finland
       Santa santa = new Santa(new Location(66.5039, 25.7294));
       SantaPlan santaPlan = new SantaPlan(santa, visits);

       Solver<SantaPlan> solver = solverFactory.buildSolver();
       return solver.solve(santaPlan);
   }
}

Without configuration the solver will keep searching for better solutions indefinitely. That’s not good, because Santa’s deadline is coming up. Luckily, we can determine how long the solver should run with some configuration.

quarkus.timefold.solver.termination.spent-limit=5s

Note: The call to Solver.solve() above is blocking. To execute asynchronously, we could inject and use a SolverManager instead.

Step 4: Visualize

We can run the code with the Solver, calculate a near-optimal route and then print it… but printing it just doesn’t work for Santa, he needs a map!

These kinds of problems just beg to be visualized. While Timefold doesn’t come with visualizations out of the box, we can expose the data through an API and then have some Javascript to visualize it. In this case, I’ll use the popular LeafletJS library together with the data from OpenStreetMap to visualize our route.

@Path("santa")
public class SantaResource {

   // Fields and constructor excluded

   @POST
   @Path("plan")
   @Consumes(MediaType.APPLICATION_JSON)
   @Produces(MediaType.APPLICATION_JSON)
   public SantaPlan solve(List<Visit> visits) {
       Santa santa = new Santa(new Location(66.5039, 25.7294));
       SantaPlan santaPlan = new SantaPlan(santa, visits);

       Solver<SantaPlan> solver = solverFactory.buildSolver();
       return solver.solve(santaPlan);
   }
}

The code above shows the necessary annotation to expose the objects through an API using Quarkus. Next is the Javascript code used to create a clickable map and render the results from the solver.

// Prepare a custom icon, since default one is not "Christmas" enough.
const treeIcon = L.icon({iconUrl: 'tree-marker.png', iconSize: [20, 20]})

const map = L.map('map', {doubleClickZoom: false}).setView([66.5039, 25.7294], 4);
L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
   attribution: '&copy; <a href="https://www.openstreetmap.org/">OpenStreetMap</a> contributors',
}).addTo(map);

// Create a layer group,
const linesGroup = L.layerGroup().addTo(map);

const visitsOnMap = [];

// Allow adding visits on click
map.on('click', function(e) {
   const { lat, lng } = e.latlng;
   addLocation(lat, lng);
});

// Add a location to the map and to the javascript array
function addLocation(lat, lng) {
   visitsOnMap.push({
       id: visitsOnMap.length,
       location: {
           lat: lat,
           lng: lng
       }
   })
   // Add a marker at the clicked location
   L.marker([lat, lng], {icon: treeIcon}).addTo(map);
}

// The function which will call the solver and visualize the result
function solve() {
   linesGroup.clearLayers();
   fetch('http://localhost:8080/santa/plan', {
       method: 'POST',
       headers: {
           'Content-Type': 'application/json',
       },
       body: JSON.stringify(visitsOnMap)
     })
     .then(response => response.json())
     .then(data => {
           const homeLocation = data.santa.home;
           const locations = data.santa.visits.map(visit => visit.location);

           L.polyline([homeLocation, ...locations, homeLocation]).addTo(linesGroup);

           return data;
      })
      .catch(error => {
           console.error('Fetch error:', error);
      });
}

The result is a backend and a UI, with a map which allows us to add locations and a "solve" button which will call the solver and eventually draws the result on the map.

The full implementation of this very basic UI can be found in the /src/main/resources/ folder of the GitHub repository.

Sending off Santa

In this post we helped Santa to find a near-optimal route. This is only a basic example of what is possible in Java using Timefold Solver. Finally, some inspiration for people who’d like to make changes:

• Use a SolverManager instead of the SolverFactory and run the solver asynchronously while updating the UI with intermediate results
• Add multiple helpers for Santa, splitting the visits among them
• Add more constraints, for example forcing Santa to only visit kids when they are asleep

You can find this project on GitHub. Be sure to check it out and try the demo yourself! For more elaborate examples, check out the extensive Timefold Solver Quickstarts repository.

To all who celebrate I wish you a very merry Christmas and all the good things in the new year!