Ask for Custom Work Last, Not First

Not because building things is expensive, though it is, but because custom code has to be maintained by somebody forever. It has to survive platform upgrades, it has to be understood by whoever inherits it, and it is the first thing that breaks when anything underneath it moves. A feature delivered as configuration costs you nothing after the day it is switched on. The same feature delivered as bespoke development is a small permanent liability. That is not an argument against custom work, which is sometimes genuinely necessary. It is an argument for establishing which category a requirement actually falls into before anybody writes a line, because a surprising amount of what gets scoped as development turns out to be a setting nobody had found.

The most common genuinely bespoke request is some version of making the platform talk to a system you already run, and that is usually not bespoke at all. Accounts, subscriptions, orders, content and sessions are all reachable through the REST API, which means an internal dashboard, a finance reconciliation job, a customer service tool or a fraud check can be built by your own team against a stable interface. The advantage is not only cost. Work done that way lives in your codebase rather than inside the platform, so it survives upgrades and can be changed on your schedule instead of somebody else's. That surface is described under the REST API, which also lists the connectors that already exist.

There is a real category here and it is worth naming honestly rather than pretending everything is configurable. Local payment methods are the clearest example, because payment infrastructure varies enormously by country and a provider that dominates one market may be unheard of in another. Regulatory requirements are the second, since some jurisdictions impose obligations on reporting, on content classification or on data residency that no platform ships by default. The third is a workflow that reflects something specific about how your organisation operates, usually because you came from broadcast or you run an unusual rights model. Those are legitimate reasons to build, and the useful question about each is whether it is a permanent difference or a habit worth revisiting.

Who maintains this in two years, and does that answer survive the people currently in the room leaving. What happens to it when the platform upgrades underneath it. Is this a requirement or an assumption carried over from a system you used to run, because a surprising share of bespoke requests turn out to describe how something used to work rather than how it needs to work. And is the same outcome reachable through configuration you have not explored yet, which is worth twenty minutes before it is worth a proposal. None of those are reasons not to build. They are the difference between custom work that pays for itself and custom work somebody regrets. The configuration surface worth exhausting first runs from white label through packages and subscriptions to conditional access.