Last Week

Last week was about clearing the biggest blocker to real-world testing: guest notifications. I formed an LLC, got an EIN, and provisioned a toll-free number so Shokken can send SMS reliably without depending on a host device. That got the project out of “email deliverability limbo” and back into a place where the app can actually be evaluated by restaurants in the way it’s meant to be used.

But that work also dragged a bunch of unglamorous dependencies into the critical path: business verification, banking, and the kind of organizational identity that Apple, Google, and telecom providers all want to see before they’ll treat you as a legitimate sender.

Marketing Is Its Own Engineering Discipline

This week ended up being a mix of operational follow-through and a mental shift: I need to start treating “people can discover and trust this product” as a feature.

The app is in alpha and installable on both iOS and Android, and I ship updates every Tuesday. I’m fixing bugs daily, and the UI is getting to a place where I’m genuinely proud of it. But none of that matters if I can’t get the right people to try it in the real world.

The Unsexy Plumbing: D‑U‑N‑S and Banking

The biggest operational win is that I finally got a D‑U‑N‑S number assigned. It sounds ridiculous to say out loud, but it’s a real milestone: it’s one more piece of “this company exists” verification that upstream systems use to decide whether you’re allowed to do normal things.

I also opened a business checking account and started moving vendor billing over. I expected this to be a five-minute “fill out a form” job, because personal banking has been optimized into a few clicks. Business banking is not that. It was a two-hour, in-person “know your customer” process with a lot of questions and paperwork.

I get why it exists, but it was still a surprise: the moment you switch from “a person building an app” to “a business operating software”, the administrative surface area expands quickly. And the monthly costs are becoming real, because Shokken depends on a stack of upstream services that all want their share.

The Next Gate: Organization Developer Accounts

With the D‑U‑N‑S number in place, the next step is to convert my Apple and Google developer accounts from individual to organization accounts. It’s mostly about credibility and continuity: if Shokken is going to be a real product, it needs to be anchored to a real entity, not to me personally.

I expect the conversion itself to take time because both platforms are rightfully cautious about fraud. So the plan is to start the process now and let it run in the background while I keep shipping weekly updates.

Learning the “Language” of Landing Pages

The more interesting part of the week was marketing research. I’ve always treated marketing as “that other world”, but once I started looking closely, I realized it has the same shape as engineering: a vocabulary, a set of patterns, and an optimization mindset.

The most obvious example is the structure of a landing page. There’s the big initial section in the center (the “hero”), then trust signals, testimonials, and obvious call-to-action buttons. I’ve seen these elements a thousand times without ever naming them. Now I’m trying to apply them intentionally: if I want restaurants to trust a new waitlist tool, I need a front door that makes the product feel real.

Pilot Strategy: Make It Easy to Say “Yes”

During the initial pilot, my plan is to make the service free for early adopters. I’m going to eat the upstream costs because you can’t buy better testing than actual end users putting the product through its paces during real rushes.

That trade is worth it to me. If Shokken is going to work, it needs feedback from hosts and guests in the wild—not just my assumptions in a quiet office.

What does it mean in English?

This week was about making Shokken look and behave like a real product outside my editor.

  • A “real” app needs a “real” company identity, because lots of important systems (app stores, SMS providers, banks) gate access on verification.
  • Marketing isn’t optional: if the right people don’t find Shokken and trust it, the code doesn’t matter.
  • The immediate goal is a simple website that explains what Shokken does and makes it easy for pilot users to try it.
  • The pilot plan is to keep it free up front, in exchange for feedback that makes the product better.

Nerdy Details

“Small business app” has enterprise-shaped dependencies

If you zoom out, the core promise of Shokken is very small-business friendly: a simple waitlist tool for restaurants that don’t have a dedicated software team. But to deliver that promise reliably, I’m forced to integrate with systems that were designed around organizational identity and compliance.

The dependency chain looks like this:

  • A restaurant waitlist needs reliable guest notifications.
  • Reliable notifications push me toward SMS instead of email.
  • Meaningful SMS throughput and deliverability pushes me into a verified sender identity (toll-free now, with potential upgrades later).
  • Verification pushes me into business formation, a bank account, and identity numbers (EIN and D‑U‑N‑S).
  • Those same identity artifacts are also prerequisites for converting Apple/Google developer accounts to organization accounts, which matters for long-term continuity.

None of that is hard in the “write a function” sense, but it’s absolutely part of the engineering work. It’s the scaffolding that lets the rest of the system exist.

Developer account conversion as a risk-management step

I’m converting developer accounts for a simple reason: I want Shokken to survive past the “one person hacking” phase.

An individual account ties distribution to a person. An organization account ties distribution to the product. That matters for:

  • Credibility (restaurants are cautious about installing unknown software).
  • Continuity (the app should outlive any one person’s personal identity).
  • Operational hygiene (billing, legal, and tax surfaces are cleaner when the product has a proper home).

The conversion flow itself is mostly procedural, but it’s the kind of procedure you want to start early because it can take days or weeks to clear review.

A landing page is a UI surface with a different user

The landing page problem is similar to product UI, but the “user” is different. In-app UI is for a host who already decided to try Shokken. The landing page is for someone who hasn’t decided yet and is actively looking for reasons to say “no”.

So the structure needs to do a few things quickly:

  • Explain the value proposition in plain language.
  • Show enough proof that this isn’t vaporware.
  • Make the next step obvious (a single, clear call to action).
  • Reduce perceived risk (what happens if it doesn’t work, how hard is it to try).

The part I’m leaning on that most waitlist tools don’t have is the dev log itself. A restaurant owner doesn’t need to care how Kotlin Multiplatform works, but they do care whether the person behind the product is real, responsive, and likely to still be around when something breaks on a Friday night. These weekly updates are part of that trust story, even if the audience is small right now.

Why “free pilots” aren’t really free

When I say “free for early adopters”, I don’t mean “free to run”. I mean “I’m paying the bill while the product proves itself”.

The cost model for a waitlist product has some interesting properties:

  • Costs scale with usage at the exact moment the product is providing value (messages, traffic, auth, storage).
  • Peaks matter: a Friday dinner rush is where you learn whether the system is actually dependable.
  • Real-world testing is expensive, but it’s the only way to uncover failure modes that don’t appear in a controlled environment.

For a pilot, that trade makes sense. I’d rather learn what breaks now—while I’m directly involved with onboarding and support—than later when expectations are higher.

Next Week

Next week is about turning “preparation” into something visible.

I’m going to start the organization conversion process for my Apple and Google developer accounts, continue tightening the app with bug fixes and UI polish, and publish the first version of a marketing website that explains Shokken clearly and makes it easy for pilot users to try it.