Mackenzie Jackson: Welcome to the show.
Geoffrey De Smet: Thank you, Mackenzie.
Mackenzie Jackson: I'm really thrilled to have you here because you have a very interesting story. You are the founder of Timefold, and we're going to kind of get into that whole process. But first, we have some sake to enjoy. We've gone with the 0% sakes this time. The first sake is from the great brewing state of Arkansas in the US. Then we have a second less traditional sake to try, but let's go for those.
Geoffrey De Smet: Okay. Cheers. I've never drank sake. It's the best sake I've ever drank.
Mackenzie Jackson: Timefold.ai is all about kind of dealing with very complex schedules, and we'll get into that, but it actually came from an open-source project, which is kind of interesting because it's a very different approach than most startups. I just kind of want to start at the very beginning, where did this open-source project start? Did you start with the idea of forming a business, or how did that whole process start?
Geoffrey De Smet: I started it 19 years ago, and originally it wasn't even called OptaPlanner. These days we call it Timefold Solver, that's the new name. But originally, 19 years ago, I was working as a researcher. I graduated three years earlier, I did two years consulting and being a developer, a Java developer. I wanted to change the world, so I went into research because I was going to invent something that would change the world. After a while there, I got a little bit jaded because I saw all of the research ending up as papers into these closets. Back then, everything was still printed. So, I started doing some open-source work in the evenings and on the weekend, mostly for karma reasons because the worst thing you can do to a builder is have them build something that nobody will use. So, I needed to build something that people would use. Anyway, at some point, there was this researcher who showed how they solved a nurse rostering problem with taboo search, which is a metaheuristic, which is an AI algorithm. So, what is the use case? You need to assign shifts to nurses, for example, an early shift, a late shift, an evening shift. But of course, the nurses have different skills, not everybody can work on the maternity ward and things like that. So, you need to make sure that it fits as well as possible and that the nurses, when they want to have a day off on a particular day, that they actually get that. All right. So, a really cool presentation, and he was explaining how it took him a month to do the algorithms part and six months to do the scoring part, figuring out if you have two shifts at the same time, if they block or not. What happened was that six months, I figured, why does it take so long? The real reason was because not just because of the complexity of the constraints like you cannot have two shifts at the same time, or somebody cannot do a particular skill, but because of the fact that you need to do something called incremental score calculation, which is the ability to say you have a particular solution, you make a small change, and then you recalculate the new score of the new solution of the new schedule and check if it's a feasible schedule, if it's a good schedule. You want to be able to do that not one time per second, but 100,000 times per second. To be able to do that, to be able to scale, you need to do that incrementally. And that took him six months to develop. I was looking at that presentation there and I was looking like, I've seen an open-source project that can do this for us. I've seen a rule engine six months ago at this developer conference. We need to do that. Of course, they just completely ignored me. But during the summer break, I figured, I'm going to do this. And I thought I did. I created this proof of concept. I came back and said, look, it works. I remember the professor there looking at me, smiling, like, yeah, you don't know anything about this, and this will lead to nothing, which was fair at the time because it was basically a proof of concept of a proof of concept. So I started continuing that in my spare time because there was this competition, an international timetabling competition, where we needed to assign lessons to schools, to teachers, and mostly to rooms and to time slots. There was this academic competition, and they pointed me out to that, and I said, okay, I'll try my little framework on that. I spent a couple of months of my spare time doing that, and I ended up fourth in that competition. So I figured there needs to be something in there. There has to be something useful in this. At some point, it was all absorbed by Red Hat. How does that happen? How does Red Hat end up kind of taking control or owning or participating in an open-source project?
Mackenzie Jackson: We are raised sometimes, right?
Geoffrey De Smet: What happened for me, right after a year I was building this, and I saw there was an IRC channel, if you still remember that, real-time chat, like Discord from back then. There was an IRC channel of the rule engine I was using, the open-source project I was using under the hood, where I was writing the metaheuristics and the rule engine was doing the score calculation for me. So I joined that and I basically got invited there to host my project as an incubator subproject, a subproject. That rule engine was called Drools. So my thing was called Drools Solver. In hindsight, naming a project Drools is not good for business adoption. So after a few years, I joined Red Hat. I got hired to work on the Drools rule engine. In my spare time, I was still doing what is now known as Timefold Solver, what used to be known as OptaPlanner. But then by 2013, they saw people actually using it all across the world, and they had customers asking, can we get support on this? So they started selling support, and they told me, yeah, you can work full-time on this. So my hobby became my job. I was very happy because that's the only thing I wanted to do. And so that's how it started. Then for the next nine years, I worked on it in Red Hat, and we built out a team, and more and more users across the world, and everything went beautifully.
Mackenzie Jackson: When did you decide to turn it into a business? What was that whole process like?
Geoffrey De Smet: So the normal founders are like, I had this idea of building a company and things like that. I was basically strong-armed into building a company. What happened was, I remember IBM acquired Red Hat in 2019, and everybody was scared because IBM had basically the competitor of our project, the main competitor, which in hindsight wasn't really a competitor. They solved different use cases. It's called Cplex. And it's also no longer around. So two interesting things, but they also had the competitor for the Drools, for the rule engine. And that was basically a dual play. So that was really the two main projects were then owned either directly by IBM or through Red Hat by IBM. Everybody was losing their heads and like, okay, how do we deal with this? How can we position ourselves? Nothing happened for the first two or three years. But then after three years, all of a sudden, I woke up, there's a meeting, and it turns out they're moving the whole product suite to IBM. Now, you have to understand that the whole OptaPlanner thing was a small part of this, a very small part of this, but it probably didn't even blink on the radar of higher management. So they were moving the rule engine part to IBM, and they didn't really know what to do with OptaPlanner. But because they were moving the support subscription to IBM, OptaPlanner was virtually dead because it no longer had anything to sell. Of course, you know what happens if you're building something in a company where there's no commercial incentive to do that? It's a very bad path to go down. In February, they told me, you know, we're going to move it. And I was like, what am I going to do? Maybe I should quit and fork this project because this is my life's work, maybe not. I was thinking about it and talking to my wife about it, and she had one conversation with me where she just said, you know, go for it, you get a year, just do it. She already made a decision, let's do this. And I was like, no, no, no, I have to think about this, I have to analyze this, I have to do this rationally, you know, make some SWOTs and figure out my entire plan. Then July came around, and by July, they were going to make a decision on how they would sell OptaPlanner within Red Hat, how they would continue to support customers. Basically, the person in charge of that called me up on the 4th of July, and he told me that he was moving to IBM, and so he had no solution. So after three months of waiting, there was no solution. Then I knew, okay, there's no other way, I need to fork this, I need to start a company around this.
Mackenzie Jackson: It's really interesting because it's kind of like an opposite journey to a lot of startups nowadays, where I feel like a lot of them have this flashy go-to-market scheme, they have this great business model, but then the product itself is, let's say, lacking. Yours is the opposite. You had this great product. You had this very mature product going out there. But in a way, you kind of lacked that go-to-market. So on that go-to-market strategy, how did you then commercialize that? How do you at Timefold make money? I don't want to be so crass, but how did you turn this into a commercial venture and not just an open-source venture?
Geoffrey De Smet: No, so originally we thought we'll just do the same thing as Red Hat. We'll just sell support on it. But we're a small shrimp, not a big company. And it turns out that doesn't really work. In fact, if you look into all of the open-source companies and the open-core companies, only Red Hat really succeeded in just selling support and making everything open source and just selling support. Everybody else is basically using the open-core model where they basically say, okay, we make a part of it open source, the core, and you can, and we make it usable. You can do stuff with it, you can do a lot of things with it, but then we provide you with additional services. And because the users of the open source see, okay, this actually works, this is high quality, they're also interested in seeing what these extra features are. So what we've done is we've started building REST APIs on top of our solver. So basically, you have the solver. You can solve any planning problem with that. You can still, just like in OptaPlanner, you can do this with Timefold Solver. And then on top of that, we are creating a REST API specifically for field service routing, specifically for employee shift scheduling, for job shop job scheduling, and for last-mile delivery and pickup and delivery routing. So basically, instead of you saying, okay, I need to configure this whole thing, and I need to configure my constraints or actually program my constraints, you can actually just send in your data. Here are my vehicles, here are my stops that I need to do, here are the skills I need per stop and things like that, and it will actually solve it for you and give you back the answer. So it's a very easy-to-use REST API, which basically, you know, you can skip a lot of development this way. When we started the company, one thing we saw very clearly is we had this very mature product and this very immature go-to-market, right? We had no clue what we were doing on the go-to-market side. We knew everything what we were doing on the product side and using real-world planning, solving real-world planning problems. But how that started out was, I didn't know anything of building a company. I had never founded a company. But I knew I didn't know much about it. So I started reading some books. One book is really good, it's called The Founder's Dilemma. It's a very thick book. It's very slow to read, but it really goes through most of the steps you need to know. And one of the interesting things this book told me is you need to look for a co-founder or co-founders who don't have the skills you have, who have opposite skills, who are very diverse and related to you. So I was talking to somebody, but that person couldn't join in the end, and so I ended up contacting one of the VCs in Belgium. A friend of mine, a CTO at a local Gen startup, told me, you have to talk to this person. And so I sent the investor an email and said, okay, I'm looking for a co-founder. I think I have an interesting project. And he said, okay, let's meet up for 30 minutes. Actually, right there at that bar over there. And I remember sitting there for 30 minutes, and I came in, and I started talking, and I started showing, okay, this is what the project does, and this is what I want to do with it and things like that. And I ended up talking for two hours. And after like two hours, I'm like, you know, is this okay? And he says, keep going, keep going. So I figured like, okay, you know, I have an investor already, and now he's just, he'll find a co-founder for me, and, you know, we'll have this running in no time. And so when he got home, he actually called my current co-founder, and he told him, like, I have something here. It's an interesting project. There's no way this is investment ready. We need somebody who knows how to do business to add here, right? So I knew that, but I was looking for a salesperson. Now what you don't need is, what you need is a salesperson, of course, too, somebody who can sell, a business-minded person, but you need somebody who can build an organization. So my co-founder, Maarten, the investor connected us, and so we started talking and we started figuring out, okay, how are we going to build a company around this, basically.
Mackenzie Jackson: So let me just kind of ask a stupid question: why can't you just take all this scheduling data that you have, put it into ChatGPT, and have it create a schedule for you? What is the difference between what you do, I believe you use the word heuristic AI, how does ChatGPT kind of differ from that?
Geoffrey De Smet: Yeah, you can do that. You can give it all of your data, say, generate me a schedule for this. And it will look good, if you, on first sight. But if you give it to somebody who actually has to make these schedules for big industries, for factories, or for field service routing, they will take one look at it and tell you, okay, that's a mistake. That won't work. Here's a hard constraint broken. This is where it's infeasible. They do this every day, and they can spot out the mistakes easily. Now, the problem with this entire with complex scheduling and routing is the bar to get something feasible, to get something usable you can use in the real world, is extremely high. It doesn't have to be, like, 80% is not good enough. It needs to be all, for the hard constraints, it needs to be 100%. The interesting thing I always say is, you know that quote where you say, programming is like writing a book except if you have a punctuation error on page 352 the whole thing becomes useless?
Mackenzie Jackson: I haven't heard that before, but I love it.
Geoffrey De Smet: Yeah, it's a great quote, I think. Well, planning problems are a little bit the same, except for the difference that if you have that punctuation error on page 357, you can go in and fix it. If you try to do that with a plan where you have this huge plan on one of them, and there's a small hard constraint broken somewhere, and you try to fix that, you often break more stuff than you fix. So it's really hard to come up with a plan that fulfills all hard constraints. Now when you look at how LLMs solve this, what they do is they work stochastically, right? So they remember patterns, they say, if it looks like this, I'm going to do the same thing. And these kinds of techniques simply don't work on scheduling and planning problems because they are inherently what the mathematicians call NP-hard, which basically means that it is the famous P versus NP question, but it basically means there's no simple way to just say if this is the input, this is the optimal schedule or near-optimal schedule. You have to basically look through almost all possibilities. You don't have to, there are better ways you can look at the most promising solutions first. But just to give you an idea, if you want to look through all possible solutions, if you want to brute force this and you're assigning something like 20 shifts to, sorry, 100 shifts to 20 people, to 20 employees, you will actually have, that's 20 to the power of 100 solutions, and that's more than the minimum number of atoms in the observable universe. So there's no way you can brute force this. The LLM, what it does, it looks for patterns, and it starts building a part, but it breaks hard constraints all over the place. That being said, the LLMs are very useful because what they can do is they can provide you an interface to a solver like Timefold. Just like they can provide an interface to a calculator. If you ask it what is 5 plus 7, let's hope it doesn't try to solve it itself. What it does, it gives to a calculator 5 plus 7 is...
Mackenzie Jackson: It's interesting the way that you describe it because you're really describing it as building this specific model, this heuristic AI model, right? But it's quite different to, I think, how a lot of us kind of are experiencing AI when you have these gigantic AI models that do everything. Now, they do everything kind of poorly, but they do everything. So, it's not machine learning. You don't train it. There's now a few techniques where you can say, I'm going to use a little bit of machine learning in there, similar to how they did for AlphaGo, right? Where they solved the Go playing thing with traditional algorithms, but at the leaf part, they interject into, they put some machine learning. But the basic algorithm is a metaheuristic algorithm for solving planning problems. So what it basically does is first, well, we actually run two algorithms. First, we run an algorithm to create a greedy solution, which is very similar to what you would do as a human planner. So what happens is you take one shift, you assign it to a person, you take another shift, you assign it to a person, but you make sure that you don't break any hard constraints and minimize your soft constraints. You find the best possible spot for that shift. You do it one at a time, one shift at a time. Now, the problem is that the first shift you assigned is probably already not the optimal location because you don't know where to put it. And so the greedy algorithm sorts all of these shifts, and then the metaheuristic comes around, and what that one does, it starts swapping shifts, which humans also do. You get a schedule, you say, this isn't good, let me see if I can swap some things around. But the difference is that a human does maybe five or 10 of those per, you know, five minutes or something like that, and spends two, three hours doing this, then gives up and publishes it out. Our algorithm does 100,000 swaps and stuff like that per second. So it literally looks at millions and millions of combinations upon that greedy algorithm. And that's why we deliver much, much better results than manual planning. Where we, where we reduce for shift scheduling the amount of, you know, people can get their day off requests more like 50% more. And also in vehicle routing, we reduce the travel time a lot and the fuel consumption a lot. And this is huge productivity-wise. This saves not millions of dollars, but hundreds of millions of dollars.
Mackenzie Jackson: There's a line on your website that's something along the lines of, we will save you thousands of hours in scheduling, but we can't write an email for you. I just loved that line. Is this something that you experience being in AI? Are there lots of kind of processes going down with these specific AI models, or is all the attention and kind of sexy VC funding going to these kind of gigantic LLM type models in your experience?
Geoffrey De Smet: Well, there's definitely sexiness in the AI technology, LLM technology, where you can talk to for VCs, and there's definitely a big demand for that. And of course, the last few months, we're seeing some slowdown in the capabilities of it going towards AGI. Now, that being said, I think we've seen a number of these waves. Let's call it hype cycles or whatever you want to call it. We've seen it with cloud, we've seen it with blockchain, we've seen it with mobile, we've seen it with augmented reality, and these had very different results. For example, cloud, everybody's using cloud, right? So, and I do believe that AI is fundamentally changing the game. Now of course, in the beginning of cloud, people didn't really know what it was useful for and where it wasn't useful for, right? Same thing with mobile. I remember actually putting my solver on a mobile phone, right? You can still do this today. It's completely useless because what you need to do is you need to solve a planning problem for where a lot of people are involved. Sometimes 10,000 employees are involved in a single schedule. Why would you want to do that on somebody's phone, right? You need to bring all the data together, right? And you cannot distribute across the phones, right? So it's completely useless, right? But still everybody was saying, oh, mobile is the big thing now, right? So we got like, okay, build something for mobile. We've spent a lot of resources at Red Hat on trying to do something with edge computing around OptaPlanner, but it's, it's, yeah, it doesn't make any sense. So the same thing is happening, I think, with the AI wave. They are saying, okay, everybody needs to use AI. If you're not thinking about AI, if you're not doing something and what we're seeing right now is basically we're seeing the good and the bad use cases being separated from each other. Take the notetakers. Those are brilliant, right? Those just work. Think of ways of interacting with something complex, like when you talk natural language and you get something back from the system. That's quite useful, right? So we're actually envisioning a way where you can with an LLM talk to your schedule, where Timefold is then solving the schedule for you and then making adjustments for you. So it's just a better interface, right? So there's definitely use there. However, will it solve your planning problem and generate all of the things you might want to have in your planning problem for you? I'm skeptical.
Mackenzie Jackson: I want to double tap on something that you said just there because I want to also kind of understand some of the business behind this. You mentioned in there the thousands of hours that you can save during this. Now I'm going to use an example that you've already given in here is that you have 20 people and 100 schedules. What would that take to do that manually and the kind of the issues there, and what would it take with Timefold to actually do that with Timefold and the kind of time-saving difference there?
Geoffrey De Smet: So first of all, how long does it take if you do it manually? I've talked to head nurses in hospitals and things like that. A head nurse who has a department of 40 people once told me every Tuesday afternoon he's making the entire schedule. That's his Tuesday afternoon. And at the end of the afternoon, he's happy if he has a feasible schedule. So feasible means that, you know, nobody has to work two shifts at the same time. Everybody has enough time between two shifts. Taking care of things like, oh, someone wants a day off on Wednesday afternoon, that's really just a secondary nice-to-have concern that they might or might not look at if it's feasibility, and they push it out. So what we do is we solve the same schedule in minutes, two minutes, three minutes, right? And we actually take into account also those day off preferences, and we do a much better job of that simply because we can do the same job much, much faster. So you might wonder, right, okay, if this is such a great technology, that saves planners hours and then also delivers much better schedules, which in some cases, not for shift scheduling, but for like vehicle routing, literally saves millions of hours of production usage, why isn't everybody using it? And again, it's that high bar, right? You talked about it in AI too, like I guess it has the same problem, right? It's not just having a schedule that's 80% good is not good enough. It's 100% useless. If you break one hard, if you tell one person to be at two places at the same time, your schedule is useless, right? And so, and then if you try to fix that, the whole thing breaks apart. And so that's why this technology existed for almost 30 years now, the research discipline for since the Second World War. And yet we still see that in practice, most people are still making plans manually or in Excel. And so that's the big thing for us. How can we make it easy for them to consume our software and make these plannings better? Basically, how can we free the world of wasteful scheduling, as you said?
Mackenzie Jackson: Well, we are coming to the end here, but we do like to play a game called "Would You Rather" on this show. Before we do that, we have one more sake to try. Now, the last sake was kind of a traditional sake in terms of its brewing techniques. This one is definitely not. It is still sake, but it's kind of infused with different things. It's quite interesting. 0% again. So, let's try that.
Geoffrey De Smet: Cheers. Thank you. Cheers. Yeah, it's good. It's strong. I like it.
Mackenzie Jackson: Would you rather have all of your scheduling done by ChatGPT and you cannot use Timefold, because I know that you'll want to kind of use that, but either entirely by ChatGPT or you have to manually do it, what would you rather?
Geoffrey De Smet: 100% ChatGPT. Yeah. Can I ask it to use a solver like Timefold to generate code for that?
Mackenzie Jackson: You're allowed it just because, yeah, that's a sticky one, but yeah.
Geoffrey De Smet: It depends on the complexity of the problem. If it just has like three or five constraints, if it's like a very what I call an academic problem like vehicle routing where you need to send a number of vehicles around the country, they have a capacity that need to deliver few items, then I would say, okay, let's use ChatGPT because it can actually generate the code for that very quite well already. It just copy-pastes it from our library or some of the others examples, right? And then you just run that. Where it gets more interesting is when you start adding more real-world constraints, like if it's for real vehicles where drivers have skills, where they need to be, they have, they can work overtime. Some of them are freelancers, others are contractors, and you want to, you know, maybe first schedule all of your employees before you start using the contractors and things like that, right? Then this will break down. You will hit the wall at some point. It's like when you use no-code or low-code. It's great at the beginning. At some point, you hit the wall and it hurts.
Mackenzie Jackson: All right, I have another, I have another one here. Similar question, but a little bit different. Would you rather write all your code manually, you cannot use any AI assistance tools, or you got to go down the Vibe path and you can only use AI vibe coding tools? You can pick whatever model you want. You can pick whatever system you want, but you have to prompt all of your engineering code. What would you rather?
Geoffrey De Smet: I'm old school, so I will definitely default to writing it manually. I do use ChatGPT and Claude and things like that to ask it questions and get back, you know, how do I solve this method or how do I do that. I was programming with my daughter yesterday, something on Android. I haven't done Android development in 15 years. So, I was using that to show her like, this is how we do it, right? But that being said, if it's a serious project, if it's something that has to go into production, definitely manual coding. If it's a prototype where it's just for a PowerPoint presentation to show, look, this is possible, to inspire people, then I would definitely consider also the prompt coding approach.
Mackenzie Jackson: Well, thanks, Geoffrey, for coming here. It's been a fascinating conversation. I really look forward to seeing Timefold.ai evolve over the years and hopefully have you back on the show. So, thanks so much for being here.
Geoffrey De Smet: Thank you, Mackenzie.
