Update, September 4, 2026: this post described the former 500-seat plan. Early Access is now open with no seat limit and no promised sign-up credit. A validated invite code keeps the terms it displays.
The first in-person test session, I knew I had a problem. Not a bug. Not a crash. A real person sitting across from me, staring at the screen like I’d handed them the assembly manual for a rocket. And me, sitting there, physically restraining myself from saying “no no, it’s right there, the button’s right there.”
I ran ten sessions like that over three months. About thirty users in closed beta total. Regular people, not technology experts. Very different profiles, very different needs. What I learned watching them: my product was built for me. Not for them.
The interface I thought was obvious wasn’t obvious at all
The identity creation flow, I was proud of it. Logical, clean, three steps. In my head.
In reality, eight out of ten people hesitated at the same spot: the moment they had to pick a phone number. Not because the choice was complicated, but because the interface didn’t give them enough context. Why does this number exist? What does it actually mean to have a separate one per identity? For me, the answers were obvious. For them, not even close.
When you spend a year building something, you forget what it’s like to discover it for the first time. For me, the role of the phone number was obvious. But I’d forgotten to explain it in the interface. The how it works page existed on the site, but inside the web application itself, that context was almost completely absent. People were arriving in the product with no sense of where to go.
I rewrote the descriptions, button labels, and help text at every step. I added an interactive tour guide that walks you through the application step by step when you first arrive. I reduced the number of decisions someone had to make before seeing their first real result. Every change, I retested. Not perfect yet, but the difference is real.
The encrypted password manager had the same problem. Navigation between identities and passwords was confusing for new users. People were looking for their passwords in the wrong section, then giving up without saying a word. Several iterations later, it flows better. This kind of work is never really finished. You improve, retest, start again.
The moment I changed my mind on a mobile application
I’ll be honest: I was convinced a web application you can install on your phone was enough. It works offline, sends real-time notifications. No native application needed, I told myself. Faster to build, cheaper to maintain, no dependency on Apple’s App Store or Google’s Play Store.
I was wrong. Not about the technology. About how people actually use things.
Ten people in one session. Nine on iPhones. Of those nine, seven automatically went looking for the application in their library. Two of them knew the web application could be installed on their phone. I knew this kind of installation isn’t well supported on all devices, but I thought it was a good compromise before shipping a mobile application. When I explained how to install it manually from Safari, I lost three of them halfway through, that blank look in their eyes.
Same thing happened session after session. Again. And again.
At some point, you’ve got two choices: defend your decision or adjust it. I adjusted. The web application is still our main product, but the iOS and Android mobile application is now officially on our roadmap to complement it. It was always going to happen. It was the timing I hadn’t decided. The data showed me I needed to accelerate, and that’s what I did.
I still think installable web applications have their place. But for WIGGWIGG, with users who expect to find an icon in the App Store because that’s how they understand “an application,” the technical argument doesn’t hold up against the human one. And that’s fine. The goal is for people to actually use the product, not for me to be right about architecture choices.
Two features I hadn’t planned
First, the password manager importer. Several participants already had their passwords in LastPass, Bitwarden, or 1Password. They didn’t want to start from scratch, which is completely fair. So I built an importer: you export your CSV from your old manager, import it into WIGGWIGG, your passwords land directly in your vault. Nothing passes through my servers in plaintext. Your data is encrypted on your device before it goes anywhere. I don’t see it because I literally can’t.
Then, password health monitoring. Reused passwords across multiple accounts. Passwords that are too short or too predictable. Accounts potentially compromised according to public known-breach databases.
All of these checks run on your device. Your actual passwords never leave it. This wasn’t in the original launch plan. It came from beta users, framed differently by different people, but always circling back to the same core need.
The timeline: why it’s taking longer
I’ve always said spring 2026 for early access. That’s still the plan. Regulatory work with the CRTC and lawyers took longer than expected, so it’s later in the spring than I’d hoped.
That time wasn’t wasted. I ran beta. I tested. I fixed problems that would’ve surfaced post-launch, when the bad reviews would already be up and the first impression already baked into Google’s algorithm.
Launching with a product you think is good is one thing. Launching with a product that real people found confusing, and that you fixed because of it, is something else entirely.
A few months of productive humility.
What early access looks like now
The 500 early access seats aren’t a marketing number. It’s how many people I can onboard well, with real human support, during the initial phase. I’d rather bring 500 people in properly than 5,000 people badly.
What you’ll find now is a product that’s been questioned by real people, not just validated by the founder in his own head. The interface is clearer than it was in January. The password importer is there. Password health monitoring is there. The mobile application is coming. And I should be able to announce an official early access date in the coming weeks.
I’m a data engineer by training. Not an interface designer by trade. Somewhere, I knew I’d have blind spots. The beta showed me exactly where they were.
That’s what makes the product better. Not me guessing what people want, but people showing me what they’re actually going through.
CAB is the founder of WIGGWIGG, a privacy-first digital identity platform built in Quebec, Canada.