Building Configurable Loan Application Flows

A consumer loan application looks simple from the outside — a few screens, some fields, a submit button. Under the hood, every lender wants it slightly different: different fields, different order, different cross-sells, different compliance text. Hard-coding one flow per client doesn't scale past the first handful.

Configuration as the product

The unlock was treating the flow itself as data. A form becomes a schema; a step becomes a node; the UI is just a renderer that walks the config. Now an implementation team can stand up a new lender's flow without shipping code — and the engineering team can improve the renderer for everyone at once.

{
  "step": "applicant",
  "fields": [
    { "id": "ssn", "type": "masked", "required": true },
    { "id": "income", "type": "currency", "required": true }
  ],
  "crossSell": { "product": "credit-card", "when": "score >= 680" }
}

Guardrails keep flexibility from becoming chaos

Total freedom is its own kind of trap — a config that can express anything can also express something broken. The renderer has to be opinionated about what's valid, so a misconfigured flow fails loudly at setup time, not silently in front of a borrower.

• Validate configs against a schema before they ever reach production.
• Give every field type one canonical, accessible implementation — no per-client forks.
• Instrument drop-off per step, so abandonment shows up as data instead of anecdote.

The payoff

Document uploads, e-signatures, and identity verification all became reusable building blocks a config could opt into. Reducing friction in the flow directly reduced abandonment — and because the improvements lived in the shared renderer, every institution got them the day they shipped.

Good abstractions make the common case effortless and the wrong case impossible. That's the bar for anything config-driven.