Week 80 | Door-To-Door Marketing Has Commenced

Last Week

Last week was about configuration management.

Shokken is now public on both Android and iOS, which means every release has to account for the awkward split between mobile app binaries and backend deployments. Backend changes can go live quickly. App changes have to pass through Google Play or the App Store, and users do not necessarily update immediately.

That created a practical problem for new feature work. If the app contains frontend code for a feature before the backend is ready, I need a way to keep that feature hidden without blocking unrelated bug fixes. So I added a simple configuration and feature flag system backed by Supabase and Postgres. The first use case was the QR-code menu work: the app can contain the new flow, but the server decides whether the feature is visible in production.

This week moved from release safety into the uncomfortable part I have been preparing for: actually going out and talking to restaurants.

The First Real Outreach Run

Door-to-door marketing has commenced.

That is the main milestone this week. Not app store approval, not another backend migration, not another UI polish pass. I physically went to restaurants, clipboard and printed materials in hand, and tried to explain Shokken to real people who were in the middle of running real businesses.

Shokken is available in the United States on both Android and iOS. The product is no longer hypothetical. Restaurants can download it, try it, set up a waitlist, and start using it. The question now is whether I can find the right early users and make the product useful enough for them to care.

I started with Google Maps and looked for restaurants where the wait problem is visible from reviews. Complaints about long waits are useful signals. They do not prove that a restaurant needs Shokken, but they suggest that the problem exists and that guests notice it.

I identified seven or eight restaurants, mostly around Chinatown in Las Vegas. That area is useful because it has many successful, busy restaurants that are not necessarily huge strip operations with entrenched enterprise vendors. A restaurant on the strip may have a corporate decision process, existing software contracts, and a level of operational complexity I cannot realistically unseat as a first customer. Smaller successful restaurants are different. They can have serious waitlist pain without having the internal technology organization of a large hospitality group.

I managed to visit six locations. Some of the others were not actually open even though Google Maps said they were, which is its own kind of signal about online presence and operational details.

The results were mixed, but useful.

One restaurant rejected the conversation quickly. There was a language barrier, and I do not think I successfully explained why I was there before they categorized me as another unwanted salesperson. That happens. It is their space, and if they want me to leave, I leave.

At several other locations, I spoke with front-of-house staff but not managers. That was another useful discovery: the manager timing I expected was wrong. I assumed managers might be easiest to reach during quieter afternoon administrative windows. In practice, some managers seem to arrive closer to the rush, which means getting their attention also means competing with the exact operational pressure Shokken is supposed to help with.

The most valuable part of the day came from the manager conversations I did get.

What does it mean in English?

I finally started trying to sell the app in person.

That does not mean I came home with customers. It means I learned things I could not learn by sitting at my desk. One restaurant liked the app but needed guest-facing language support. Another busy restaurant already had a system and a way of operating that would be hard to replace. Another location was using Yelp Waitlist and seemed comfortable enough with it.

The important lesson is that “busy restaurant with a wait” is not enough of a target profile. The better target is a busy restaurant with visible waitlist pain and no deeply established system already solving it.

That is a narrower target, and it is harder to identify from Google Maps alone. But it is much more useful than guessing.

Nerdy Details

Google Maps is a lead source, not a truth source

The first outreach list came from Google Maps.

The filter was simple: find restaurants with strong demand and review complaints about waiting. If people are writing “great food, long wait,” then there is at least a guest-side pain point. If the restaurant is popular enough to have a recurring wait, then waitlist software might be relevant.

That is a decent starting point, but it is not enough.

Google Maps can tell me that people complain about waiting. It can show hours, photos, review language, and sometimes enough hints to understand the restaurant’s popularity. It cannot reliably tell me whether the restaurant already has a waitlist vendor, whether the manager is open to changing systems, whether the pain is seasonal, or whether the operational process is flexible enough for Shokken to fit.

Even basic information can be wrong. A couple of restaurants that appeared open on Google Maps were closed when I arrived. That does not make them bad targets, but it reinforces that online signals are incomplete.

The real qualification step happens at the door.

That is inefficient, but it is also the point of this phase. I do not yet have enough data to automate the targeting. I need to learn what signals matter, which ones are misleading, and which restaurants are approachable.

The first rejection was useful

One restaurant rejected the pitch almost immediately.

That was not pleasant, but it was not surprising. Door-to-door outreach starts with negative context. The person at the front does not know me. They did not ask for the conversation. They may be busy. They may have been pitched by vendors constantly. They may assume I am selling something unrelated before I get through the first sentence.

In this case, there was also a language barrier. I do not think I communicated the purpose of the visit clearly enough before the interaction closed down. They seemed to read me as a generic salesperson, and the conversation ended.

That is useful feedback.

It means the opening line has to be short, specific, and immediately relevant. “I built a waitlist app for restaurants” is better than a vague product introduction. “I noticed guests mention long waits here and wanted to show you a simple waitlist tool” is probably better still, because it connects the visit to a concrete problem.

The first few seconds matter more than I wanted them to.

Managers are the real path, but not easy to reach

At three locations, the conversation stopped at front-of-house staff.

That is not a criticism of the staff. They were doing their job. A waitlist tool affects operations, guest communication, and possibly cost, so it makes sense that staff would defer to a manager or owner.

The challenge is timing.

I expected mid-afternoon on a weekday to be a good time to find managers. It seemed logical: not lunch, not dinner, not the weekend rush. But the reality was more complicated. Some managers were not there yet. Some arrived later, closer to service. That means the person I need to reach may be present exactly when the restaurant is preparing for or handling the rush.

That changes the outreach strategy.

I may need to treat the first visit as a drop-off and qualification step, then return when the manager is actually there. I may need to ask staff for the right time to come back rather than trying to force the pitch immediately. I may also need a version of the flyer that is strong enough to survive being handed upward without me in the room.

This is one reason the printed materials matter. They are not just decoration. They are the thing that keeps working after a short conversation ends.

The first real product gap was language

The most useful conversation came from a manager who was interested in the app.

She liked the product. She thought the interface looked polished. She understood the waitlist idea. But she pointed out a guest-facing problem I had not prioritized enough: language.

Shokken’s sign tells guests to scan a QR code to join the waitlist. That sign was in English. For many restaurants, that is fine for most guests, but not for all guests. This restaurant serves a customer base where a meaningful subset of guests may need or strongly prefer another language.

That immediately turned into the first real product change driven by field feedback: the guest-facing surfaces need multilingual support.

The important part is that this was not an abstract feature brainstorm. It came from a real operator looking at the real product and explaining what would block adoption in her restaurant.

That is much more valuable than me sitting at home inventing features.

It also changes the scope of “simple waitlist app” in a practical way. The operator-facing app can still be mostly English for now, but the guest-facing entry points matter more broadly. If guests are scanning a sign, reading instructions, and joining a waitlist on their phones, the product needs to meet them where they are.

That means translation support for at least the sign and guest flow, and eventually a cleaner way for restaurants to choose which languages they want to present.

The seasonal wait problem was hard to interpret

That same conversation also complicated my assumptions.

The restaurant had review complaints about long waits. It had a paper waitlist visible near the front. From the outside, it looked like a strong target. But the manager said their real wait problem is more seasonal, especially in winter.

That was surprising because I had seen recent reviews mentioning waits. I also saw the paper process in place. But there was no reason to assume she was being dishonest. She knows her restaurant better than I do, and I was only seeing the outside signals.

This is a reminder that “wait” is not one problem.

A restaurant might have a severe wait only during specific seasons. Another might only need waitlist support on weekends. Another might have a consistent daily wait but still feel that the current manual process is good enough. Another might need better guest communication more than queue management.

The first version of my targeting model was too simple:

• popular restaurant
• review complaints about wait
• likely target

The better model needs more nuance:

• when does the wait happen?
• who feels the pain: guests, hosts, managers, or owners?
• is the current process manual, digital, or vendor-backed?
• is the restaurant already happy with its workflow?
• does the guest base need language support?
• is the restaurant open to changing operations?

Those are not questions Google Maps can answer reliably.

The second manager conversation showed the incumbent problem

The next major conversation was with a manager at a very successful restaurant.

This location looked almost ideal from the outside. It is popular, busy, and appears to have guests waiting regularly. The manager was generous with his time and spoke with me for fifteen or twenty minutes even while preparing for that evening’s rush.

The problem was not that he failed to understand the pain. The problem was that they already had a way of handling it.

They had an existing waitlist system and an existing vendor relationship. That changes the sale completely. I am no longer introducing a solution to an unsolved problem. I am asking them to replace or reconsider something they already use, understand, and have built operations around.

That is much harder.

Even if Shokken is cheaper, simpler, or better in some narrow way, switching has a cost. Staff need to learn a new flow. Managers need to trust a new vendor. The restaurant needs to risk operational disruption during service. A system that is not perfect but is familiar can be more attractive than a system that is theoretically better but new.

This is especially true for successful restaurants. If the restaurant is already busy every night, the operator may reasonably ask: why change the process?

That does not mean Shokken can never win those accounts. It means they are probably not the first accounts to chase.

A custom solution is not the goal

The second manager conversation also exposed a product strategy risk.

When someone explains their specific operational pain, the natural builder instinct is to shape the product around that pain. I could start saying, “Yes, I can build that,” and slowly turn Shokken into a custom software service for one restaurant at a time.

That might close a deal, but it is not the product I am trying to build.

Shokken should be broadly useful to restaurants that need simple waitlist and guest-flow tooling. If every prospect requires a specialized workflow, custom configuration, and restaurant-specific logic, then I am no longer building a scalable product. I am doing bespoke software.

There is a balance here.

Field feedback should shape the product. The language support issue is a good example: it is specific feedback, but the solution applies broadly across many restaurants. That is worth building.

Customizing the app around one restaurant’s deeply established process is different. That may be useful someday for larger accounts, but at this stage it risks pulling the product away from the simple, repeatable use case that made it worth building in the first place.

So I left the materials, gave them my contact information, and treated it as a longer-term opportunity. Maybe social proof, references, and repeated exposure will make a future conversation easier. But it is probably not the right first win.

Yelp Waitlist is a clearer competitor in the field

Another location was already using Yelp Waitlist.

That was useful to see in person. The restaurant had a kiosk where guests could enter their information and join the waitlist. From the staff conversation, they seemed reasonably happy with the current setup.

That is another version of the incumbent problem. If a restaurant already has a system, even one I might think is heavier or less ideal than Shokken, the value proposition has to be strong enough to justify switching.

For those restaurants, the pitch cannot just be “this manages your waitlist.” They already have that. The pitch would need to be:

• easier setup
• lower cost
• better guest experience
• better fit for smaller operators
• faster changes
• more control
• less platform lock-in

But those claims only matter if the restaurant feels pain with the current system. If they are happy enough, they are not an urgent target.

This clarified the early-market profile. I should not spend most of my energy trying to unseat established systems at successful restaurants that are already comfortable. I should look for successful restaurants where the wait problem exists but the technology is still light, manual, outdated, or poorly matched to the way they work.

The target profile is changing

After this first outreach run, the target is sharper.

The best early restaurant is probably not the biggest restaurant. It is not necessarily the busiest restaurant. It is not the one with the most polished existing operation.

The better target is a restaurant that is:

• popular enough to have real waits
• operationally mature enough to care about guest experience
• not already locked into a waitlist vendor
• still using manual or weak tooling
• reachable through an owner or manager
• open to practical help rather than a large software project

That is a narrower market than “restaurants with long waits,” but it is more useful.

The challenge is finding them. Reviews can reveal wait complaints. Photos may reveal a kiosk or sign-in sheet. Social media may show how polished their digital presence is. But a lot of the answer only appears after walking in.

That means this is going to require volume.

The likely hit rate is low. It may take five or ten rejections to find one serious prospect. Because I am doing this myself, the throughput is also low. I cannot visit every restaurant in the valley. I do not have a large ad budget or a sales team.

So the work is slow, direct, and uncomfortable.

There is not really a shortcut around that yet.

Building is the comfortable trap

The other important lesson this week was emotional.

Building is comfortable. Selling is not.

Writing code has a loop. Find the problem, implement the feature, test it, polish it, ship it. Even when the work is difficult, it is familiar. There is a sense of control. I can sit at the computer, open the development environment, and lose myself in the process.

Door-to-door outreach is different.

It was physically uncomfortable. Las Vegas heat is not theoretical; walking from restaurant to restaurant in 43 degree Celsius weather is draining. It was also psychologically uncomfortable. Every conversation carries uncertainty. Some people are polite. Some people are busy. Some people reject the conversation. Even a good conversation may not turn into anything.

That discomfort creates a temptation: go back to building.

It is very easy to justify another feature. Maybe the app needs menu support. Maybe it needs QR-code printing. Maybe it needs better parsing of uploaded menu photos. Maybe it needs language support. Some of those features are real and important. The language support came directly from a field conversation, so it belongs on the list.

But there is a dangerous version of that pattern where building becomes avoidance. If I keep adding features because selling is uncomfortable, then I am not learning from the market. I am hiding from it.

That is the line I need to watch.

Some feature creep is real, some is useful

Shokken has grown beyond a simple waitlist app.

Some of that growth makes sense. The waitlist flow already has guest-facing QR codes, so adding menu viewing is a nearby extension. Restaurants can upload menu images, and Shokken can parse them so the operator does not have to manually enter every item. Restaurants can print QR codes instead of only showing them on a tablet or phone.

Those features may help the product feel more complete.

But this week made the tradeoff clearer. Every feature has to justify itself against the goal of getting real users. A feature that removes a real adoption blocker is worth considering. A feature that exists mostly because I enjoy building it needs more skepticism.

The multilingual guest-facing work is now in the first category. It came from a real prospect, it applies to many Las Vegas restaurants, and it affects whether guests can use the product at all.

Other features may still be useful, but they need to be judged against outreach, not just against what would be fun or elegant to build.

Next Week

Next week is another outreach week.

I need to add the language support surfaced by the first manager conversation, identify another set of restaurant targets, and do another door-to-door run. The likely schedule is Tuesday or Wednesday for a new batch, plus a Friday follow-up for a restaurant whose manager is only available then.

The product work is no longer separate from the marketing work. The marketing is now producing product requirements, and the product has to respond without becoming an excuse to stop selling.