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. It needs to earn trust quickly and give someone a reason to take the next step.
A Hero Section You Can Actually Use
The main thing I wrestled with this week is attention.
I’ve been learning (slowly) that the first 5–10 seconds of a visitor landing on a page are unbelievably valuable. If the first screen requires careful reading, or the “here’s what this looks like” story takes a minute-long video, you’ve already lost most people.
I tried to think through the usual solutions—screenshots, walkthrough clips, long-form explanations—but they all felt like they demanded too much deliberation from someone who’s just trying to decide whether this is worth their time.
So I leaned into one of Shokken’s core workflows instead: QR-code self-join.
If you’re running a busy host stand, the best version of a waitlist is the one that removes friction for the staff. Shokken can display a QR code on a tablet so guests can scan it and join themselves, then get text updates as their place in line changes.
The idea I landed on was: why not make that the first thing a visitor sees on the website?
Instead of asking a restaurant owner to imagine what the app feels like, I can let them try it immediately:
- The hero section shows the same “scan this QR code to join” experience you’d put on a tablet.
- If you have a second device, you can literally scan it.
- If you’re on a single device (which is most people), you can click it and get taken to a live join page, as if you had scanned it.
- When you come back to the site, you can see the guest count update and understand that this is a real, live system—not mock screenshots.
I don’t pretend to be a marketing expert, but as a product builder it feels like a good fit: it’s visual, it’s interactive, and it demonstrates value without a wall of text.
What does it mean in English?
This week was about turning “a website that explains the app” into “a website that proves the app is real”.
Screenshots and long demo videos can work, but they ask for attention up front. An interactive demo flips the burden: instead of convincing someone with claims, you let them press a button and see something happen.
The broader lesson for me is that the first impression isn’t a design detail—it’s part of the product. If I want real restaurants to test Shokken, I have to make the first step feel obvious, safe, and fast.
Nerdy Details
Why I didn’t build the product site with Kotlin Multiplatform
Shokken is Kotlin Multiplatform, and KMP can technically target the web (including WASM), but the web target still feels too experimental for what I need right now.
The marketing site has to be lightweight, fast to iterate on, and “boring” in the best way: stable and easy to ship. The goal isn’t to prove a stack choice—it’s to get a clean front door in front of users.
Astro, “no server”, and the shape of the demo
I’m building the product site with Astro, aiming for a simple JAMStack setup.
There’s still a backend database for Shokken, but I don’t want to run a separate application server just to power the marketing site. That pushes the architecture toward “the app runs in the browser and talks directly to the backend”.
That’s where the interactive hero demo becomes interesting (and dangerous).
If the website can talk to your backend directly, you have to be extremely deliberate about what it’s allowed to do and what data it can see. Otherwise, you’ve turned your marketing site into a new attack surface.
Security constraint: demo data must never expose real people
The demo needs to feel live, but it can’t leak anything sensitive.
The shape I’m working toward is:
- The hero demo is backed by a “mock restaurant” that contains no real customer data.
- The website can only read the minimum public state it needs to display the demo (like a guest count).
- Any write path is constrained and abuse-resistant (because a public join endpoint is a perfect target for bots and bored teenagers).
In practice, this means treating the demo as a sandboxed slice of the system with strict permissions, rather than letting the marketing site wander around the real backend.
Responsive design: the web is chaos compared to tablets
Another challenge is purely visual: a QR-code display page in the app is designed for a fairly predictable device class (a tablet at a host stand).
On the web, the screen could be a tiny phone or a giant desktop monitor. Even if the demo is “the same UI”, the layout has to adapt gracefully across a ridiculous range of aspect ratios. That’s why the first version works but still doesn’t feel as polished as it should—I need to keep iterating on spacing, scaling, and how the demo sits inside the hero layout.
The marketing backlog is real work (and it gates Play Store progress)
I also got reminded that some of the most important “engineering” work at this stage looks like marketing:
- Adding analytics so I can tell what’s working.
- Tightening copy so the value is legible quickly.
- Producing screenshots and a store listing that help people trust the product.
I want to move Shokken on Google Play from internal testing to external testing. External testing removes a lot of friction for new testers, but it also forces the store listing to be in real shape: descriptions, tags, screenshots, and everything else that turns “download” into “I trust this”.
Next Week
Next week is about finishing the website the right way: tightening the copy, making the hero demo look great across screen sizes, adding analytics, and removing the “site under construction” banner.
After that, I want to tackle the app store listing work so I can move Google Play from internal testing to external testing and make it significantly easier for new testers to install Shokken.