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
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.
- 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.
- 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.
- 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.
- 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.
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.
Login and new device checks
Login for users and organizations, with new device verification and one time codes designed into the flow.
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
Apps and APIs
Also in the stack
How it shipped
Discovery and requirements
Analysis of two leading password managers, then a BRD, SRS, permission matrix, activity log catalogue and user stories.
Design in stages
Brand and marketing site, then the Super Admin, Business admin and Personal account portals, each signed off before the next.
Security proofs of concept
Key management, key exchange and end to end encryption options tested before feature work.
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.
Related work
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.
