Last Week

Week 52 was mostly about removing friction for testers: automated TestFlight distribution, and federated login so onboarding didn’t depend on email OTP deliverability. The plan for the follow-up was polishing—tightening the UX and smoothing out the rough edges now that both Android and iOS builds were broadly installable.

Instead, I ran into a different kind of deliverability problem: not “can users log in?”, but “can guests actually receive the waitlist notifications?” The email notifications Shokken sends to guests were consistently landing in spam, and that makes the app effectively unusable in a real setting. If the guest never sees the “you’re up” message, the host can do everything right and still look like the system failed.

That forced a pivot: move notifications from email to SMS.

SMS Isn’t a Drop-in Replacement for Email

In my head, switching from email to SMS sounded like a pragmatic engineering trade. Email is cheap, but inbox placement is probabilistic. SMS is more expensive, but the expectation is that it actually shows up.

In practice, SMS isn’t just a different transport. It’s a different industry with different incentives, different failure modes, and a lot more compliance overhead.

The basic problem I’m trying to solve is simple: a host uses Shokken to manage a waitlist, and guests get timely notifications (welcome, “you’re up”, and dismissal). Email was the primary communication channel, and it worked fine on my side of the stack. The issue was the part I don’t control: reputation and filtering.

This is also week 53, which means I’ve officially crossed the one-year mark on this project. The alpha builds are on their respective stores and downloadable, but until notifications are reliable, they’re not ready for real-world testing.

I can add copy in the app telling hosts to warn guests to check spam, but that’s not a real solution. If the workflow requires humans to remember a workaround, the workaround will get skipped—and when it fails, it fails in a way that looks like “the app is broken”.

So I started investigating SMS seriously. That’s where things got interesting.

What does it mean in English?

This week was less about shipping features and more about making the product viable.

  • Guests need notifications that reliably appear when they matter. If messages get filtered into spam, the “waitlist” part of a waitlist app doesn’t work.
  • Switching to SMS isn’t just a toggle. Carriers and providers treat texting as a regulated channel, and you don’t get to send at scale unless you can prove who you are and what you’re sending.
  • The unexpected consequence is that Shokken is forcing me to formalize the business side sooner than I planned, just to be eligible for a toll-free SMS sender.

Nerdy Details

Why email deliverability breaks alpha testing

The email system wasn’t “down”. It was doing exactly what modern email providers do when a new sender shows up with no reputation: treat it as suspicious.

If you’re running a waitlist, the entire UX depends on timely delivery. It’s not like a newsletter where landing in spam is annoying but recoverable. A waitlist notification is effectively part of the product’s control loop. When it doesn’t arrive, the host and the guest both experience it as a system failure at exactly the moment the system is supposed to be most reliable.

I tried to mitigate it with in-app messaging (“tell guests to check spam”), but that’s effectively asking the product to train the user to compensate for the product. That’s backwards.

The three sender types (and why only one made sense)

When you send SMS through an upstream provider, you still have to choose what kind of “from” identity you’re going to use. There are three common options:

  1. 10DLC (10-digit long code): a normal-looking phone number.
  2. Toll-free: a number that starts with 8 (what people think of as an “800 number”, even though it could be other prefixes).
  3. Short code: a 5–6 digit number.

I looked at all three. In theory, any of them could work for a waitlist notification system. In practice, two of them quickly fell out of the running.

Why 10DLC was a dead end for Shokken

10DLC is heavily campaign-oriented. Carriers and regulators worry about spam and impersonation because a 10-digit number looks like a personal device number. To send from 10DLC at any meaningful scale, you have to register your use case and get approved.

Two issues killed it for me:

  • Throughput and rate limits: on the low end, you can be limited to surprisingly small numbers of messages per day and a strict per-minute rate. For a waitlist app, bursts matter. If a restaurant seats a big party or clears a section, you might need to notify a bunch of guests at once. Rate limiting at that moment defeats the entire point of the channel.
  • Per-sender campaign friction: if every business using Shokken needs its own sender identity and its own campaign approval process, you’ve turned “sign up and start using it” into “sign up, then wait for compliance”. That might be fine for a high-touch enterprise onboarding process, but it’s the opposite of what I want for Shokken right now.

So 10DLC was out.

Why short codes were attractive (but not realistic)

Short codes are great for scale and clarity. No one mistakes a short code for “some random person texting me”. Throughput is high, and you avoid a lot of the campaign-by-campaign friction.

The problem is cost. Renting a short code is expensive—on the order of thousands of dollars per month before you even send a single message. That’s not an early-stage expense I’m willing to take on yet.

Maybe one day. But not today.

Why toll-free became the only viable option

That left toll-free.

Toll-free numbers sit in an awkward but useful middle ground:

  • They’re clearly “an organization”, not a personal number.
  • They generally allow higher throughput than 10DLC.
  • They avoid some of the per-user campaign complexity that would make onboarding painful.

But toll-free has its own gate: you still need to verify your organization. And that’s where the project took an unexpected turn.

The surprise requirement: I needed a business entity

When I started building Shokken, I intentionally avoided forming a legal entity. I wanted to stay in “one person building an app” mode until there was traction worth formalizing.

The toll-free verification process doesn’t really allow that. To be eligible for the kind of sender identity I need, I have to be a verifiable organization, not just a natural person with a domain.

So on January 2, I submitted my application to form a business in my state. If all goes smoothly, I’ll get the confirmation next week and then start the follow-on work to become eligible to rent a toll-free number for SMS.

This week ended up being less about Kotlin and UI polish and more about learning how telecom compliance works and what it forces downstream on product onboarding.

The plan from here

Once the business formation is approved, the immediate checklist looks like:

  • Apply for an EIN (Employer Identification Number).
  • Apply for a D‑U‑N‑S number (used as part of business verification flows).
  • Use those to apply for the ability to rent and use a toll-free number for outbound SMS.

Only after that can I finish the end-to-end SMS implementation and put Shokken back into a state where it’s truly ready for testing.

I’m also planning to discontinue my upstream email provider (Resend). The original assumption was “email is the baseline channel”; this week made it clear that for this product, that assumption doesn’t hold.

Next Week

Next week is about getting unblocked so I can get back to product work.

If business formation is approved, I’ll apply for an EIN and a D‑U‑N‑S number, then start the toll-free verification and number provisioning process. Once I have a viable SMS sender, I can finally switch guest notifications away from email and return to the UX polish that was supposed to happen this week.