When should you configure the platform's existing features vs write custom code for a customer?

30-second answerSay your answer out loud first, then reveal.

Prefer configuration and standard platform features: they're supported, upgrade-safe and reusable. Write custom code when the customer's requirement is essential to the outcome and the platform can't meet it: specific integrations, domain logic, data transformations, UX inside their tools. Keep custom code modular, documented and owned, and flag repeated custom needs to the product team as candidates for platform features.

Decision guide

Situation	Approach
Platform feature covers 90% of the need	Configure; adjust the workflow slightly; document the gap
Integration with the customer's unique system (legacy ERP)	Custom connector, built as a reusable adapter if possible
Domain-specific validation rules	Custom code / rules module
One customer wants a niche UI tweak	Push back or defer unless critical
Three customers need the same custom thing	Escalate as a product feature request

Risks of too much custom code

A maintenance burden falls on you or the customer after handover.
Breaks on platform upgrades.
"Snowflake" deployments that the support team can't support.

Good practice: a shared internal library of FDE components (connectors, eval templates, guardrails) so bespoke work is assembled from tested parts.

PreviousHow do you handle customer data access and security in the first weeks of an engagement?

Little by little, you're building something great.

When should you configure the platform's existing features vs write custom code for a customer?

Decision guide

Risks of too much custom code

Related