Blogs

Last Week Last week was infrastructure week. I finally split Shokken into integration, staging, and production backends so I could keep building without treating real users like crash-test dummies. That work mattered immediately, because both the Android and iOS beta builds are now live in their respective test tracks. I expected this week to be more website polish: tighten up the marketing pages, improve the presentation, and keep delaying the uncomfortable part where strangers actually use the product....

Last Week Last week was the first time Shokken felt like it was brushing up against the real world. Someone reached out because they found the live QR-code demo on the website and wanted to use it for a real event, which forced a late-night hotfix and a whole new level of seriousness about reliability. That experience made something obvious: I can’t keep treating “the backend” as one big shared sandbox....

Last Week Last week was still (somehow) about the product website. The core pages are basically done, but I kept stalling out on the last-mile marketing assets—especially the video demo. The bright spot is that the interactive QR-code “self-join” demo is live in the hero section now. You can scan or click it, join a mock waitlist, and watch the site update in real time. It’s the first part of the website that feels like it proves Shokken exists instead of just describing it....

Last Week Last week’s goal was to finish Shokken’s product website: the pages that explain what the app does, what problem it solves, and what the next step is if you’re a restaurant that’s curious. Most of the site is now “done enough” from a functional standpoint, but I got stuck in the part that’s harder to ship: making it compelling. A marketing site isn’t just an information dump—it’s a conversion surface....

Last Week Last week was about trying to get Shokken ready for the “real world” instead of just the “builder world”. The alpha builds are in a good place on both Android and iOS, and I’m still shipping weekly updates as bugs and rough edges show up from testers. The big non-app milestone was the product website: getting it to the point where it explains what Shokken is, what problem it solves, and what the next step is for a restaurant that’s curious....

Last Week Last week was about building a real “front door” for Shokken: the product website. The layout, content, and overall structure are in a good place, but I still need the assets that make it feel real—screenshots and a short demo video that show the app in motion. On the app side, the theme is still the same: the alpha builds are usable, I’m shipping updates, and testing keeps surfacing bugs and rough edges that I didn’t anticipate....

Last Week Last week was about turning “this app exists” into “this product exists”. I got my Google developer account converted from an individual account to an organization account (Apple is still in review), and I started doing the early work on a real product website: figuring out what a landing page needs to communicate, what trust signals matter, and what the next step should be for someone who’s curious enough to try Shokken....

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....

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....

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?...