Last Week
Last week I finally treated production like a real destination instead of a vague future milestone. I had already tightened the development loop by giving my workflow a way to drive the Android emulator for smoke tests, and I used that momentum to push the store-submission work forward. Google had the Android production-access request in hand, and Apple had the iOS submission materials in motion, even if I expected that side to take more iteration.
This week the Android answer came back: Google granted production access. That means Shokken is now publicly downloadable on Google Play instead of living behind testing gates. The iOS application is also submitted and pending review, but I am not assuming that will sail through untouched. In practical terms, though, the nature of the work has changed. The question is no longer just “can I finish the software?” It is now “can I get real businesses to find it, understand it, and trust it enough to try it?”
Public At Last, Invisible By Default
The headline for this week is simple: Android production access is granted, the iOS submission is pending, and the app is now close enough to “launched” that the old engineering excuses no longer apply.
That is both satisfying and uncomfortable.
It has been one year, three months, and twenty days to get to the point where the app is publicly listed instead of sitting in alpha and beta channels. That sounds like a finish line until you look at what actually happens after listing. Public availability does not create discovery. A store listing does not create trust. A stable backend does not create customers. It just means the door is unlocked.
So the real work for the next stretch is not a flashy new subsystem. It is distribution. I need better store copy, better screenshots, clearer website materials, a better explanation of how the app works for hosts and guests, and eventually a marketing rhythm that reaches people outside the tiny circle that already knows I exist. Shipping the product got Shokken onto the shelf. Now I need to give people a reason to pick it up.
What does it mean in English?
This week I hit an important milestone: the Android version of Shokken is now available to the general public on Google Play, and the iPhone version is waiting on Apple’s review.
But publishing the app did not solve the hardest problem. It only revealed it.
If someone cannot discover the app in search, understand what it does within a few seconds, or trust that it is maintained by a real person who will keep supporting it, then the technical work underneath barely matters. That is why the next phase is about screenshots, copywriting, website demos, explainer videos, and outreach instead of another round of deep backend work.
There is also a business-model reality to explain more clearly. The QR waitlist flow is free to use, but SMS notifications are paid because every text message costs real money to send. Now that the app is public, I have to make those boundaries understandable, fair, and easy to evaluate.
Nerdy Details
Production access changed the constraint, not the workload
The most important technical detail this week is not a new feature. It is that the release state changed.
On Android, Google granted production access, which means I am no longer treating the app like a controlled beta artifact. It is a public listing backed by the current stable frontend and the production backend. That matters because the risk profile changes the moment strangers can install the thing without me pre-screening them first.
Inside testing channels, a lot of rough edges can be absorbed socially. Testers are more forgiving. They expect change. They know they are early. Once the listing is public, expectations harden. The app store page becomes part of the product. Pricing becomes part of the product. Support responsiveness becomes part of the product. Even the wording on screenshots becomes part of the product, because that wording may be the first and only chance I get to explain why Shokken exists.
That is why I do not think of this week as “launch complete.” I think of it as “the environment got stricter.” The software still has to work, obviously, but now it also has to be legible to people who were not in the room while it was being built.
The iOS side reinforces that point. Apple review is still pending, and I would be surprised if the first pass required no follow-up. Apple tends to demand more presentation polish and more explicit framing than Google does. That is annoying in the short term, but it is also a useful forcing function. If I cannot explain the product cleanly to a reviewer, I am probably not explaining it cleanly enough to a customer either.
Discovery is now a systems problem
Before this week, “distribution” still felt abstract. Now it is concrete.
If someone searches for Shokken by name, they can find it. That is not the real test. The real test is whether someone searching for the problem can find the solution. Right now, if you search broadly for the kind of tool this is supposed to be, the app does not naturally surface. The website domain is still cold. The store listing is still young. Competitors own the generic search terms. Search engines and app stores have no reason yet to treat a new product as a trustworthy answer.
That means discovery is not a branding afterthought. It is a ranking problem, a language problem, and a patience problem.
I need better titles, better descriptions, better keyword coverage, and better alignment between the phrases a potential operator would search for and the phrases I use to describe the product. I also need to accept that indexing systems move slowly. A new domain and a new listing do not accumulate trust instantly. They earn it through consistency, relevance, and time.
As an engineer, this is slightly offensive because it means the elegant part of the system is not enough. You can build the cleanest architecture in the world and still lose the discovery battle if the product page reads like a placeholder and the search terms do not map to what real users type.
So I am treating discovery as another layer of system design. The inputs are copy, screenshots, metadata, demo assets, and channels. The outputs are visits, installs, and conversations. It is less fun than writing Kotlin, but it is no less real.
Conversion starts before the first install
One thing this transcript made obvious is that I need to stop thinking of app-store screenshots as documentation. They are sales material.
Right now, the raw screenshots prove that the app has screens. That is not enough. Good listings do more than expose UI surfaces. They frame those surfaces. They put the screen in a device mockup, pair it with a tight message, and tell the user why the feature matters before the user has time to bounce. That is the bar I need to hit.
The same logic applies to the website. The site already contains a useful live demo: there is a QR code that points at the production backend so a visitor can experience the guest-side flow immediately. That is good because it moves the product from abstract promise to concrete interaction. A business owner can scan it and see what a guest would actually encounter.
But the website still lacks the matching host-side explanation. A guest-facing QR code demonstrates one half of the loop. It does not yet show how the operator creates and manages the waitlist, how the handoff feels, or how the product fits into an actual front-desk workflow. The next obvious asset is a short host-side walkthrough video on the website. That would let me show the operational value directly instead of hoping the screenshots do all the work.
This is what I mean when I say the work has shifted. The product is no longer only the codebase. The product now includes every explanatory surface that turns “interesting software” into “something I can picture using at my business.”
Pricing has to match infrastructure reality
Going public also makes the pricing boundaries more important.
One of the easiest mistakes in a product like this is to pretend every feature can be free forever because free reduces friction in the short term. That only works until the infrastructure bill arrives. In Shokken’s case, the clean dividing line is straightforward: the QR waitlist flow can stay free, but SMS notifications cannot, because text delivery has a direct cost every time it is used.
That cost is not theoretical. It exists in the backend every time a message is sent. So the paid boundary is not arbitrary packaging. It is a reflection of variable cost. If I ignore that and make SMS free indefinitely, I am not being generous. I am just shortening the lifespan of the product.
What does matter is making evaluation easy. If a serious prospective user wants to test the full experience, I do not want the first interaction to be “buy now and maybe ask for a refund later.” That creates support overhead, store friction, and bad signals in the wrong places. A much cleaner approach is to grant temporary access directly on the backend when someone reaches out. That keeps the evaluation path simple while preserving the logic of the public pricing model.
I expect this area to keep evolving, but the principle is stable: free where the marginal cost is effectively zero, paid where ongoing usage incurs a real operating expense, and human support where a qualified evaluator needs a smoother path than the default storefront provides.
Trust has to be designed too
The other uncomfortable realization this week is that a stranger does not automatically know whether this app is real in the sense that matters.
They do not know whether it is actively maintained. They do not know whether the person behind it understands the businesses it targets. They do not know whether support exists, whether bugs will get fixed, or whether the product will still be here in six months. Those questions are obvious to me because I have lived inside the build process for over a year. They are not obvious from the outside.
That means developer visibility is now part of the launch strategy. The blog helps. The website helps. Direct email access helps. A social presence, however reluctant, probably helps too. Some businesses will want proof that the software comes from a real builder with ongoing accountability rather than from a disposable, anonymous listing. That is a trust problem, and trust problems do not solve themselves.
In practice, that likely means experimenting with channels I do not naturally enjoy. I will probably need some mix of website improvements, short-form social posts, and more explicitly professional presence where a buyer can sanity-check who is behind the product. None of that replaces the product. It makes the product believable.
The next phase is distribution engineering
The phrase “marketing” still feels vague to me unless I break it into deliverables, so that is how I am framing the next couple of weeks.
I need revised website assets. I need store screenshots that communicate value instead of merely exposing screens. I need a host-side explainer video. I need to tighten the listing copy. I need a clearer path for evaluators to reach out for access to the paid messaging features. I may also experiment with physical one-pagers and coupon codes for direct local outreach, because sometimes the shortest path to a first user is not a perfect funnel. It is showing up with something concrete in hand.
That framing helps because it keeps the work honest. “Do marketing” is vague enough to avoid. “Produce a host demo video, redesign the store screenshots, tighten the website copy, and test a one-page leave-behind” is actionable.
So yes, this week was a milestone. But the more useful interpretation is that the project crossed a boundary. For the first year, the dominant question was whether I could build the product at all. Starting now, the dominant question is whether I can build demand around it with the same seriousness.
Next Week
Next week, assuming Apple does not interrupt me with review feedback first, is about turning distribution into concrete assets. I want a better host-side walkthrough on the website, stronger app-store screenshots, sharper copy on the listing surfaces, and a cleaner explanation of how free QR usage and paid SMS fit together.
If I can get those pieces into place, then the next experiments become much more grounded: social outreach, direct business conversations, and possibly a physical one-pager with a coupon code for local discovery. The engineering phase is not over, but it is no longer the bottleneck. Clarity and distribution are.