What shipping small products keeps teaching me

Most of what I make is small: an Android browser, an Android companion app for AI agents, a Mac utility, a storefront builder that Mosambee later acquired, and two mobile games. On projects this size, architecture, store listings and the first bug reports sit close together, and the same lessons come back each time.

Below are the ones I keep running into, each tied to a product on this site.

Decide the boundary before the feature list

The first useful decision in each project has been where one part stops and another begins. Features are easier to add once that is settled.

In Aster, the line is between the agent and the device. The agent proposes an action. The Android app decides which capabilities it exposes, under which permissions, and what result it can honestly report. That line holds across all three of Aster’s ways to connect: an on-device MCP server, Binder IPC between apps on the same phone, and an optional remote WebSocket mode.

In TaffyGo, the line is between proposing and acting. Taffy’s logic runs in a sandboxed Rust process that never receives a key, a cookie or a network connection. It suggests a step, a policy engine decides whether that step is allowed, and the Chromium browser process carries it out.

The games follow the same habit. Both are made in Unity 6, and both keep the rules apart from the pictures. In Narrow Front, a plain C# simulation decides each battle, ticking twenty times a second, and the 3D view, camera and effects only draw what it reports. A clear boundary like that makes it possible to test the part that matters without the part that is expensive to run.

Make each claim match its evidence

Small products are tempting to oversell, because nobody else is checking. I try to write descriptions that say exactly what was measured.

ZyadaShop generated an Android app package from a merchant’s configuration in approximately 15 seconds. That number is true, and it is only about generating the APK. It does not include installing the app on a customer’s phone or getting through store review. Saying that out loud kept the product honest about the part it controlled.

TaffyGo’s README says that 1.0 is the first release and that it has so far been tested on one physical phone. Its check commands report when a toolchain is missing and a check was skipped, and they never report a pass for something that did not run. This site follows the same rule in its content schema: a product figure needs either a public source URL or an explicit note that the owner reported it.

Copy written this way sounds a little less confident, and it has saved me from a lot of awkward corrections.

A store listing is its own workflow

Publishing is easy to treat as the last step of building. In practice it behaves like a second product with its own rules.

ZyadaShop made that obvious. Generating an app was an engineering workflow under the platform’s control. Play Store publishing was a separate workflow with its own submission and review stages. The merchant needed to understand which of those had happened, so the product had to show the next step as clearly as the finished build.

TaffyGo has two distribution paths with different signing. The Google Play copy is signed by a key Google holds. The APK on GitHub is published with a checksum file and a certificate fingerprint people can verify with apksigner. Android will not update one install with the other, so the README explains that switching means uninstalling first, and that uninstalling deletes that copy’s data. That kind of detail rarely appears in a feature list, and it decides whether someone trusts the download.

Keep the person in control, visibly

Several of these products act on someone’s behalf, and the control has to be something a person can see and use.

Aster relies on Android accessibility access, which is powerful. It has device approval, a persistent notification that stops screen control, and a package policy that blocks banking apps by default and fails closed. TaffyGo asks before opening more tabs, shows the exact values before filling in a form, never submits the form for you and hands passwords and one-time codes back to the person.

UnfoldMyMac is playful, and it still has this responsibility. A live wallpaper has to say what data it reads, whether that is public GitHub activity, local coding sessions, network readings or weather. Its previews on this site pause when they leave the screen. A desktop effect shares the machine with real work, so it should stop doing work when nobody can see it.

Small does not mean easy to finish

The last stretch of a small project is rarely the code you expected to write.

Siren Jam has 160 levels across eight worlds. A level that looks fine can still be impossible, so the levels are generated from a plan and checked by a solver, which also sets each level’s move limit. Every jam has a known way out. Without that, the game would depend on a person finding every broken level by hand.

Narrow Front’s campaign covers ten small actions, plus eleven skirmish maps, and every battle runs offline. Both games are free to play. Narrow Front has optional rewarded ads and optional in-app purchases; Siren Jam has nothing to buy, and a short optional ad earns extra coins. A business model shapes design decisions well beyond the store page, from what a reward is worth to which screens can show an ad at all.

Open source changes the checklist

Aster is MIT-licensed. UnfoldMyMac is open source, with contribution guidance and artwork notices in its repository. TaffyGo’s first-party code is published under the Mozilla Public License 2.0, while its name, marks and the Taffy character are reserved, so a fork takes the code and picks a new name.

Publishing source adds work that a private project can skip. Licences for every vendored part, a clear statement of what the licence does and does not grant, a way to accept contributions (TaffyGo uses a Developer Certificate of Origin sign-off instead of a contributor agreement), and documentation written for someone who was never in the room. I think it is worth it. People can check what a product does instead of relying on what I say it does.

What I carry into the next one

ZyadaShop was recognised by Google Play as one of the Best Hidden Gems of 2022 in India, and Mosambee later acquired it. The work after it, and the products since, have mostly reinforced the same few habits: settle the boundary early, describe only what you measured, treat distribution as real engineering, and make control visible to the person using the thing.

Those habits add work at the start. In my experience they also make a product easier to finish, and easier for someone else to trust once it is out.