Digital Contact Card Marketing Engine

The situation

A digital contact card platform has a surface area that's easy to underestimate. Below the product — the card design experience, the QR/NFC integration, the analytics, the iOS app — sits a full B2B SaaS substrate: multi-tenant data isolation so each customer's cards are private, role-based access for teams sharing an account, an auth surface that has to work reliably across web and mobile, and a notification engine for share events and card views.

Building that substrate from scratch on a startup timeline means spending the first 6–12 months on infrastructure instead of product. The team needed a foundation that was already there so they could focus engineering time on what makes the product distinctive.

The engagement

The team licensed the CleenUI codebase to skip the foundation phase entirely — the auth surface, the multi-tenant data layer, the React component library — and start building the product-distinct work on day one.

Deployed onto Azure cloud infrastructure, with every named object (resource groups, app service names, SQL servers, blob containers) configured to the team's own conventions. From license to a working platform their developers could extend without architect supervision: weeks, not quarters.

Which parts of the codebase

Not every module is equally relevant to every engagement. Here's where the CleenUI codebase did the most work for this team:

• M01
  Auth & IdentitySecure sign-in and social login via Auth0. Multi-tenant isolation enforced at the stored-procedure level — each card owner's data is completely separate.
• M02
  AccountsAccount hierarchy for card owners, teams, and admins. A single user can own multiple card profiles; team accounts share visibility.
• M04
  ObservabilityStructured logging and platform health monitoring. Necessary for any production web + iOS platform.
• M06
  NotificationsShare events, card view notifications, and in-app alerts — the engagement layer that keeps card owners informed.

The outcome

• Foundation phase skipped — team started on product-distinct work on day one.
• Azure deployment with custom naming conventions, provisioned by the architect.
• Working platform the team could extend independently: weeks, not quarters.