Schema-Driven Flows with Config as Code

The problem

Flows for many markets meant duplicated code and an engineering ticket every time product or compliance wanted to change a regional rule.

The approach

• Render forms from schema. The UI reads JSON or YAML configuration through jsonform: the schema generates the fields and validation rules. Custom actions, like starting a native bridge, stay in code.
• One step, different outcomes. The configuration decides what a step does for each market and platform. Where a native capability is supported the step shows guidance and a scan button; otherwise it shows the normal form fields and a Continue button. Product changes that in config, not in code.
• Config as code. Changes are submitted through Git. Each change opens an automated pull request and runs CI with strict schema validation backed by TypeScript types, so malformed config fails before production.

Two decisions worth explaining

jsonform for rendering, code for actions. A fully server-driven UI that runs arbitrary logic sent from the server invites remote-code-execution risk and performance problems. Data-driven rendering with actions bound to pre-compiled handlers keeps the flexibility without that exposure.

Git instead of an admin form. Easy edits without governance break production flows. Pull requests, type checks and CI make every change attributable, reviewed and easy to roll back.

The result

Config releases no longer depend on frontend deploys, so multi-market updates moved from weeks to hours, and regional code duplication stopped growing.