$ case open banking-onboarding
How onboarding for five applications became a shared platform
An architecture case study of a React/TypeScript library: separating product variation from shared flows, complex forms, and workflow.
- 5
- applications on the shared library
- 6–10
- steps in a product flow
- 273
- configurable fields
- ≈3 mo.
- to the first working flow
01 / Context
One onboarding domain, different products and roles
The banking platform was launched from scratch by a team of three frontend engineers. The challenge was not one multi-step form, but a system that could scale across several products.
My role
Senior Frontend Developer: platform launch, shared libraries, workflows, and shell integration.
Two domains
Client onboarding and staff/compliance workflows for bank employees.
Domain complexity
Legal entities, UBOs, signatories, nested entities, documents/OCR, OTP, and asynchronous checks.
02 / Architecture
Variation in configuration, complexity in the shared core
Switch between the layers to see where product differences, shared logic, workflow, and delivery boundaries live.
Product differences are expressed as data
Products change their flow without copying shared pages.
- Steps and sections
- Fields, copy, and dictionaries
- Document handling rules
03 / Decisions
Four boundaries that keep the system coherent
Configuration over forks
Products define steps, fields, sections, copy, and rules.
A stricter configuration schema, but less product drift.Two shared libraries
Client onboarding and staff/compliance reuse workflows, checks, and documents.
Explicit APIs and backward compatibility become essential.Saga for orchestration
Sequential and parallel checks do not dissolve into UI code.
More explicit orchestration code, but statuses stay controlled.Routes as the remote contract
Each onboarding application exposes routes to the shared shell.
Shared dependency versions and remote boundaries need discipline.04 / Outcome
Shared pages are reused without product branches drifting apart
The value is not merely moving code into a package. Shared behavior changes once, while product differences remain explicit in configuration.
- 5
- applications on shared onboarding
- 4
- applications without separate forks
- 26
- staff workflow statuses
- 9
- internal user roles
Scale
From 6–10 steps to 273 fields and 65 sections.
Reuse
Shared solutions across client and staff domains.
Delivery
Remotes expose routes and connect to the shell.
$ next case
Explore the SFERA performance case study
A memory-leak investigation in a long-lived real-time React interface.