Last Week

Last week was about getting unblocked on a problem that ended up being bigger than “just swap email for SMS”. Shokken’s guest notifications were reliably landing in spam, which makes a waitlist product feel broken at exactly the moment it needs to feel dependable. Switching to SMS meant walking into telecom compliance, and compliance meant I needed to be a verifiable organization.

The two concrete goals were: form an LLC, and use that newly formed LLC to apply for toll-free SMS access with my upstream provider. This week was the follow-through: turn the “I guess I’m starting a business now” paperwork into something real enough that I can actually send messages without getting throttled into irrelevance.

Becoming Eligible to Send Real SMS

This week had two tracks that fed into each other: business formation (so I could qualify as a sender), and sender strategy (so I could pick a number type that fits a self-serve waitlist app).

On the business side, the happy surprise was how fast most of the process was. My state’s filing fees aren’t cheap, but the actual filing experience was straightforward and the approval came back the same day. Once the LLC paperwork was in hand, I grabbed an EIN from the IRS online. That part was almost comically fast: it’s basically an “answer a questionnaire and get a number” flow, and the approval happened in seconds.

Then I ran into the slow step: the D‑U‑N‑S number. Apple and Google both like you to have one if you want an organization/enterprise developer account, and that process appears to be manually reviewed with a long lead time. So the LLC is formed and the EIN exists, but I’m still waiting on the D‑U‑N‑S before I can convert my developer accounts over.

On top of that, I opened a business checking account. It’s one of those boring-but-important tasks that suddenly becomes real the moment you form an LLC: you can’t keep mixing personal and business transactions if you want the liability separation to mean anything. The next thing to solve there is bookkeeping: I’m currently evaluating accounting software so I’m not trying to reinvent a general ledger in a spreadsheet.

The technical side was the more interesting part (and the reason all of this paperwork exists in the first place). I’m using an upstream SMS provider because Shokken can’t depend on a host device sending texts directly. The host device might be a tablet (which often can’t send SMS at all), and even when it can, I need compliance guardrails and predictable delivery behavior. For this product, reliability is the feature.

Once I went deeper on SMS, the “which phone number type do we want?” decision got a lot clearer:

  • 10DLC (10-digit long code) looks like a normal phone number, which makes carriers treat it as the most compliance-heavy option.
  • Short code is the dream for throughput and clarity, but it’s priced like an enterprise tool.
  • Toll-free is the weird middle ground that’s affordable enough to bootstrap, while still looking “institutional” and avoiding some of the onboarding traps.

This week I was approved for toll-free messaging access and provisioned a toll-free number. That means I can finally start doing serious end-to-end testing of SMS delivery in Shokken, instead of theorizing about it.

What does it mean in English?

This week was about making Shokken eligible to do the thing it needs to do: reliably notify guests.

  • To send SMS at scale, you need to look like a real organization, not just “a person with an app”.
  • The type of phone number you send from affects everything: cost, throughput, and how painful onboarding is.
  • For a waitlist app, delivery speed matters as much as delivery success. If messages back up in a queue, the product fails in real time.
  • Toll-free is the first practical step: it’s affordable, recognizable to guests, and it can be upgraded later if throughput becomes a problem.

Nerdy Details

The surprisingly long dependency chain: “send an SMS” → “form a company”

Before this project, I would’ve described SMS as “a more reliable email”. It’s not. It’s a more regulated channel with more gatekeeping, and a lot of that gatekeeping is upstream of code.

To get access to the number type I wanted, I needed (at minimum) state formation documents and an EIN. To move developer accounts into an organization identity, I also need a D‑U‑N‑S number, which is issued by a private company and seems to take weeks. None of this is hard in a technical sense, but it’s real time on the calendar—and it’s now on the critical path to product viability.

Why Shokken can’t send SMS from the host device

Even if I wanted to, “just text from the iPad at the host stand” isn’t a reliable architecture:

  • Many tablets simply can’t send SMS. They can have a SIM for data, but still not have SMS service provisioned.
  • Even when devices can send, tying notification delivery to one physical device is brittle. Devices get swapped, lost, logged out, or have dead batteries.
  • Compliance is a product requirement, not a nice-to-have. Using an upstream provider means I can follow a well-defined set of policies and verification steps, instead of inventing my own legal interpretations.

For Shokken, the right model is “host action triggers a server-side message send”, with observability around the outbound queue so I can see congestion before it becomes user-visible.

Sender types: why 10DLC looks attractive until you model onboarding

At a high level, the trade space looks like this:

  • 10DLC: cheap numbers, but heavy compliance and onboarding friction. As a solo sender, the quotas are so low that it barely works for a handful of restaurants. As a business, quotas get better, but the compliance story shifts into something worse for me: each restaurant needs its own campaign approval. That turns self-serve onboarding into paperwork and waiting, which is a non-starter.
  • Short code: high throughput and a clear “this is a business” identity. But renting one starts around $1,000/month, which is way too expensive for an early-stage product.
  • Toll-free: affordable and recognizable, with fewer “pretend to be a person” compliance issues than 10DLC. The tradeoff is throughput.

That combination—self-serve onboarding and “notifications must arrive quickly”—is what pushed me toward toll-free.

Segments, quotas, and why “3,000 per day” disappears immediately

One of the first surprises was how quotas are often described in segments, not “messages”.

In the simple case, you can think of it like:

  • A segment is up to ~160 plain characters.
  • If you include emoji or other non-basic characters, the effective per-segment capacity drops dramatically (closer to ~70 characters), and messages split into more segments.

In Shokken, many messages will be multiple segments. That matters because some 10DLC plans (especially individual/sole-prop ones) cap you around 3,000 segments/day.

Here’s a back-of-the-envelope model from the transcript:

  • Assume ~2 segments/message.
  • A restaurant sends ~3 messages/customer over the lifecycle (join/tracking link, “you’re up”, and a final “you’re seated/removed” confirmation).
  • That’s ~6 segments/customer.
  • At 100 customers/day (which is not a high-volume restaurant), that’s ~600 segments/day per restaurant.

At a 3,000 segment/day cap, you’re already down to “about five restaurants” worth of capacity. That’s not a growth plan; it’s a demo.

Throughput is the real waitlist constraint

Even if your daily quota is high, throughput (messages per second) is what determines whether the product feels responsive in peak moments.

With toll-free on my provider, the default throughput is 3 messages per second. If messages are ~2 segments each, that’s roughly “about 1–2 customers per second worth of notifications” during bursts. That’s totally fine for a single restaurant, but at some point multiple restaurants’ bursts will overlap, and you don’t want “you’re up” messages waiting behind other traffic.

The good news is toll-free throughput can be upgraded (the next tier up is much higher), and I’ve already built the analytics/observability I need to watch for congestion. The plan is to treat toll-free as the bootstrap path: get pilot users sending real messages now, and only pay for more throughput once the data says it’s necessary.

Next Week

Next week, I want to start pulling the project back toward product polish and real-world onboarding.

On the business side, I’m going to pick accounting software and get it working cleanly with the business checking account. On the product side, I’m going back to bug squashing and UX polishing now that SMS is no longer blocked on eligibility. And I’m going to start writing actual marketing materials: a landing page that explains Shokken’s value proposition in plain language, and content that helps potential pilot users trust that this is a service they can depend on.