Last Week
Last week was almost entirely a loss to COVID.
I had a high fever, recovered from that part quickly after seeing a doctor, and then spent the rest of the week without much energy or motivation to work. The only meaningful progress was a small update to Shokken’s public-facing sites: the product site and the guest status site where guests join a waitlist and review menus. Both updates made it to integration, but I deliberately left them out of production because they still needed testing.
That pause came immediately after the first door-to-door outreach run. I had started learning which restaurants were worth talking to, which already had entrenched waitlist systems, and why guest-facing language support mattered. This week I was well enough to get back to the field—and to learn that the real task ahead is bigger than another feature.
Building Is 10%. Marketing Is 90%.
Shokken is ready to use in the United States on both Android and iOS.
That is a real milestone, but it does not create customers. App stores publish hundreds or thousands of apps every day. Being listed does not make a restaurant discover Shokken, understand what it does, decide that it solves a problem they care about, trust it during service, or commit to changing how their front-of-house works.
That chain is the job now.
The goal is not more testers. It is the first real restaurant using Shokken in production because it has a busy wait and needs a better way to manage it. Getting there involves awareness, qualification, trust, onboarding, and continued support. That is a much less familiar problem to me than building the app, and it is why I now think of the work as 10% building and 90% marketing.
I have done the basic launch-surface work. The app store screenshots and descriptions have been improved. Shokken has basic branded pages on the major social platforms. There is a YouTube channel with a product video, and I put more effort into LinkedIn because early outreach is intentionally high-touch. If a restaurant operator looks me up after a conversation, I want them to find a real person and a product that looks maintained—not an empty profile or a dead end.
Those assets are useful, but they are not the acquisition engine. The field conversations are.
What does it mean in English?
The app works. The hard part is finding a restaurant that both needs it and is ready to try it.
That is more specific than finding a busy restaurant. Some busy restaurants already have a system. Some restaurants have long waits only during part of the year. Some have a waitlist problem but do not see it as important enough to introduce a new tool to their staff.
So the first sales work is also research. Every restaurant conversation reveals whether the wait is real, who feels the pain, how the restaurant handles it today, and whether changing that process is realistic. The ten visits did not produce a customer, but they made the target customer much clearer.
Meanwhile, the app still needs normal product care. A change that broke account deletion is safely contained in integration, an Android compatibility deadline needs attention, and the first-run experience needs to be easier for someone who discovers Shokken without me standing beside them.
Nerdy Details
Ten conversations produced three restaurant categories
I have now visited ten targeted restaurants. These were not random walk-ins. I started with Google Maps reviews, looking for restaurants where customers repeatedly mentioned long waits, then visited to understand the actual operating situation.
That research surfaced three distinct categories.
The first is the successful restaurant with a real wait and an existing system. I spoke with three restaurants in this group: one uses Yelp, one uses a custom waitlist product, and one uses a direct competitor. None of them was completely happy with what they had. They listened to the demo, looked at the flyers, and understood the offer.
But interest is not adoption.
Their existing workflow works well enough. Replacing it means asking staff to learn something new, asking managers to trust an unfamiliar vendor, and risking disruption at the front of house. Even a better product offered with free service and free texting is not automatically worth that change to an operator who already has something that is familiar and functional.
The second category is a restaurant that does not currently have enough waitlist pain. This exposed a limitation in my early research. A review can say that a restaurant had a long wait, but it cannot tell me whether that wait was seasonal, whether it still happens, or whether the business is currently under enough pressure to make a new system worthwhile.
Several operators explained that summer is slow. One described revenue being down and waits no longer being what they used to be. That makes a waitlist tool hard to prioritize. Running a restaurant already means handling staff, inventory, rent, accounting, and everything else outside the customer-facing experience. A system that does not solve an urgent problem is just another thing for the front-of-house team to learn.
For some of these restaurants, the right answer is timing rather than force. Business tends to pick up toward the end of the year, especially around October and November as holiday spending and travel increase. A few conversations may be worth restarting then, when the waitlist problem is more likely to be visible again.
The third category is more subtle: restaurants that are busy enough for guests to complain about waiting but do not recognize the wait as a problem they need to solve. Guests may mention a long wait in a review without lowering their rating if the food and service were good. The operator sees a successful restaurant, not necessarily a broken experience.
That makes the pitch difficult. I may be correct that better guest communication or a more organized queue would help, but I cannot walk in and lecture an owner about a problem they do not believe they have. Add the fact that only a small fraction of restaurant operators are actively looking for new technology, and the market narrows very quickly.
The status quo is a real competitor
The biggest lesson is that the alternative is often not Yelp, a direct competitor, or a custom tool. It is doing nothing different.
That is true even when the current process is frustrating. A familiar process has hidden advantages: staff already know it, managers already understand its failures, and nobody has to spend attention learning a new workflow during a busy shift. The switching cost is not only the software price. It is operational trust.
This is why the early offer is deliberately white-glove. I can provide the full package free, including texting, and I can be personally available while a restaurant evaluates the product. The point is not to make Shokken permanently free. The point is to remove as much risk as possible from the first real deployment and learn what happens when the product meets a live service.
Even that may not be enough for the wrong target. The better prospect is probably a restaurant at a moment when changing systems already makes sense: a new location, a relocation, a management or ownership transition, or another operational reset. In those moments, the cost of evaluating a different tool is lower because the restaurant is already reconsidering how it works.
Google Maps reviews are not enough to find that signal. I am looking into public information that could help identify those transitions and make the next outreach list more intentional. It is still a discovery problem, but it is a better hypothesis than treating every long-wait review as a qualified lead.
Relationships may be a better lead source than a flyer
Another possible approach is to spend less time pitching cold and more time learning from people in the industry.
The formal version is a restaurant association. The Nevada Restaurant Association could put me in front of operators as a vendor, but the economics are not attractive yet. A seat is around $650, and a booth can run into the thousands. At this stage, that money may be more useful for other forms of customer discovery.
The more personal version is simpler: buy a meal at a local restaurant, invite a front-of-house employee or manager to join, and have a genuine conversation about the operational problems they deal with. The goal is not to force a sale over dinner. It is to understand the work well enough to know whether there is a real fit and to build relationships in the local restaurant community.
I have not committed to either approach yet. The important change is that I am reconsidering the message and the target profile while keeping the local, personalized strategy. Competing nationally through generic social posts or app-store optimization alone is not a meaningful advantage for Shokken. Talking to local operators directly still is.
Integration contained an account-deletion regression
Marketing does not mean the product stops changing.
One recent feature update introduced a regression in account deletion. The problem exists in integration, and I have not fixed it yet. That is frustrating, but it is also exactly why the project has separate integration, staging, and production environments.
The broken account-deletion flow has not reached production. A restaurant that downloads and uses Shokken today is not exposed to it. I can isolate the failure, fix it, and validate the change before the next release moves forward.
This is the practical value of environments. Integration is where new work can break without becoming a customer incident. Staging provides another release check. Production remains the version that real users depend on. That separation does not eliminate bugs, but it prevents every unfinished or faulty change from becoming an emergency.
Android 16 is a release requirement, not a feature
Google now requires Shokken to target API level 36, which corresponds to Android 16. That means updating the Android configuration and publishing updated builds to every relevant Play track. If I do not, Google will delist the app.
This is one of the less glamorous parts of maintaining a public mobile app. Nothing about this change is a new customer-facing feature. It is compatibility and distribution maintenance. But if the app disappears from Google Play, none of the feature work or marketing work matters.
It belongs in the same release cycle as product fixes because it affects whether new Android users can continue to find and install Shokken.
The first-run experience needs a guide
I am also implementing an onboarding checklist.
So far, much of the expected early usage has assumed a conversation with me: I explain the product, help a restaurant get started, and stay close enough to answer questions. That is appropriate for a high-touch first customer, but the app also needs to work for someone who discovers it organically through an app store search or a referral.
An onboarding checklist gives that person a path through the first important steps instead of dropping them into an unfamiliar operator workflow. It should make the initial launch feel deliberate, explain the product through use, and reduce the chance that a curious download becomes an abandoned account because the next action was unclear.
The next store release needs its release plumbing repaired
There have not been new builds pushed to the app stores for roughly two weeks. The account-deletion regression is one reason: it needs to be fixed before I promote the current integration work.
The other blocker is iOS signing. The signing key used by the current CI/CD setup expired after its annual issuance period. I need to replace it before the pipeline can produce and distribute the next iOS build.
I set that up manually the first time. I am now moving the pipeline to Apple’s cloud-managed signing so the next yearly renewal does not require the same manual key replacement. It is a small piece of release infrastructure, but it directly affects how quickly I can ship a critical fix once the app is in customers’ hands.
Next Week
The immediate product priorities are clear: fix the account-deletion regression in integration, meet the Android 16/API 36 requirement, finish the onboarding checklist, and restore iOS release signing so the next build can move through the stores.
On the marketing side, I will keep the local, high-touch approach but refine the target list and message. I need to look for restaurants at moments of change, learn more from operators before assuming a fit, and follow up with seasonal prospects when their wait problem is likely to return. Ten visits did not create the first customer, but they turned vague outreach into a more specific problem to solve.