When are your constraints so specific that a generic solver works against you?
Most commercial planning engines are built around common constraints: capacity, time windows, availability. That works well as long as your operation fits within those boundaries. The problem arises with businesses that have multiple layers of domain-specific rules. Consider a transport company that works with fixed customer agreements on specific driver-client combinations, combined with material certificates per vehicle and time slot restrictions per terminal. A generic solver treats those rules as separate parameters. You know they interact in ways the solver cannot model. The result: the engine produces an 'optimal' schedule that the planner immediately rejects because it is not practically executable. You do not have a planning tool; you have a conflict generator. The question is not whether commercial engines are good, because they are for the average case. The question is whether your operation is average. If the answer is no, building custom planning software is not a luxury but a necessity.
How do you structure the data model so your planning software does not stall as you grow?
This is the lesson that is the least glamorous and the most frequently skipped. Planning software always has a status model: an order is available, scheduled, confirmed, in progress, completed. How you set up that model determines whether the system is still extensible two years from now. The mistake we see is storing status as a loose string in an order table, without transitions, without timestamps, without a record of who did what. That works in a prototype. With a hundred orders per day and three planners working simultaneously, it breaks down. A better approach is a separate status history table with an immutable log of every transition, including the reason and the actor. That may sound like over-engineering, but it is precisely the foundation on which you can later build reporting, auditing, and AI support without restructuring the system. The same applies to the data model for resources: do not just plan today's capacity, but model how resources qualify, expire, and can be combined. A data model that feels logical for the current situation becomes a straitjacket a year from now when the operation grows.
When do you use a library or external solver anyway?
Building custom planning software does not mean writing everything yourself. There are situations where you bring in an existing optimization library, and situations where you are better off not doing so. Use a solver or library when the mathematical problem is generic enough. Route optimization based on distance and time windows is a classic vehicle routing problem. There are mature open-source libraries for that which outperform anything you would build yourself in a few weeks. Do not use a solver when the constraints are so intertwined with domain knowledge that they cannot be expressed in the input format the library expects. That leads to translating your reality into an abstract model, interpreting the output, and manually correcting the results. Then you are worse off than before. The rule of thumb: a solver is a good idea if a mathematician can understand the problem without domain knowledge. If domain knowledge is inseparable from the constraints, build the logic yourself and use the solver at most for a sub-problem. When building custom planning software, you see this pattern in transport, but also in production planning at manufacturing companies and in purchasing planning at wholesalers: the mathematics is generic, the domain rules are not.
What does custom planning software cost compared to an off-the-shelf package?
Honest answer: building custom planning software costs more on day one than buying a license. The initial build costs are real. What you get in return is a system that expresses your constraints precisely, a data model that scales with you, and ownership of code and data without lock-in. A commercial package has a lower entry price, but comes with configuration costs, training costs, adjustment costs for every deviation from the standard, and an annual license that increases as you need more users or modules. The break-even point exists, and it depends on how significantly your operation deviates from the standard. If the deviation is small, buy a package. If it deviates structurally on multiple fronts, custom software is cheaper and better in the long run. The mistake we see is that companies buy a commercial package, work around it for years with Excel and manual corrections, and then switch anyway. That means paying twice.