In previous posts, I examined claims about “building a product in one day” and discussed my attempt to take a game from wireframe to working prototype. Here’s what happened next.
By the time the game was fully built, tested, and stable, there was one step left that felt harder than anything technical: actually launching it.
Up until that point, everything had been controlled. I had tested the mechanics at the kitchen table, validated interactions through prototypes, and worked through logic, storage, and edge cases during development. Even the beta testing phase, while incredibly useful, was still contained within a small, friendly group. Launching meant removing that safety net and putting something out into the world without knowing how people would respond.
It is easy to assume that the hardest part of building something like this is the engineering. Setting up Firebase, working through data models, debugging logic, and deploying a live site all take effort. But none of that was the most difficult part.
The hardest moment was opening Facebook and deciding to share it more broadly with friends, family, and others.
There is a psychological shift that happens when something moves from “a project I’m working on” to “a thing that exists in the world.” It feels more permanent and more exposed. There is a quiet fear that no one will care, or worse, that people will try it once and never come back. At that point, the product is no longer theoretical. It is real, and real things can be judged.
Still, I hit post.
Early Traction (Without Trying to Go Viral)
In that first week, I saw an immediate wave of support. Friends and family were curious, willing to try something new, and eager to give feedback. I was averaging around 50 daily active users, which was encouraging on its own. What mattered more was what happened after that first play.
People came back.
Some started sharing their results on their own Facebook pages. Others talked about how many attempts it took or whether the clue felt fair. Small conversations started forming around the game because people found it worth talking about.
There was no paid promotion, no growth strategy, and no SEO push. It was simply a small network of people discovering it organically and deciding it was worth sharing. That mattered far more than any vanity metric, because the goal was never to maximize clicks. The goal was to understand whether the experience held up as something people would return to daily.
What the Data Started to Show
As time went on, usage naturally settled. Without any intentional promotion, daily active users have stabilized closer to around 15 per day, which is exactly what I would expect. Early on, I posted a few updates and invited people into a dedicated Padlock Game Facebook page, but beyond that there has been no structured effort to drive growth.
There is no content engine bringing in new users, no funnel, and no distribution strategy. It is simply a product existing on its own.
Even within that smaller number, the signal is strong. People are returning. Players are tracking their performance. Some are consistently engaging day after day.
As of today, around 40 users have created accounts, even though accounts are not required to play, and the game has seen over 1,500 total plays. For something that started as a kitchen table experiment, that is meaningful traction.
Building After Launch (Not Just Before)
Launching did not mark the end of development. In many ways, it marked the beginning of a more informed phase.
Once real players were interacting with the game daily, it became much easier to identify what to improve and what to add. People started commenting, texting ideas, and even suggesting their own code combinations. That feedback loop was incredibly valuable, not just for identifying issues but for shaping what the product could become.
One of the first features I introduced was the ability for players to submit their own code ideas directly within the app. Those submissions flow into an admin dashboard where I can review and incorporate them into future puzzles, and I have already used quite a few. This introduced something I had not originally planned for, which was community contribution. Instead of the game being entirely authored by me, players now have a way to influence it.
I also expanded performance tracking. Completion rate data began to tell a story about puzzle difficulty, and adding a timer made it possible to measure how quickly players solved each puzzle. That idea came from a simple question a friend asked: “Was I the fastest to solve today’s puzzle?”
I had the data in the database, but it was not surfaced in a meaningful way. Bringing that insight into the experience, and eventually into the sharing flow, added a new layer of engagement. Players could now see not just whether they solved the puzzle, but how efficiently they did it, and that became part of what they shared.
The product deepened through small, intentional enhancements rather than large feature additions. This was never the kind of product that needed constant expansion. A handful of thoughtful improvements pushed it to a place I am genuinely proud of.
This Was Never About Going Viral
There is a version of this story where the goal is scale, where success looks like The New York Times acquiring the game for seven figures, similar to what happened with Wordle.
That was never the goal, even if it would be a nice outcome.
I did not build this expecting a breakout success or massive growth. The real goal was much simpler. I wanted to prove that I could take an idea all the way to a real, functioning, public product. Not a prototype, not a demo, and not a half-finished project, but a complete experience that I owned, deployed properly, and continue to maintain.
The Outcome
From the outside, this might look like a small web game. From the inside, it was an exercise in end-to-end product ownership.
It required identifying the right scope, validating the mechanic, designing the experience, prototyping interactions, building the system, testing with real users, launching publicly, and iterating based on feedback. Throughout the process, AI played an important role as a support system. It helped accelerate development, unblock technical challenges, and refine logic, but it did not replace decision-making or remove the need for product thinking.
I set out to see if I could build and launch something relatively quickly, and I did. More importantly, I proved something to myself. With the right scope, the right process, and the right use of tools, I can take ownership of an entire product lifecycle, even in areas that used to feel out of reach.
I do not expect The New York Times to come knocking, and that is fine. This was never about a headline outcome. It was about building something real, something stable, tested, and used by actual people. Something that goes beyond a vibe-coded, buggy demo.
If you want to try it out, you can play the game at playpadlock.com.
And if there is one thing I hope this series reinforces, it is this: AI does not replace product thinking. It amplifies it. The difference is not whether you use AI, but whether you use it to move faster or to build something worth coming back to.