Last Week
Last week, I continued the app-store screenshot redesign and experimented with OpenCode as a model-agnostic coding harness.
This week is a shorter update. I was not feeling especially well, but the development and marketing work continued: the third weekly product video went out, the phone screenshots reached a stopping point, and a surprising database problem turned into an upgrade rehearsal.
Product Videos Keep Moving
I have committed to publishing a short, customer-facing Shokken video every Thursday, and this was the third week of that schedule.
The newest videos show the product rather than the development process. A restaurant operator can follow the guest experience from joining a waitlist, through SMS updates and menu browsing, to finally being called. That gives a potential customer a much faster answer to the question, “What does this actually do?”
I am considering bringing those demonstrations onto the product website too. A steady collection of short videos could explain the app in context and show visitors that it is a real product with continuing work behind it.
The website is beginning to receive some traffic and impressions. That is encouraging, but also mildly terrifying. It is one thing to build a product and prepare its marketing surfaces. It feels different when there is evidence that people are actually looking at them.
The Tablet Screenshot Bottleneck
The app-store screenshots for iPhone and Android phones are now finalized. Tablets are proving harder.
For the current store submission, I need four tablet variations across the two platforms, with eight images in each set. That leaves thirty-two images whose screenshots, messages, formatting, and layout all need to work together.
The difficulty is not taking thirty-two screenshots. It is keeping the same story clear while the available canvas changes shape. Text that is balanced in one format can feel lost in another. A product screen that crops cleanly on one tablet can leave too much empty space on the next.
I expect this work to continue through next week and possibly beyond it. The phone images are real progress, but they do not remove the need to represent the tablet experience well.
An Unexpected Database Upgrade
The development surprise came from PostgreSQL.
The database version running in my integration, staging, and production environments appears to have a bug that amplifies writes during read operations. That matters for Shokken because the client devices poll the backend regularly for an updated waitlist. Even without many changes to save, those repeated reads were producing more database writes than I expected.
I have already performed an offline upgrade in the integration environment, and the early result suggests that it fixed the problem. I am going to keep monitoring it before drawing a firm conclusion. If the extra writes stay gone, I will plan the same upgrade for production.
There are no active production users at the moment, so taking the database offline for a controlled upgrade should not disrupt a restaurant. That makes this a good time to learn the process.
What Does It Mean in English?
Imagine asking someone to read the same clipboard every few seconds. Reading should not change the clipboard, but this bug behaves as though each lookup also creates extra paperwork.
One device doing that is mostly noise. Multiple devices polling throughout a service turn it into a steady stream of unnecessary work. Fixing the database behavior now keeps that overhead from becoming harder to diagnose later.
The integration environment is the rehearsal. I can apply the upgrade there, watch the database metrics, and confirm that normal application behavior still works before I touch production.
Nerdy Details
Polling is a deliberate simplification. Each client periodically asks for the latest state instead of keeping a continuous real-time connection open. It is not the most efficient possible architecture, but it is straightforward and adequate for the product’s current stage.
A WebSocket-based system could push changes as they happen, but it would introduce more infrastructure, connection management, and operating cost. I do not need to redesign that communication path merely because an unrelated database bug made the existing read volume more visible.
The upgrade also exposes a future operational question. With active customers, taking the only production database offline for a few hours would not be acceptable. I would need a migration plan that keeps service available while traffic moves between healthy database instances.
That is a real concern, but it is not today’s problem. Today I can use a quiet production environment to practice the upgrade safely and gather evidence for the more complicated version I may need later.
Next Week
The immediate plan is to finish more of the tablet screenshot work, decide how the product videos should appear on the website, and continue monitoring the upgraded integration database before scheduling production.
I expect the next couple of weeks to be busy outside the project as well, so progress may be uneven. The useful part is that each thread is moving: the product videos have a cadence, the phone screenshots are complete, and the database problem has a testable path forward.