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.

A Real Person Tried to Use Shokken

This week took an unexpected turn: someone reached out because they found that live QR demo on the website.

They’re not a restaurant. They’re organizing an event. But the skeleton of the problem is the same: let people join a line via QR code, and text them so they don’t have to hover in one place waiting.

That was exciting for two reasons:

  1. It’s the first real signal that the product website can pull someone into a conversation.
  2. It’s the first time Shokken was about to be used for something “real” enough that I’d be embarrassed if it fell over.

They were expecting fewer than 100 people, so I offered them a free weekend license and treated it as a chance to stress-test the system.

The Midnight Hotfix

They asked for one change that makes total sense for an event: the default wording in some of the text messages is restaurant-specific (things like “enjoy your meal”), and that doesn’t fit their situation.

I didn’t want to overpromise, because there were less than two business days before the event. But I also couldn’t resist the challenge: could I ship an app + backend tweak fast enough to help a real user without breaking anything?

I ended up doing it the hard way: staying up way too late, pushing a hotfix through, and manually testing it end-to-end. The deploy went green, the tests checked out, and the updated messaging was in place by the next morning.

I’m curious how their event goes, but even getting to this point felt like a milestone: the first time a non-friend was relying on the system.

What does it mean in English?

This week was the first time Shokken felt like something that might actually get used.

The website’s job is to create trust fast enough that someone reaches out. The app’s job is to make the first experience smooth enough that they want to try it again. And when a real person is about to use your product, your tolerance for “it’s fine, I’ll fix it later” drops to zero.

The surprise for me is that the “validation moment” didn’t come from a perfect launch. It came from a rough, real-world use case that was close enough to the core problem that Shokken could help.

Nerdy Details

One backend isn’t enough once anyone depends on you

Until now, I’ve basically been running Shokken with a single backend environment. That’s fine when only friends and family are testing and you can accept a little chaos.

The moment someone real is using it, that stops being acceptable.

If I take down the database because I’m experimenting, I’m not just annoying myself—I’m breaking someone else’s workflow.

So I’m finally doing the work I’ve been avoiding: splitting environments properly.

The shape I want: production, integration, staging

I’m doing trunk-based development, so I don’t want a heavy GitFlow setup. But I still need a clean separation of concerns:

  • Production: stable, locked down, serves real users.
  • Integration: tracks master so I can keep moving fast without risking production.
  • Staging: a release-candidate environment that can be promoted to production on a cadence (probably monthly at first).

In Supabase terms, this means treating the current instance as “production”, then spinning up an “integration” branch for day-to-day development, and using branching to create a staging/release-candidate environment when I cut a release.

The hidden work: keys, builds, and social login callbacks

The hard part about multiple environments isn’t the idea—it’s the bookkeeping:

  • Each environment has its own project URL, anon keys, service role keys, etc.
  • Each mobile build needs to know which environment it should talk to (internal/dev vs. alpha vs. release candidate).
  • If you use social login (Apple + Google), each environment needs its own callback URLs and configuration, because those providers validate against a specific backend.

None of this is visible to users, but it’s the difference between “a fun side project” and “a system you can trust”.

Locking down the automation (and protecting myself from myself)

This also forces an audit of anything that can touch the backend automatically.

If I’ve got GitHub workflows, scripts, or “easy access” shortcuts that can write directly to what I now consider production, they need to be removed or gated. Branch protections, tighter permissions, and fewer backdoors—even if the “attacker” I’m protecting against is me at 1:00 AM.

Next Week

Next week is infrastructure week, whether I like it or not.

I’m going to set up the environment split so I can keep developing safely: lock down production, spin up integration, and start wiring the app builds and social login configs so each build talks to the right backend.

If I have time after that, I’ll get back to finishing the product website’s last-mile assets (especially the video demo) now that I’ve got a real story to tell.