UI / UX Design
Brand Is a Variable
How a solo designer built one design system that ships a loan origination platform as 10+ differently-branded products — across light and dark modes, and from dense desktop dashboards to mobile borrower journeys — without forking a single component.
Year :
2025-26
Industry :
Design
Client :
Algebrik
Project Duration :
6 months
One product, many faces
Algebrik AI builds a loan origination platform - but it never ships as one product.
The same core ships as a Loan Officer Portal, a borrower-facing Point-of-Sale portal, internal ops tools, and the marketing website. Then multiply that by clients: 10+ credit unions and lenders, each white-labeling the platform under their own brand guidelines.
As the sole designer, I was effectively designing N products, where N grew with every signed client.
The breaking point
Three pressures converged:
Inconsistency at scale. The same button, card, or data table was drifting across surfaces. With one designer and multiple engineering streams, every undocumented decision got re-decided slightly differently downstream.
The "client's eyes" problem. Sales and onboarding had no way to answer a basic question: what does our LOS look like as your product? Re-skinning screens manually per prospect was hours of throwaway work, repeated for every client.
Multi-device reality. Loan officers work in dense desktop dashboards; borrowers complete applications on phones. Responsiveness was being solved screen-by-screen instead of system-wide.
Three layers, one rule
Components never touch raw values. Every component references semantic tokens only. Which is what makes brand, theme, and device swappable without touching a single component.
Theming is the same move, applied twice
Dark and light modes aren't a separate system, they're a mode switch on the semantic layer. surface-raised resolves to one value in light, another in dark; components stay untouched. Once that mechanism existed, client branding was the same mechanism applied at the alias layer:
Any client × any theme × any device with zero per-combination design work.
Switch the brand or theme above this dashboard re-renders through the token chain with no component changes. This page is built on the same three-layer architecture it documents.
How token values resolve
Semantic token | Algebrik | Credit Union | Lender Co |
|---|---|---|---|
action-primary-bg |
|
|
|
surface-brand-tint |
|
|
|
text-on-action | Computed per brand — contrast-checked against | ||
Where the system had to say no
A multi-tenant system is defined less by what it allows than by what it refuses. Three decisions shaped everything downstream.
Draft note: These three are written from what you've described plus the most common white-label realities. Confirm, correct, or replace with the fights you actually had - real specifics here are worth more than polished hypotheticals.
Client brand colors vs. accessibility
Client brand guidelines were written for marketing, not for software. A brand primary that works on a billboard can fail contrast as a button fill or status color. The system's position: brand owns identity; the system owns legibility. Functional colors text on actions, statuses like approved/rejected/pending, error states are derived or system-controlled, contrast-checked against the client's palette rather than copied from it.
Trade-off accepted: a client's LOS is recognizably theirs, but never pixel-identical to their brand book. That's a conversation onboarding has once instead of an accessibility problem every borrower has forever.
The customization boundary
Every white-label system dies one of two deaths: too rigid (clients reject it) or too open (every client becomes a fork). I drew the line explicitly: clients customize the alias layer palette, logo, key brand surfaces. They do not customize structure layout, component anatomy, interaction patterns, or information hierarchy stay system-owned.
Why it held: the boundary is enforced by architecture, not by policy. There is simply no token a client theme can set that moves a layout. Saying no became a property of the system instead of a recurring negotiation.
Two postures, one component set
The Loan Officer Portal and the borrower POS aren't the same product at different widths they're opposite postures. Officers need density: more data per viewport, smaller type, tighter spacing. Borrowers need focus: one task at a time, generous touch targets, mobile-first. Rather than two component libraries, density lives in spacing and type token modes the same data table or form field composes into a dense desktop posture or a roomy mobile one by switching modes.
Trade-off accepted: a handful of components carry posture-specific variants where token modes weren't enough. Honest cost, paid in a few components instead of a parallel library.
A system of one, used by many
A solo designer can't review every screen. The system had to encode my judgment so it applied when I wasn't in the room.
Naming as API. Semantic token names were written for engineers, not designers action-primary-bg tells a developer what to use without asking. The token vocabulary became the shared language between design files and code: handoff stopped being "what hex is this?" and became "which token is this?", a question that answers itself.
Client onboarding as a workflow, not a project. A new client's brand becomes a new alias collection: populate the brand tokens from their guidelines, contrast-check the functional derivations, and every surface LOP, POS, comms re-renders in their identity. What used to be a manual re-skin per prospect became a repeatable, hours-not-days step in onboarding.
The sales-demo dividend. The same mechanism answered the "client's eyes" problem: prospects could be shown their LOS, in their brand, before signing turning the design system into a sales asset, not just an engineering one.
The AI stress test
The strongest validation of the token architecture came from outside Figma: I used the token system to generate production-grade HTML with Claude Code. Because the system's semantic layer describes roles rather than appearances, an AI agent could compose correct, on-brand, theme-aware UI from token names alone no screenshots, no eyeballing.
What variation costs now
The deeper outcome is organizational: brand variation stopped being design work. New clients, new themes, and new surfaces draw from the system instead of drawing on me which is the only way a one-designer team supports a multi-tenant product without becoming its bottleneck.
What I'd do next
The system's ceiling today is sync: tokens live in Figma Variables and travel to code through structure and convention. The next maturity step is a tokens-as-code pipeline (Style Dictionary or equivalent) so a client theme committed once propagates everywhere and so the AI-generation workflow runs on the same source of truth engineering ships.
UI / UX Design
Brand Is a Variable
How a solo designer built one design system that ships a loan origination platform as 10+ differently-branded products — across light and dark modes, and from dense desktop dashboards to mobile borrower journeys — without forking a single component.
Year :
2025-26
Industry :
Design
Client :
Algebrik
Project Duration :
6 months
One product, many faces
Algebrik AI builds a loan origination platform - but it never ships as one product.
The same core ships as a Loan Officer Portal, a borrower-facing Point-of-Sale portal, internal ops tools, and the marketing website. Then multiply that by clients: 10+ credit unions and lenders, each white-labeling the platform under their own brand guidelines.
As the sole designer, I was effectively designing N products, where N grew with every signed client.
The breaking point
Three pressures converged:
Inconsistency at scale. The same button, card, or data table was drifting across surfaces. With one designer and multiple engineering streams, every undocumented decision got re-decided slightly differently downstream.
The "client's eyes" problem. Sales and onboarding had no way to answer a basic question: what does our LOS look like as your product? Re-skinning screens manually per prospect was hours of throwaway work, repeated for every client.
Multi-device reality. Loan officers work in dense desktop dashboards; borrowers complete applications on phones. Responsiveness was being solved screen-by-screen instead of system-wide.
Three layers, one rule
Components never touch raw values. Every component references semantic tokens only. Which is what makes brand, theme, and device swappable without touching a single component.
Theming is the same move, applied twice
Dark and light modes aren't a separate system, they're a mode switch on the semantic layer. surface-raised resolves to one value in light, another in dark; components stay untouched. Once that mechanism existed, client branding was the same mechanism applied at the alias layer:
Any client × any theme × any device with zero per-combination design work.
Switch the brand or theme above this dashboard re-renders through the token chain with no component changes. This page is built on the same three-layer architecture it documents.
How token values resolve
Semantic token | Algebrik | Credit Union | Lender Co |
|---|---|---|---|
action-primary-bg |
|
|
|
surface-brand-tint |
|
|
|
text-on-action | Computed per brand — contrast-checked against | ||
Where the system had to say no
A multi-tenant system is defined less by what it allows than by what it refuses. Three decisions shaped everything downstream.
Draft note: These three are written from what you've described plus the most common white-label realities. Confirm, correct, or replace with the fights you actually had - real specifics here are worth more than polished hypotheticals.
Client brand colors vs. accessibility
Client brand guidelines were written for marketing, not for software. A brand primary that works on a billboard can fail contrast as a button fill or status color. The system's position: brand owns identity; the system owns legibility. Functional colors text on actions, statuses like approved/rejected/pending, error states are derived or system-controlled, contrast-checked against the client's palette rather than copied from it.
Trade-off accepted: a client's LOS is recognizably theirs, but never pixel-identical to their brand book. That's a conversation onboarding has once instead of an accessibility problem every borrower has forever.
The customization boundary
Every white-label system dies one of two deaths: too rigid (clients reject it) or too open (every client becomes a fork). I drew the line explicitly: clients customize the alias layer palette, logo, key brand surfaces. They do not customize structure layout, component anatomy, interaction patterns, or information hierarchy stay system-owned.
Why it held: the boundary is enforced by architecture, not by policy. There is simply no token a client theme can set that moves a layout. Saying no became a property of the system instead of a recurring negotiation.
Two postures, one component set
The Loan Officer Portal and the borrower POS aren't the same product at different widths they're opposite postures. Officers need density: more data per viewport, smaller type, tighter spacing. Borrowers need focus: one task at a time, generous touch targets, mobile-first. Rather than two component libraries, density lives in spacing and type token modes the same data table or form field composes into a dense desktop posture or a roomy mobile one by switching modes.
Trade-off accepted: a handful of components carry posture-specific variants where token modes weren't enough. Honest cost, paid in a few components instead of a parallel library.
A system of one, used by many
A solo designer can't review every screen. The system had to encode my judgment so it applied when I wasn't in the room.
Naming as API. Semantic token names were written for engineers, not designers action-primary-bg tells a developer what to use without asking. The token vocabulary became the shared language between design files and code: handoff stopped being "what hex is this?" and became "which token is this?", a question that answers itself.
Client onboarding as a workflow, not a project. A new client's brand becomes a new alias collection: populate the brand tokens from their guidelines, contrast-check the functional derivations, and every surface LOP, POS, comms re-renders in their identity. What used to be a manual re-skin per prospect became a repeatable, hours-not-days step in onboarding.
The sales-demo dividend. The same mechanism answered the "client's eyes" problem: prospects could be shown their LOS, in their brand, before signing turning the design system into a sales asset, not just an engineering one.
The AI stress test
The strongest validation of the token architecture came from outside Figma: I used the token system to generate production-grade HTML with Claude Code. Because the system's semantic layer describes roles rather than appearances, an AI agent could compose correct, on-brand, theme-aware UI from token names alone no screenshots, no eyeballing.
What variation costs now
The deeper outcome is organizational: brand variation stopped being design work. New clients, new themes, and new surfaces draw from the system instead of drawing on me which is the only way a one-designer team supports a multi-tenant product without becoming its bottleneck.
What I'd do next
The system's ceiling today is sync: tokens live in Figma Variables and travel to code through structure and convention. The next maturity step is a tokens-as-code pipeline (Style Dictionary or equivalent) so a client theme committed once propagates everywhere and so the AI-generation workflow runs on the same source of truth engineering ships.
UI / UX Design
Brand Is a Variable
How a solo designer built one design system that ships a loan origination platform as 10+ differently-branded products — across light and dark modes, and from dense desktop dashboards to mobile borrower journeys — without forking a single component.
Year :
2025-26
Industry :
Design
Client :
Algebrik
Project Duration :
6 months
One product, many faces
Algebrik AI builds a loan origination platform - but it never ships as one product.
The same core ships as a Loan Officer Portal, a borrower-facing Point-of-Sale portal, internal ops tools, and the marketing website. Then multiply that by clients: 10+ credit unions and lenders, each white-labeling the platform under their own brand guidelines.
As the sole designer, I was effectively designing N products, where N grew with every signed client.
The breaking point
Three pressures converged:
Inconsistency at scale. The same button, card, or data table was drifting across surfaces. With one designer and multiple engineering streams, every undocumented decision got re-decided slightly differently downstream.
The "client's eyes" problem. Sales and onboarding had no way to answer a basic question: what does our LOS look like as your product? Re-skinning screens manually per prospect was hours of throwaway work, repeated for every client.
Multi-device reality. Loan officers work in dense desktop dashboards; borrowers complete applications on phones. Responsiveness was being solved screen-by-screen instead of system-wide.
Three layers, one rule
Components never touch raw values. Every component references semantic tokens only. Which is what makes brand, theme, and device swappable without touching a single component.
Theming is the same move, applied twice
Dark and light modes aren't a separate system, they're a mode switch on the semantic layer. surface-raised resolves to one value in light, another in dark; components stay untouched. Once that mechanism existed, client branding was the same mechanism applied at the alias layer:
Any client × any theme × any device with zero per-combination design work.
Switch the brand or theme above this dashboard re-renders through the token chain with no component changes. This page is built on the same three-layer architecture it documents.
How token values resolve
Semantic token | Algebrik | Credit Union | Lender Co |
|---|---|---|---|
action-primary-bg |
|
|
|
surface-brand-tint |
|
|
|
text-on-action | Computed per brand — contrast-checked against | ||
Where the system had to say no
A multi-tenant system is defined less by what it allows than by what it refuses. Three decisions shaped everything downstream.
Draft note: These three are written from what you've described plus the most common white-label realities. Confirm, correct, or replace with the fights you actually had - real specifics here are worth more than polished hypotheticals.
Client brand colors vs. accessibility
Client brand guidelines were written for marketing, not for software. A brand primary that works on a billboard can fail contrast as a button fill or status color. The system's position: brand owns identity; the system owns legibility. Functional colors text on actions, statuses like approved/rejected/pending, error states are derived or system-controlled, contrast-checked against the client's palette rather than copied from it.
Trade-off accepted: a client's LOS is recognizably theirs, but never pixel-identical to their brand book. That's a conversation onboarding has once instead of an accessibility problem every borrower has forever.
The customization boundary
Every white-label system dies one of two deaths: too rigid (clients reject it) or too open (every client becomes a fork). I drew the line explicitly: clients customize the alias layer palette, logo, key brand surfaces. They do not customize structure layout, component anatomy, interaction patterns, or information hierarchy stay system-owned.
Why it held: the boundary is enforced by architecture, not by policy. There is simply no token a client theme can set that moves a layout. Saying no became a property of the system instead of a recurring negotiation.
Two postures, one component set
The Loan Officer Portal and the borrower POS aren't the same product at different widths they're opposite postures. Officers need density: more data per viewport, smaller type, tighter spacing. Borrowers need focus: one task at a time, generous touch targets, mobile-first. Rather than two component libraries, density lives in spacing and type token modes the same data table or form field composes into a dense desktop posture or a roomy mobile one by switching modes.
Trade-off accepted: a handful of components carry posture-specific variants where token modes weren't enough. Honest cost, paid in a few components instead of a parallel library.
A system of one, used by many
A solo designer can't review every screen. The system had to encode my judgment so it applied when I wasn't in the room.
Naming as API. Semantic token names were written for engineers, not designers action-primary-bg tells a developer what to use without asking. The token vocabulary became the shared language between design files and code: handoff stopped being "what hex is this?" and became "which token is this?", a question that answers itself.
Client onboarding as a workflow, not a project. A new client's brand becomes a new alias collection: populate the brand tokens from their guidelines, contrast-check the functional derivations, and every surface LOP, POS, comms re-renders in their identity. What used to be a manual re-skin per prospect became a repeatable, hours-not-days step in onboarding.
The sales-demo dividend. The same mechanism answered the "client's eyes" problem: prospects could be shown their LOS, in their brand, before signing turning the design system into a sales asset, not just an engineering one.
The AI stress test
The strongest validation of the token architecture came from outside Figma: I used the token system to generate production-grade HTML with Claude Code. Because the system's semantic layer describes roles rather than appearances, an AI agent could compose correct, on-brand, theme-aware UI from token names alone no screenshots, no eyeballing.
What variation costs now
The deeper outcome is organizational: brand variation stopped being design work. New clients, new themes, and new surfaces draw from the system instead of drawing on me which is the only way a one-designer team supports a multi-tenant product without becoming its bottleneck.
What I'd do next
The system's ceiling today is sync: tokens live in Figma Variables and travel to code through structure and convention. The next maturity step is a tokens-as-code pipeline (Style Dictionary or equivalent) so a client theme committed once propagates everywhere and so the AI-generation workflow runs on the same source of truth engineering ships.