Most "customization" requests are configuration nobody finished.

Configuration is anything reachable through Salesforce admin tools: picklist values, record types, page layouts, validation rules, report types, permission sets and Flow. That covers most of what lenders ask for. Development begins where those tools cannot express the requirement — complex multi-object logic, callouts to a system with no connector, bulk processing beyond Flow limits, or an interface Lightning pages cannot produce. We name which side a request falls on before quoting it, because the two have very different costs and very different maintenance.

Custom fields on Contact, Loan and Task are ordinary configuration, and the vendor documents editing them through a single help article — a fair signal those three are the core records. New custom objects alongside the package are also fine. What you cannot do is alter the internals of a managed package, so extensions live beside it and reference it rather than editing it.

Well-built extensions should not, because they sit beside the package rather than inside it. The real risk is elsewhere: picklist values are customer-editable and drift against the origination system field map, and Flows built by different people over years start contending on the same object. We manage that with change control, a sandbox release path and a regression check on the sync and the milestone Flows before anything reaches production.

Often, and it is worth scoping carefully. The portal lets referral partners see status, leave notes, submit referrals and reissue pre-approval letters up to a ceiling the loan officer sets. That editable ceiling is a control worth reviewing with your compliance team before you widen it. Extensions beyond the shipped behaviour are Experience Cloud work and are quoted as development, not configuration.

Less than most teams expect. In our experience the majority of "we need a customization" requests are unbuilt configuration — a picklist nobody extended, a recipient matrix nobody finished, a report type nobody created. We check that first, because it is faster and cheaper and there is nothing to maintain afterwards.

Always, and it is not optional at our end. An org where three people built Flows on the same object over two years, undocumented, is the single most common thing we are called in to untangle. You get architecture documentation, a change log and a release path, so the next person to touch it is not doing archaeology.

Yes, and that is a common arrangement. Automation here is Salesforce Flow, so anything can be built and somebody has to own it afterwards. Where that owner does not exist internally we provide the capacity on a retained basis; the support page covers how that works.