← All work

New SaaS product for a U.S. dealership group

A password manager designed so the service itself never sees users' passwords

A U.S. dealership group wanted its own password manager for individuals and teams. Before feature code, we proved how keys are created, stored and shared, then built signup that generates each user's key pair in the browser.

B2B SoftwareMulti-tenant password managerBuilt from zero

Business admins see active, suspended and recovering people, pending invitations and weak passwords in shared vaults.

The challenge

Every later feature of a password manager, from sharing to recovery, depends on where keys live, and each business's data had to stay apart on shared infrastructure.

What we did

We wrote requirements, a permission matrix and an audit catalogue, ran encryption proofs of concept, then built auth and onboarding with keys made in the browser.

The outcome

The client approved the full product design stage by stage and received working signup, login, invitations and people management before the work stopped.

What shipped
Approved product design, requirements, auth foundations
Built in code
Signup, OTP verification, login, invitations, people APIs
Designed for
Individuals, business admins, business users, super admin
Status
Stopped after the first feature sprint

The starting point

The client, a U.S. dealership group, wanted to sell its own SaaS password manager to individuals and to businesses that control which team members reach which credentials. The MVP was a web app and a Chrome extension, to test demand.

What had to change

A password manager is only as good as its key management. Before any feature code, we had to decide how vaults are encrypted, shared with a group and recovered, and where private keys live.

What could not break

  • Passwords protected even from the service itself
  • Each business's data isolated on shared infrastructure
  • MVP limited to a web app and a Chrome extension
  • Original designs, not copies of the products used as a reference

The calls we made

We treated key custody as the first design decision, because sharing, recovery and every later feature depend on where keys live.

  1. 01

    Prove the encryption before the sprints

    Our tech lead ran proofs of concept on AWS KMS data keys, the AWS Encryption SDK, hybrid encryption, Secure Remote Password login, elliptic curve key exchange, PKI based end to end encryption and keys kept outside the database.

  2. 02

    Decide where private keys live

    The engineering manager, tech lead and backend engineer met on where users' private keys are stored before the auth sprint, and signup was then built to create each key pair in the browser with a secret key the user downloads.

  3. 03

    Permissions and audit written down first

    A permission matrix and an activity log catalogue, with a message for every group action, were written before development, so roles and audit were part of the data model from the start.

  4. 04

    Original screens from studied flows

    We analyzed how two leading password managers handle sign in, recovery and vault sharing, then revised our wireframes so the product stayed original and consistent.

What we built

Product design, signed off in stages

Brand, marketing site, Super Admin, Business admin, Business user and Personal account portals, each approved by the client before the next.

The Super Admin portal tracks personal and business accounts and their billing status.

Registration with browser side keys

Signup for individuals and organizations with OTP email verification, a key pair generated in the browser and a downloadable secret key.

The registration flow document from the design stage: signup, email activation, master password setup and optional two factor setup.

Login and new device checks

Login for users and organizations, with new device verification and one time codes designed into the flow.

Login flow with a credential check, new device verification and one time codes.
04

Organization people management

Invitations with permissions, an ownership guard on organization actions, and APIs to list, delete, suspend and reactivate people, one by one or in bulk.

How it works

Sign up

A person or organization registers and verifies the email with a one time code.

Create keys

The browser generates the user's key pair and offers a secret key to download.

Invite

A business admin invites team members with set permissions.

Manage

Admins suspend, reactivate or remove people, individually or in bulk.

What changed

The client received an approved product design, full requirements, tested encryption options and working authentication and onboarding foundations. Work stopped after the first feature sprint, before vaults, sharing, billing and the extension were built.

Under the hood

Datics role
Product built by Datics
Encryption
Key pairs generated in the browser at signup, with AWS KMS data keys, hybrid encryption and PKI based end to end encryption tested in proofs of concept.
Tenancy and permissions
Data isolated per tenant on shared infrastructure, a permission matrix for every role, and an ownership guard on organization actions.
Audit
An activity log catalogue with a message for every group action, from adding members to granting vault access.
Stack
React, Vite and Material UI on the front end, NestJS on Node.js for the APIs.

Cloud and infrastructure

AWS KMSAWS Encryption SDK

Apps and APIs

ReactNode.js

Also in the stack

ViteMaterial UINestJSFigma

How it shipped

  1. Discovery and requirements

    Analysis of two leading password managers, then a BRD, SRS, permission matrix, activity log catalogue and user stories.

  2. Design in stages

    Brand and marketing site, then the Super Admin, Business admin and Personal account portals, each signed off before the next.

  3. Security proofs of concept

    Key management, key exchange and end to end encryption options tested before feature work.

  4. Foundations and first feature sprint

    React and NestJS boilerplates, the database schema, then signup, login, invitations and people APIs.

Sign off at every design stage

The client approved the website, each portal and the personal app in turn, and the development plan was agreed on a call after the last design.

Two week sprints with reviews

Development ran in two week sprints with sprint scrums, lint and pre commit hooks, and code review on every pull request.

What this unlocked

The same order of work, key custody, tenant isolation and audit before features, is what we apply when AI has to read sensitive data inside a product.

Have a product with the same kind of constraints?

Tell us what already exists and what you want it to do. We will tell you what it takes.

Book a 30-minute Product Review