Every line of Apex is a line you maintain forever.

Well-built customization does not, and that is largely a design decision rather than luck. Configuration is the most upgrade-safe option because Salesforce maintains the behaviour behind it. Custom code is safe when it uses documented extension points and does not depend on internal managed-package behaviour that was never guaranteed. The work that breaks is usually the work that reverse-engineered something undocumented because it was the quickest route at the time. We decide upgrade safety before building, and meaningful test coverage is what makes each release a check rather than a gamble.

Yes, through custom work rules that plug into the scheduling policy alongside the standard ones. The important part is that they sit inside the policy rather than trying to override the engine from outside, which keeps the behaviour explainable and lets the optimizer reason about them properly. Before building one, it is worth checking hard that the constraint is genuinely unexpressible — the standard rules cover more than most teams realise, and a custom rule runs against every candidate resource, so a poorly performing one slows every scheduling operation you have.

Extend the standard ones, in almost every case. Work Order, Service Appointment, Service Resource and Asset are wired into the scheduling engine, the dispatcher console, the mobile app and the reporting model. A custom object that duplicates one of them gets none of that for free and has to reimplement all of it. Custom fields and genuinely new related objects are fine and normal. The expensive mistake is building a bespoke "Job" object beside Work Order because the standard model was not fully understood — every report, integration and upgrade then has to handle both forever.

The package ships as managed code, which means its internals are not yours to modify — you extend it where it offers extension points and you work around it where it does not. In practice the scheduling and optimization behaviour is configurable to a considerable degree through policies, rules and objectives, and far less modifiable at the algorithm level. The practical consequence for scoping is that "can we make the optimizer do X" needs checking against the current package capabilities before anyone estimates it, rather than being assumed. We verify that during design rather than discovering it during build.

Build less of it, and document what you do build. The single biggest lever is refusing to write code for requirements that configuration can meet, because that code then needs testing, upgrading and explaining forever. After that it is ordinary engineering discipline: one trigger per object with explicit ordering, bulk-safe patterns throughout, test coverage that actually asserts behaviour rather than just reaching a percentage, and documentation that records why configuration was insufficient. That last point matters most — it is what lets the next person judge whether the custom work is still needed.

Yes, and it is a common starting point. A review covers what exists, whether it is bulk-safe, whether it will survive releases, where it duplicates standard functionality that could replace it, and what the realistic cost is of keeping it versus retiring it. We give you the honest answer including where the existing work is sound, because "rip it all out" is usually neither true nor affordable. The most valuable output is normally the list of custom components that can be retired in favour of configuration — that reduces your maintenance surface permanently rather than just tidying it.