Last Week

Last week was the first week where Shokken felt less like an app under construction and more like a product that needed to be sold.

Android was live on Google Play. iOS was live on the App Store. The first post-approval iOS update moved through review quickly, which made the release process feel less frightening than the initial approval loop. I also finished the first real short-form marketing video and got the physical flyer into a shape I could actually hand to a restaurant.

That changed the next problem. The product exists. The listings exist. The website exists. The first marketing assets exist. Now I need to start putting Shokken in front of real operators, especially busy restaurants in Las Vegas where waitlist pain is visible and local support is practical.

This week still had that marketing thread running through it, but the main story turned into something more operational: I made an unexpected Prime Day purchase because the iOS build machine has become a real development bottleneck.

The App Is Live. The Pipeline Is Slow.

Shokken is now available on both Google Play and the iOS App Store in the United States.

That geographic qualifier matters. Because Shokken uses SMS, I am starting with the United States first. Messaging compliance gets expensive and complicated quickly once the app crosses into other countries, and I do not want to open a broader market until I can support the regulatory and fraud-risk side responsibly.

There was also a small but encouraging surprise this week: two people signed up.

I do not know how they found the app. I have not started serious outreach yet. They are not paying customers because they are not using the SMS features; the core waitlist workflow remains free, and the paid parts begin where the app starts incurring messaging cost. Still, seeing real users appear without a direct invitation is different from testing the app myself. It means the public surface is at least discoverable enough for somebody to land on it and try it.

The next step is still marketing. I need to get better at explaining the product quickly, earning trust, and not wasting the time of people who are busy running restaurants. I have the flyer. I have the first video. I have the app store listings. I still need the actual outreach habit.

But before that becomes the main story, the development infrastructure forced a decision.

My current iOS build setup works, but it is too slow. The Mac that builds Shokken for iOS is an M3 MacBook Air with 16 GB of memory. It sits in clamshell mode and behaves more like a build server than a daily development machine. I do most of the work on my desktop, then hand off the iOS build to the Mac because Apple requires macOS for that part of the pipeline.

That arrangement was tolerable while the app was still moving toward release. It is less tolerable now that the app is public and quick fixes matter.

This week I found an authentication issue that needed a fast update. The fix itself was not the painful part. The painful part was waiting through the iOS build and deployment process. When a routine change turns into half an hour of waiting on the build machine, iteration speed takes a visible hit.

That is how an unexpected Prime Day purchase became part of the development log.

What does it mean in English?

I bought a new Mac because the old one was slowing down Shokken development.

That sounds like a gadget purchase, but it is really a tooling purchase. To ship an iPhone or iPad app, I need a Mac somewhere in the build chain. Shokken is cross-platform, so most of the app code can be shared between Android and iOS, but the iOS build still has to pass through Apple’s toolchain.

The current build machine only has 16 GB of memory. That is fine for many normal tasks, but it is tight for app development with Android Studio, iOS tooling, test runs, and multiple device simulators. The machine can build the app, but it does so slowly enough that it changes how quickly I can fix problems.

So the purchase was about removing friction from the release process. If Shokken is going to be a real product, fixing bugs and shipping updates cannot feel like waiting in line behind my own hardware.

Nerdy Details

The first organic signups matter

The most interesting product signal this week was not dramatic, but it was real.

Two people signed up for Shokken.

That is not revenue yet. They are not using SMS, and SMS is where the paid product begins because those messages cost money to send. The rest of the app is free to use, so a signup by itself does not validate the business model.

But it does validate something smaller and still useful: the app is findable, installable, and coherent enough that a person who was not me could get into it.

That matters at this stage. For a long time, the product work was dominated by platform gates: Google approval, Apple review, subscription product rules, account deletion requirements, privacy links, metadata, screenshots, and the mechanics of getting builds into the stores. When the app is stuck behind those gates, every user interaction is hypothetical.

Now the product is public. Someone can search for Shokken, install it, and create an account. That changes the kind of feedback I should care about.

The next useful questions are no longer only “does the build pass?” or “will Apple approve this?” They become:

  • Can a restaurant operator understand the product quickly?
  • Does the onboarding flow make sense without me explaining it?
  • Does the app communicate which parts are free and which parts require paid SMS access?
  • Does the product look trustworthy enough for a business to try during a real shift?
  • Can the app survive someone arriving from a flyer, store listing, search result, or social profile?

Those questions are marketing questions and product questions at the same time. A signup is not the finish line, but it is the first sign that the public product surface is doing anything at all.

The marketing work is uncomfortable but unavoidable

The next major task is still restaurant outreach.

That is uncomfortable for me. I have an engineering background. I can debug a build, trace an authentication problem, or reason through a backend flow. Walking into a restaurant and trying to explain a product to a person who did not ask to hear about it is a different skill entirely.

The dynamic is awkward because people are pitched constantly. Door-to-door sales has a deservedly bad reputation because so much of it is intrusive, generic, or timed badly. I understand the reaction because I have the same reaction when someone shows up at my house trying to sell me something I did not request.

The lesson is not “never sell.” The lesson is that the pitch has to respect the other person’s time.

For Shokken, that means showing up only where the pain is likely to exist. A quiet restaurant with no waitlist problem is not a serious target. A busy restaurant with frequent wait times, pressure at the host stand, or reviews complaining about the wait is a much better fit.

The flyer helps because it makes the interaction shorter. I can explain the product quickly, hand over something polished, and let the operator inspect it later. The QR codes let them test the guest flow directly. The pitch still needs work, but the assets are becoming real enough to support the conversation.

Prime Day became a forcing function

I was not planning to make a major hardware purchase this week.

Prime Day and the surrounding retailer sales were mostly background noise. Amazon has made its own shopping holiday, and now every other retailer has a differently named version of the same thing. Best Buy has one label. Costco has another. Everyone finds a way to join the event without calling it the same thing.

Normally, that would not matter to Shokken.

The twist was Apple’s pricing.

The configuration I had been watching became significantly more expensive overnight. The exact amount depends on the configuration, but the one I cared about jumped by roughly $2,600. Retailers adjusted quickly. The normal arbitrage path mostly disappeared, because when Apple prices move, the rest of the channel tends to catch up fast.

Costco happened to have a short window where its existing sale price was still being honored. It did not have the exact configuration I wanted, but it had a configuration that was much better than the current machine and still priced before the broader increase had fully landed.

So I bought it.

This was a useful reminder that delaying a tool purchase is not always the responsible choice. Sometimes waiting saves money. Sometimes waiting costs money. In this case, I had already been feeling the pain from the current build machine, and the price move turned a vague future upgrade into a concrete decision.

iOS requires a Mac somewhere in the loop

The reason this purchase matters to Shokken is simple: iOS builds require macOS.

Shokken is written as a cross-platform app. I do not maintain two completely separate applications by hand. The shared codebase lets me target Android and iOS without duplicating every feature, every screen, and every bug fix.

That does not remove Apple’s build requirement. To produce the iOS app, run the simulator, and work through the Apple distribution path, I still need a Mac in the chain.

My current setup separates the job into two machines:

  • I do most of the development work on my desktop.
  • The Mac handles the iOS build and simulator side.

That split is workable. It even has some advantages, because the Mac can behave like a dedicated build server. But the split only works well if the build server is fast enough to stay out of the way.

The M3 MacBook Air has not been fast enough for this workload.

It is not a bad machine. For normal use, 16 GB of memory on Apple silicon can go surprisingly far. macOS also handles memory pressure and swap better than people sometimes expect.

But development workloads are not normal use. A cross-platform app build can involve the IDE, Gradle, Apple tooling, simulators, test processes, caches, and background services. When memory pressure goes red during builds, the machine still completes the job, but the cost is time.

That time accumulates.

CI gates make slow builds more expensive

Slow local builds are annoying. Slow gated builds are worse.

Shokken’s repository uses checks around pull requests. Those checks exist for good reasons. They help catch regressions, enforce basic quality, and reduce the chance that a change breaks data handling, authentication, privacy-sensitive flows, or platform behavior.

That means iOS is not an optional afterthought. A change should build and test against the iOS app before it is merged. If the app is public on iOS, the iOS build needs to be treated as a first-class release target.

The problem is that every change now pays the iOS build cost.

If the Mac takes around half an hour to get through the relevant iOS work, that affects the whole development rhythm. A small authentication fix does not feel small if I have to wait through the same slow build cycle repeatedly. The feedback loop gets longer. Context gets stale. The temptation to batch too many changes together increases, which is the opposite of how I want to run a careful release process.

Good CI should make shipping safer without making iteration miserable. The current hardware was starting to push that balance in the wrong direction.

Memory is the real constraint

The purchase was mostly about memory.

The configuration I wanted had at least 64 GB of memory. That may sound excessive until the workload is broken down.

Android Studio or IntelliJ can consume a large amount of memory by itself. The transcript estimate was around 16 GB just for the IDE in a serious session. That is before counting macOS, build tooling, caches, browsers, terminals, and any support processes.

Then come the simulators and emulators.

For Shokken, testing responsibly means caring about both platform and form factor:

  • Android phone
  • Android tablet
  • iPhone
  • iPad

That is four device targets. Each emulator or simulator can consume several gigabytes of memory. The exact amount varies, but four to five gigabytes each is not unusual once the system is running real app workflows.

The math gets ugly quickly. Before the operating system and build tools are even counted, the development session can already be deep into the 30 GB range. A 16 GB machine can survive that only by leaning heavily on swap. Surviving is not the same as being efficient.

That is why 64 GB felt like the right target.

Costco did not have the exact 64 GB configuration I wanted, so I bought a 48 GB configuration instead. That is a compromise. It is still a major improvement over 16 GB, and it should give the build system enough breathing room to avoid the worst memory-pressure behavior.

The 128 GB configuration would have been fun, but it moved out of a practical price range. This is a business tool, not a trophy purchase. The goal is to speed up Shokken development, not win a spec sheet.

Waiting for the next generation was the wrong frame

The gadget part of my brain wanted to wait.

There is always a future machine. There is always another chip, another display technology, another chassis, another rumor, another reason to delay. The next generation might be thinner. It might have a nicer screen. It might have better performance. It might solve some unrelated annoyance.

That thinking makes sense when the purchase is entertainment.

It makes less sense when the purchase is a tool that is already blocking work.

The build machine does not need to be exciting. It needs to build Shokken faster and with less memory pressure. A future screen technology does not help a clamshell machine acting as a server. A thinner laptop body does not make pull request checks finish sooner. Waiting for a rumored future configuration does not fix the authentication issue I needed to ship this week.

That was the real lesson.

I was treating the Mac like a gadget decision when I should have been treating it like infrastructure. Once the app is public, infrastructure friction is product friction. If it slows down fixes, it affects users. If it slows down releases, it affects momentum.

The purchase should improve the release loop

The new machine will not magically make marketing easier.

It will not write the restaurant pitch. It will not convince anyone to try Shokken. It will not replace the uncomfortable work of showing up, explaining the product, and learning from rejection.

But it should make the engineering side less painful while that marketing work begins.

That matters because public products generate interruptions. A bug can appear. A user can hit an account issue. A store listing can need an update. A small fix can become urgent. When those moments happen, I need the release pipeline to support fast response instead of turning every update into a long wait.

The current Mac got Shokken through the first public release, which is not nothing. But the next phase needs a faster loop.

Next Week

Next week is still about getting Shokken in front of real restaurants.

The marketing package is close enough that I need to move from preparation into outreach. That means tightening the short pitch, smoke testing the flyer QR flows, making sure the app store and website paths are ready, and starting conversations with busy local restaurants.

The hardware purchase should help with the engineering background noise. The main challenge now is not whether I can build the app. It is whether I can get the right people to try it.