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.

That shift matters because I’m at an awkward stage: the iOS and Android alpha builds are usable, I’m shipping weekly updates, and I’m fixing bugs daily—but I still don’t have a clean front door that explains what the product is and makes it easy for real restaurants to get involved.

A Product Website Is a Different Kind of UI

This week was mostly about the product website and all the hidden work that comes with it.

I’ve been happy with Hugo for the dev blog. It’s incredibly efficient for publishing long-form content, and the “push a markdown file, get a site” workflow is exactly what I want for weekly posts.

But a marketing site has a different job. It’s not an archive. It’s a conversion surface: a few pages that need to feel modern, load fast, and answer questions quickly enough that a skeptical visitor doesn’t bounce. And the ecosystem around that kind of site—themes, components, and patterns—is different than the ecosystem around blogging.

So I ended up doing the part I always try to avoid: learning just enough of a new stack to ship something that looks like it belongs in the current web. The goal is intentionally simple:

  • A clear explanation of what Shokken does.
  • A signup flow.
  • A scheduling widget (I’m planning to embed a cal.com calendar) so a pilot customer can book time without email back-and-forth.

At this point, the site is mostly feature complete: layout, colors, and content are close. The remaining work is surprisingly non-code: I need screenshots and a short screen recording from the app that are not only informative, but punchy enough to communicate polish.

That’s the new theme I’m noticing as I move closer to real-world testing: every “last mile” task is about presentation and confidence. The work isn’t hard in the algorithmic sense, but it is still real engineering effort—because it directly determines whether someone trusts the product enough to try it.

What does it mean in English?

This week was about getting Shokken ready to be evaluated by people who don’t already care about the project.

  • A product website isn’t “just a website”; it’s the front door and the first trust test.
  • The stack choice matters less than the end result: fast, clear, modern, and easy to take the next step.
  • Screenshots and a short demo video are part of the product, not marketing fluff—because they’re how people decide whether the app feels real.
  • As more testers touch the app, the bug backlog becomes a moving target, so I need a more disciplined “freeze and test” approach.

Nerdy Details

Hugo vs. a landing-page-first stack

Hugo is excellent when your site is mostly content. It’s fast, the build is predictable, and the unit of work is “write a markdown file”.

A product site is closer to an app UI than a blog post. The unit of work is “make this one section look right”: spacing, typography, responsive layout, and the small interaction details that make the page feel modern. That usually means leaning more heavily on component ecosystems and patterns that are tuned for marketing pages, not for article publishing.

I don’t think there’s a perfect answer here—only tradeoffs:

  • If I optimize for “I know this tool”, I risk shipping something that feels dated.
  • If I optimize for “this looks great”, I take on a short-term learning curve.

This week, I chose to pay the learning curve so the result matches what users expect from a modern product.

“It builds” isn’t the same as “it looks right”

One thing that surprised me is how many failure modes exist between “the site compiles” and “a human trusts it”.

For pure backend work, a passing build and a green test suite are strong signals. For user-facing work, the feedback loop has to be visual and fast. A layout can be technically correct and still be wrong: awkward spacing, inconsistent hierarchy, or a page that technically works but doesn’t read well on a phone.

That’s why the workflow matters: I need to be able to iterate quickly, see the page rendered, and make changes until it feels right.

The bug treadmill and the need for a frozen build

On the app side, I’m still doing the daily bug-fix grind. This week I closed roughly 10–15 tickets, and the pattern continues: for every bug I close, a couple new ones appear as more people test from fresh perspectives.

I’ve also been reminded (the hard way) that regressions can appear from build to build. If I want the first “publishable” build to feel punchy and reliable, I need to pick a build, freeze it, and test aggressively against that snapshot instead of constantly chasing the moving target.

Billing as a guardrail, not a growth feature

The closer I get to onboarding real users, the more obvious it becomes that I need cost guardrails before I scale up activity on the backend.

I’m using RevenueCat for purchases, and I’ve already done the provider-side setup (store configuration, RevenueCat configuration, and backend wiring so purchase state can flow into the system). Next is the app-side integration: wiring the SDK into Shokken, building a paywall, and setting up mock purchases so I can validate the end-to-end flow without charging anyone for real.

This is one of those tasks that doesn’t feel like “building features”, but it’s necessary infrastructure. If I’m going to run a real pilot and push people toward real usage, I need a clear boundary between “this is safe to use freely” and “this could accidentally run up a bill”.

Next Week

Next week is about turning “mostly done” into “ready for real people”.

I’m going to finish the website by producing the screenshots and short screen recording it needs, keep grinding down the bug backlog, pick a build to freeze and test heavily, and wire RevenueCat into the app with a real paywall and mock purchase testing. I’ll also keep an eye on the Apple organization account conversion as it moves through review.