Banca Assist: Designing a Configurable Platform for B2B Insurance at Scale

Banca Assist: Designing a Configurable Platform for B2B Insurance at Scale

Led the 0→1 design of a no code, modular workspace that lets product teams configure, brand, and launch partner insurance products.

Led the 0→1 design of a no code, modular workspace that lets product teams configure, brand, and launch partner insurance products.

Product Configurator & Tools

B2B Platform

Insurance / BFSI

0→1 Design

PPROJECT

Enterprise Product · B2B Configuration Platform

Enterprise Product · B2B Configuration Platform

MY ROLE

Led design end-to-end, 2 PMs, 5 Engineers

Led design end-to-end, 2 PMs, 5 Engineers

TIMELINE

November 2025 - Februray 2026

I OWNED

Discovery · Journey builder · White-labelling system

Overview

Banca Product Configurator is a no-code workflow automation tool that enables product admins to configure complex products without engineers or third-party tools. I led product design from concept to MVP launch, delivering a working prototype in just 80 days.

02 - CHALLENGES

Every new partner started from zero.

Bancassurance grew by adding partners, but each followed the same single path without branching. This meant ten partners required ten separate builds, with the tenth costing as much as the first.

~2 Months

to get a partner live

20 Days

to build a microsite

₹ 6L

average dev cost

Baselines relied on previous launches, but separate ownership of builds caused desynchronization and no unified system overview.

03 - REFRAMING CHALLENGE

Almost Built a Faster Microsite Builder…

The initial focus was on speeding up microsite creation, which took 20 days. The scoped solution could have cut this to 8 days.
However, it left the core model unchanged. Engineering would remain the bottleneck for products, journeys, payments, and integrations, optimizing just one small step in a longer process.

DESIGN CHALLENGE

How might we enable product teams to configure complex partner experiences without overwhelming them or relying on Engineering for every change?

04 - DISCOVERY

Requirements varied, but capabilities repeated.

I cataloged partner-specific needs from 19 past builds, working with 10 product and engineering stakeholders, then grouped them by system functionality instead of by requester.

I cataloged partner-specific needs from 19 past builds, working with 10 product and engineering stakeholders, then grouped them by system functionality instead of by requester.

Product

· Products

· Plans

· Payment modes

· Pricing configurations

Experience

· Journeys

· Extra fields

· Sales channels

Brand

· Documents

· Declarations

· Communication

Integration

· APIs

· Policy sharing

· SFTP

Content

· Communication

· Documents

· Declarations

· Pricing configurations

Product

· Products

· Plans

· Payment modes

· Pricing configurations

Experience

· Journeys

· Extra fields

· Sales channels

Brand

· Documents

· Declarations

· Communication

Integration

· APIs

· Policy sharing

· SFTP

Content

· Communication

· Documents

· Declarations

· Pricing configurations

Product

· Products

· Plans

· Payment modes

· Pricing configurations

Experience

· Journeys

· Extra fields

· Sales channels

Brand

· Documents

· Declarations

· Communication

Integration

· APIs

· Policy sharing

· SFTP

Content

· Communication

· Documents

· Declarations

· Pricing configurations

Key Finding: Across all 19 builds, requirements fit into five core groups. The variation was in configuration, not capability—making the decision to reframe both safe and strategic.

Key Finding: Across all 19 builds, requirements fit into five core groups. The variation was in configuration, not capability—making the decision to reframe both safe and strategic.

Product

· Products

· Plans

· Payment modes

· Pricing configurations

Experience

· Journeys

· Extra fields

· Sales channels

Brand

· Documents

· Declarations

· Communication

Integration

· APIs

· Policy sharing

· SFTP

Content

· Communication

· Documents

· Declarations

· Pricing configurations

Key Finding: Across all 19 builds, requirements fit into five core groups. The variation was in configuration, not capability—making the decision to reframe both safe and strategic.

Benchmarked against five products

Three direct competitors: TurtleMint, Riskcovry, SprintMoney and two indirect examples: Shopify and Wix.
The latter demonstrated thousands of non-technical users configuring complex storefronts without engineering support, validating the core premise.

Borrowed

Direct manipulation for customization, instant change previews, and stepped flows to ease admin cognitive load.

Direct manipulation for customization, instant change previews, and stepped flows to ease admin cognitive load.

Improved on

Pre- and post-setup states, often overlooked by competitors, with clearer action indicators.

Pre- and post-setup states, often overlooked by competitors, with clearer action indicators.

Avoided

Lengthy input forms before feedback; weak white-labeling and dashboards found in direct competitors.

Lengthy input forms before feedback; weak white-labeling and dashboards found in direct competitors.

05 - ARCHITECTURE

Configure once, reuse whenever possible, and override as needed.

The system keeps core functions intact while supporting partner-specific customizations.

This also resolved the coordination issue. A shared configuration layer made system capabilities visible to all partner launch teams, rather than siloed with individual builders.

This also resolved the coordination issue. A shared configuration layer made system capabilities visible to all partner launch teams, rather than siloed with individual builders.

06 - DEEP DIVE · JOURNEY BUILDER

Customise within boundaries.

artner journeys vary widely but must follow regulatory rules. Partners can reorder steps but can’t skip mandatory disclosures. Full freedom causes engineering issues; full rigidity limits needed flexibility. Benchmarking Shopify and Wix showed they allow total freedom, which suits non-technical users but risks missing critical disclosures.

Thus i adapted a similar interaction style but with controlled flexibility. Journeys are built from reusable steps, each configurable within strict rules to prevent errors.

artner journeys vary widely but must follow regulatory rules. Partners can reorder steps but can’t skip mandatory disclosures. Full freedom causes engineering issues; full rigidity limits needed flexibility. Benchmarking Shopify and Wix showed they allow total freedom, which suits non-technical users but risks missing critical disclosures.

Thus i adapted a similar interaction style but with controlled flexibility. Journeys are built from reusable steps, each configurable within strict rules to prevent errors.

What validation changed?

Testing wireframes with partners’ stakeholders, business teams, and engineering revealed my module scope was too narrow. The existing 19-build mapping showed what was built, not the full range of partner needs, customizations, or journey variations.

Solution: Instead of adding new modules, I broadened the scope and redesigned forms to support more input types, avoiding redirects back to engineering and better meeting platform goals.

07 - DECISIONS

Two calls worth defending.

DECISION 1

Branding is optional and minimal at onboarding

SKUs and data are needed for partner setup. Going online takes precedence over branding, which frequently occurs later. Mandatory branding would result in placeholder data or postpone launches. Unused features increase needless complexity, therefore a complicated branding tool was eliminated because partners wouldn't utilize it. To educate users, the partial configuration status is always displayed.

DECISION 2

No launch without full approval

Under compliances, a product cannot launch until all journeys and settings have been approved. This guaranties quality and safety while slowing the fastest path. In order to eliminate engineering as a bottleneck while preserving accuracy, administrators can freely configure, certain that nothing reaches customers without authorized sign-off.

DECISION 1

No launch without full approval

By compliance, no product goes live until all journeys and settings are fully approved. This slows the fastest path but ensures safety and quality. Admins can configure freely, confident nothing reaches customers without authorized sign-off, removing engineering as a bottleneck while maintaining correctness.

DECISION 2

Branding is optional and minimal at onboarding

Partner setup requires SKUs and details; branding is optional. Partners prioritize going live over branding, which often comes later. Making branding mandatory would delay launches or lead to placeholder data. A complex branding feature was removed since partners wouldn’t use it, and unused features add unnecessary complexity. Partial configuration status is always visible to keep users informed.

08 - DESIGN FOCUS

Prioritize reusing patterns, not just components.

Adding modules piecemeal fragments the interface, as each brings its own layout, form logic, and "saved" state—leading to inconsistency before even addressing code fragmentation.

Patterns that scale

Progressive Configuration

Large setups broken into focused decisions.

Reusable form patterns

Consistent handling of fields and dependencies

Configuration States

Clear visibility into incomplete and completed setups.

Review before action

Validate configurations before proceeeding

09 - DESIGN WIREFRAMES

09 - DESIGN WIREFRAMES

From scattered requirements to a structured experience.

From scattered requirements to a structured experience.

10 - WHERE IT STANDS

10 - WHERE IT STANDS

Custom builds and experiences that can be customized

Banca Assist is being developed right now. The figures below show the team's target estimations for the new configurable model, agreed upon with product and engineering, rather than actual results; partner launch timelines have averaged two months.

Banca Assist is being developed right now. The figures below show the team's target estimations for the new configurable model, agreed upon with product and engineering, rather than actual results; partner launch timelines have averaged two months.

~2 months

25 days

Partner go-live

20 days

05 Days

Microsite creation

₹6L

₹ 1L

Development cost

Every change

~90% lower

Engineering involvement

~2 months

25 days

Partner go-live

₹6L

₹ 1L

Development cost

20 days

05 Days

Microsite creation

Every change

~90% lower

Engineering involvement

What could prove this wrong?

The model matures based on five capability groups that will address partner needs. If a partner requires a feature that exceeds their current capabilities, it either necessitates a custom build (which reintroduces the original problem) or the development of a new module, which is considered expected platform behavior. The real test is which path is played out in practice, and the outcome can only be known post rollout.

The model matures based on five capability groups that will address partner needs. If a partner requires a feature that exceeds their current capabilities, it either necessitates a custom build (which reintroduces the original problem) or the development of a new module, which is considered expected platform behavior. The real test is which path is played out in practice, and the outcome can only be known post rollout.

What I Would Do Different

I mapped 19 completed builds before going back to partners to validate, but the map showed what was built, not what was requested or negotiated away. The correction needed to broaden the scope. Next time I would do the reverse: engage partners first to understand their needs before cataloging past deliveries.

I mapped 19 completed builds before going back to partners to validate, but the map showed what was built, not what was requested or negotiated away. The correction needed to broaden the scope. Next time I would do the reverse: engage partners first to understand their needs before cataloging past deliveries.

Contact

ishukardamSPACE@gmail.com

Social

Linkedin

\

BEHANCE

\

Ar.eNA

© 2025 Ishu Kardam

v01.01 Last Update → June 2026

Made in

Mumbai, INDIA

Contact

ishukardamSPACE@gmail.com

Social

Linkedin

\

BEHANCE

\

Ar.eNA

© 2025 Ishu Kardam

v01.01 Last Update → June 2026

Made in Mumbai, INDIA

Contact

ishukardamSPACE@gmail.com

Social

Linkedin

\

BEHANCE

\

Ar.eNA

© 2025 Ishu Kardam

v01.01 Last Update → June 2026

Made in

Mumbai, INDIA

npx -y @posthog/wizard@latest self-driving