Writing a post-mortem for a shipping product feels premature, it's not dead, it's not even fully launched. But the build is far enough along to see the places I was confidently wrong, and the honest thing to do is put them on the record before they become part of the origin myth.
Here are four of them.
I thought the app's job was to show gift cards.
The app was going to be a wallet. You open it, you see your cards, pretty. That was the whole pitch early on. I built the wallet view, it looked great, and I showed it to five friends, and three of them asked "okay, but, why would I open this?"
I had no answer.
The real job of the app was not to show. The real job was to remember. Users already know what gift cards they have (roughly); they don't need a screen that shows them. What they need is an agent that notices, for them, at the right moment, that a card they own is relevant to where they are and what they're doing. The wallet screen is a backup. The active product is a notification engine.
I didn't get to this realization through a flash of insight. I got to it through three people asking "why would I open this?" and me not having an answer that wasn't technical. If the answer is not something a normal person would care about, the product is probably mis-aimed. Fix the aim before you build more.
I thought onboarding was about teaching.
The original onboarding flow was four screens of explanation: here's what Cue does, here's why it's private, here's how to add a card, here's how to set your home quiet zone. It was beautiful. I was proud of it. It was, in retrospect, a failure.
Users did not want to be taught. They wanted to add a card. They wanted to see the magic happen. The explanation was in the way of the magic.
Onboarding v2 is the opposite: it drops the user into the camera within about three seconds of opening the app, and lets the app show what it does by doing it. You point at a gift card, the form fills itself in, you save, and now you have an app with a card in it. The teaching happened, but it happened as a side effect of the doing.
This is a small lesson, but it cost real time building the wrong thing. I've since adopted a rule: don't explain what you can demonstrate. Onboarding that relies on text is a sign that the first interaction isn't strong enough to speak for itself. Fix the first interaction instead.
I thought notifications were about value-add.
Early on, every time I thought of a notification Cue could send, I asked: would the user find this useful? If yes, I added it. The list got long fast. Expiration reminders. Balance updates. New-card additions from another device. Price-drop notifications for merchants you've scanned. Weekly summaries.
The user of this app, I imagined, wanted information.
The user, I eventually learned, wanted quiet. Every additional notification made the app slightly less trustworthy, not more. The question I should have been asking was not is this useful, but is this worth the interruption. Almost nothing clears that bar. The things that do clear it are high-value, geographically anchored, time-sensitive. Everything else should be an icon badge or a wallet-open experience, not a push.
The redesign that came out of this was what eventually became the five-gate system and the Conductor, a single shared notification throttle through which every alert in the product has to pass. Any alert can be canceled by the Conductor without shipping. The architecture now has an institutional bias against its own notifications, and that bias is the best feature of the product.
I had to build the bad version of notification logic first to see why the quiet version was correct. I wish I'd seen it sooner.
I thought Swift would be the hardest part.
Everything I just described, and the technical parts I didn't describe, the vision pipeline, the on-device AI, the geofencing engine, the design system, the ecosystem surfaces, is the part of app development I am qualified to do. It was hard, but it was the familiar kind of hard.
The unfamiliar kind of hard was the editorial work. Writing the copy in the app so it sounded like one voice. Writing the press materials so a journalist could cover it without me on a call. Writing blog posts like this one so a reader could encounter the product without a pitch. Writing the Complete press kit, which reads as the definitive summary of what the app is, that took longer than the App Intents integration did.
The technology is easier than the communication. Every year it becomes even easier than the year before. What remains hard is saying, in a short number of words, what the product is and why anyone should care. If you are building something, budget for that work. It is a real, distinct, capital-E Engineering problem. It is not a thing you do at the end.
A year ago I thought I was building a wallet. I was, a little. But mostly I was building an apparatus to remember things on people's behalf and to stay out of their way otherwise, and learning in public, and writing a voice. The app is the surface. The rest of it is the product.
The second year will be about whether I can get out of the way enough for the product to be used. I'll tell you what I got wrong about that one next year.