Happening v1 shipped last month. This post is the retrospective I wish more product teams would publish: the bits that worked, the bits that didn't, and the things I would do differently if I were starting again tomorrow. None of this is groundbreaking. It is just honest.
1. Saying no was the most important skill
I have a list of features that beta testers requested during the build. It is forty-seven items long. We shipped two of them. The other forty-five we either rejected outright or pushed to "maybe later".
This was the right call. I am sure of that now, and I was not sure at the time. Every individual rejection felt like I was being unreasonable. The cumulative effect was that Happening v1 has one job and does it well, instead of having forty-seven jobs and doing all of them badly. The best feedback we have had since launch is from people saying "it's just the thing I needed and nothing else". That is only possible if you say no.
The lesson: if you cannot articulate a one-sentence reason why a feature has to be in v1, it does not go in v1.
2. Building for the host vs building for the guest
Halfway through development I realised Happening had two very different users with very different needs, and I had been designing for only one of them.
The host is the person creating the event. They are highly motivated. They will tolerate friction. They will read the help text. They will install the app and create an account because they see the value clearly.
The guest is the person being invited. They have almost zero motivation. They are doing a favour for the host. They will tolerate roughly thirty seconds of friction before bailing. They will not install an app. They will not create an account. They will not read the help text.
Once I saw it that way, the design unstuck. Hosts get a real app with the features they need. Guests get a no-account, no-install, single-page web flow that looks nice and takes ten seconds to use. Neither is the "real" user; both are essential.
The lesson: identify your zero-friction users and design for them ruthlessly, even at the cost of the experience for your high-motivation users.
3. The boring parts took longer than the interesting parts
The scheduling algorithm, the bit I assumed would be the hard part, took a few days. The interesting design questions about how to score availability, what to do about non-responders, how to break ties. Fun work.
What took weeks was: account recovery flows, email deliverability, refresh token rotation, time zones, the difference between "the user's local Saturday" and "the server's UTC Saturday", how to render a calendar grid that works on a 320px screen, how to make the invite link survive being copy-pasted across four messaging apps without losing the trailing slash. None of it is interesting. All of it is the difference between a working product and a science fair project.
The lesson: budget twice as long as you think for the unsexy infrastructure work. It is the work that determines whether your product is usable.
4. Real users find the things you didn't think to test
Within the first week of beta we had three reports of bugs I would have sworn were impossible. One was a time zone edge case that only manifests if your phone's time zone changes mid-event (e.g. because you flew somewhere). One was a state machine glitch that triggered if you marked the same date as available, then unavailable, then available again, all in under five seconds. Something I had personally never thought to do. One was a copy-paste of an invite link from a messaging app that had inserted an invisible character into the URL.
All three were real bugs. None of them would have surfaced in any test suite I could have written, because I would not have written tests for things I did not believe could happen.
The lesson: there is no substitute for putting your software in front of people who do not know it the way you do. Beta testing is not a phase; it's an ongoing source of truth about what your software actually does.
5. The launch is the start of the work, not the end
For about two weeks before launch, "launch day" felt like the finish line. Once it was live, the project would be done, and I could take a breath, and the next thing on the list could begin.
That was not what happened. Launch day was the day the real list of work started. Bug reports, feature requests, infrastructure tweaks because the load profile in production was different from staging, support emails from people whose use case I had not anticipated, decisions about what to build next informed by data we did not have until people were using the product. The week after launch was busier than the month before launch.
The lesson: do not plan launch as a deadline. Plan it as the kickoff of phase two. Whatever buffer you think you need on the other side of launch, double it.
What's next
Happening v1 is the start of the story, not the end of it. The next few months are about listening. To the bug reports, to the feature requests we end up saying yes to, to the patterns of how people actually use the app. We are not in a hurry to add things. We are in a hurry to make sure the things that are already there work brilliantly.
Thank you for shipping v1 with us. Whether you used the beta, sent us feedback, or just told a friend, you are part of why this product exists. The next post in this series will be about something concrete we built in response to v1 feedback. I don't know yet what it will be, because we are still listening.