The Feature I Left Out: What JAML Taught Me About Trust as Architecture

JAML is an Android launcher that replaces your phone's wall of icons with a calm list of words. Its most important feature is one I left out: it requests no internet permission at all. That's a stronger claim than "we don't collect your data": the operating system will not allow the app to send a single byte anywhere. The marketing site puts it plainly: it can't phone home, literally.

That one omission taught me more about trust than anything I've added to software.

Promises are policy. Architecture is proof.

Every app says it respects your privacy; the claim costs nothing and expires with the next management decision. JAML's claim is structural. A curious user can verify it in the phone's settings in 10 seconds, and no future version of me can quietly change it without asking the operating system, publicly, for a new permission.

The general principle: a promise enforced by architecture is worth a hundred enforced by intention. And it applies far beyond privacy:

• "Only managers can approve discounts over 10%" as a policy memo vs. as a rule the system enforces: one survives employee turnover, one doesn't.
• "Invoices are never edited after posting" as training vs. as an append-only record: one is auditable, one is archaeology.
• "The AI can't spend more than $50 a month" as a dashboard someone watches vs. as a hard server-side cap: I build the cap.

When I review systems for clients, this is the lens: which of your business rules exist as architecture, and which exist as hope? The gap between those lists is your risk register.

Constraints are also a product decision

JAML's whole product is subtraction: no icons, no widgets, no badges, no feed. Every installed app is hidden by default; your home screen shows only the words you deliberately placed there. The constraint is the value, and it's the hardest kind of decision to hold, because every user request and every idea pushes toward addition.

Business software has the same gravity. Tools grow fields nobody fills, screens nobody opens, and options that exist because saying no to a stakeholder was awkward in 2019. Every addition costs training, testing, and attention forever. One of the most valuable sentences a developer can say to you is "I'd leave that out", and one of my standing rules is to say it even when it shrinks the invoice.

Boring on purpose

Under the minimal surface, JAML is built conventionally on purpose: standard Android architecture, a local database with tested migrations, the patterns any competent Kotlin developer would recognize in an afternoon. For a tool people run on their primary device all day, novelty is a liability. The same holds for the systems your business depends on: the exciting part should be what the software does for you, and how it's built should stay boring. "Boring inside, opinionated outside" is a compliment I aim for.

If there's a rule your business currently enforces by memo and hopes for the best, or a system that's grown so many features nobody can find the four that matter, that's exactly the kind of conversation I like. Sometimes the most valuable build is the one where we take things away.