Last Week
Last week, I started improving how Shokken presents itself online. The app is available to US users on Android and iOS, but simply being in the stores does not mean the listing explains the product well or gives the right customer a reason to download it.
That work is still underway. The app-store screenshots in particular have taken much longer than I expected. A good listing does not just show a stack of raw screens. The images need to tell a coherent story about the problem Shokken solves while staying legible, polished, and consistent.
This week, I continued that marketing work and also experimented with a different kind of tool: a coding harness that separates the development experience from any one model provider.
App-Store Screenshots Are Their Own Design Project
The current store screenshots are functional, but fairly generic. They show the app without doing enough to explain it. The new set combines product screens with a clearer message so that moving through the images feels like a short introduction to Shokken rather than a tour of disconnected interfaces.
Consistency is where the work becomes difficult. Shokken runs across small phones, large tablets, and the web. The same visual idea has to survive different aspect ratios, crops, device frames, and store requirements without looking like each image came from a different campaign.
I am close to being happy with the phone images, but the tablet versions still need work. Tablets matter because they are a primary surface for restaurant staff, so I cannot treat those screenshots as an afterthought just to finish the listing sooner.
The product website has also received a brighter, friendlier visual update. The planned launch-pricing change has not happened yet. That update crosses the subscription system, backend, database, and website, so I want to finish the current app-store work before changing all of those surfaces together.
A Model Is Only Part of the Coding Experience
The larger experiment this week was with the software around the AI model.
A model by itself produces tokens. The coding harness is what turns those responses into a development workflow. It supplies system instructions and project context, exposes tools, manages files and commands, presents the interface, and coordinates any agents involved in the work.
That means the quality of an AI-assisted programming session depends on more than which model sits behind it. The same model can feel very different depending on how the harness provides context, asks for permission, handles tools, and keeps track of the conversation.
My default assumption had been simple: use Claude Code with Claude models and Codex with OpenAI models. Those first-party pairings make sense, but they also couple the workflow I have built around a harness to the models that harness is designed to use most directly.
Why I Wanted More Flexibility
Usage limits made that coupling more noticeable. I had developed the bad habit of using the strongest model available for almost everything, including small jobs that did not need it. That is convenient until the expensive capacity runs out before the next reset.
Delegation gives me another option. Straightforward, well-bounded tasks can go to a faster model, while product decisions and holistic review can keep the models with stronger judgment. I explored that idea in more detail in the week 84.5 post, where I described an implement-review-fix loop built around fresh subagents.
The awkward part came when I tried to route work outside a harness’s native agent system. I could launch another command-line job, but then the orchestrator had to poll the operating-system process and infer whether it was still healthy. If the process died without the polling logic recognizing it, the whole workflow could sit and wait forever.
I had already tried versions of that approach, and it was too brittle. I wanted model choice without rebuilding fragile process coordination around every provider.
Trying OpenCode
That brought me to OpenCode, an open-source coding harness designed to work across model providers.
I had dismissed it earlier because I assumed a third-party harness could not handle a provider’s models as well as that provider’s own tool. After trying it with model access I already had, I changed my mind quickly. The experience felt polished, and the provider boundary was much less visible than I expected.
The largest benefit is not any single interface feature. It is that the harness and the model provider are now separate decisions. If I want to route different responsibilities to different models—or change providers later—I can adjust the model configuration without replacing the entire working environment around it.
OpenCode also includes practical workflow features I had missed elsewhere. It can track file changes so a session can undo them, and it offers several ways to resume or connect to a working session. Those details matter because I develop from more than one computer and occasionally need to continue a conversation away from the machine where it started.
I am still in the honeymoon phase, so this is an early impression rather than a final verdict. A new tool always feels especially good while its strengths are fresh and its limitations are still undiscovered.
Packaging the Workflow Instead of Hand-Rolling It
The other discovery was the OMO plugin, previously known as Oh My OpenCode. It packages an opinionated agent workflow around OpenCode, including specialized roles and orchestration behavior.
That overlaps with work I had been encoding by hand in my own Codex instructions: discover the codebase, evaluate the request, resolve product and architectural questions, prepare a plan, review it independently, implement the accepted plan, and review the completed change.
I have also been moving pieces of those long instructions into skills so that the agent only loads the procedure it needs for the current task. OMO approaches much of the same problem as a reusable plugin. If I had found the combination earlier, I might have saved a week or two of tuning my own configuration.
That does not make every opinion in the plugin correct for my projects, and it does not eliminate the need for tests, scope limits, or human approval. It does give me a stronger starting point than recreating every coordination rule from scratch.
Next Week
I plan to keep using OpenCode and OMO long enough to get past the first-impression glow and see whether they actually improve my day-to-day work.
The risk is familiar: discovering a promising tool can become an excuse to spend days polishing the tool instead of using it. The goal is not to build the perfect coding environment. It is to make the work more efficient while I continue the app-store screenshots, website updates, and pricing changes that put Shokken in front of customers.