Most engineering profiles are a list of employers. That tells you where someone was, not what they were doing there. This is the second thing.
Architecture standards for organizations that don’t have one
I have walked several times into a mobile codebase where every screen used a different architecture and nobody could say which one was correct — not because the team was careless, but because no document existed to be correct against, and no team was accountable for writing it.
I write that document. Clean Architecture adapted to the codebase that actually exists rather than to a conference talk: feature module creation, the API / mapper / domain-model data layers, the repository boundary, dependency injection wiring, and testing guidance at every one of those layers. Then I move it out of the wiki and into the repository, next to the code, where a change to the architecture and a change to the doc can land in the same pull request.
The distinction I care about: a standard nobody can enforce is a preference.
AI code review that knows the architecture
Point an LLM at a diff with “you are a code reviewer” and you get generic review: naming nits, a suggestion to add a comment, an opinion about a variable. It is fast and it is worthless, and it teaches a team to ignore the bot inside a week.
What makes review agents useful is the thing most teams skip: writing down what correct looks like first. I build review agents grounded in the architecture standard itself — hundreds of lines of criteria derived directly from it — so the agent catches a layering violation, a state holder that will replay navigation events on rotation, or business logic sitting two modules from where it belongs. Specific enough to be wrong, which is the only way to be useful.
I ran a tuned agent privately against real production pull requests for months before proposing it to an organization. Shipping a tool you have already lived with is a different proposition from shipping a prototype, and it changes the conversation from “should we try this” to “here is what it caught.”
Hardening it was the easy part — reject fork pull requests, gate triggers on author association, measure token spend per diff before rollout rather than after the invoice. The judgment calls were these:
- The tool does not get to be a second source of truth. The architecture document decides; the ruleset implements it. The moment review automation starts mandating patterns with no precedent in the codebase, you have manufactured an authority nobody agreed to and everybody now has to satisfy. I have declined rules on exactly that ground, including ones proposed by people above my level.
- Merging a rival implementation rather than beating it. A second, repository-wide implementation appeared on another platform at the same time as mine. Neither was dropped: one workflow, my ruleset as the platform content layer, an equivalent to follow for the other platform. Two engineers with no reporting line between them and one tool at the end of it.
- Ownership that outlives whoever built it. The workflow belongs to the guild; the review rules belong to the platform they cover, so an Android rule change requires an Android reviewer. Without that split the two copies re-diverge inside a year and nobody can say whose rule is the real one.
- Knowing when a practice will not transfer. Backend teams point their agents at contributing guides and agent files and it works, because they have the senior density to keep those documents honest. Copy the pattern into a mobile repository that has neither the documents nor the density and you get a reviewer grounded in nothing. The prerequisite was never the tool.
The through-line with everything above it: the interesting question in 2026 is not whether a model can write your code. It is what you had to write down before one could review it. An architecture standard nobody wrote is also an architecture standard no agent can enforce.
Currently working toward Claude Certified Architect — Foundations through Anthropic Academy.
Cross-platform decisions, made once
I lead work across Android, iOS, and backend, and the thing I push hardest on is that a contract specifying two clients should be one document, not two that agree today.
In practice that means: merging separate iOS and Android technical design documents into a single specification before either implementation exists. Resolving platform-specific behavior server-side, off the request header, rather than letting each client invent its own workaround. Instrumenting both platforms on one dashboard so they are measured against each other rather than separately. Reading the service, and being willing to open a pull request in it.
Client-server contract questions are where I do some of my best arguing — idempotency on debounced mutations, whether a write returns the state it produced or leaves the client to re-read it, and what happens in the window between those two things. These are not backend problems that mobile inherits. They are mobile problems with a backend cause.
Observability that answers the question actually being asked
Crashlytics tells you the app crashed. It will not tell you a release is quietly degrading, it will not tell you which platform regressed, and it cannot tell you that someone is draining accounts through your API — because a client-side metric cannot see cross-account behavior, and an attacker hitting your endpoints is not going through your app at all. Crash reporting and release health are different questions, and most mobile teams own a tool for the first and nothing for the second.
So I build the second. Datadog dashboards that instrument the whole stack rather than the surfaces I own — client screens, the request traces behind them, and the backend service resources behind those — templated by environment, with volume, failure rate and p95 latency broken out per platform so Android and iOS are measured against each other rather than separately. Monitors with runbooks attached and alerts that route somewhere a human reads.
The judgment that matters most here is tier. A metric has to be emitted somewhere that can see the thing you are trying to detect. Abuse and fraud signals belong on the server’s order path, not in client analytics, and a security requirement built in the wrong tier produces dashboards that look healthy and catch nothing. Getting that call right is worth more than the dashboard.
Choosing what to build on is the other half of it. I have argued against putting release monitoring on New Relic while the contract behind it was being wound back to logs only — a monitoring stack you lose in six months is worse than the one you never built, because by then you have retired the alternative to make room for it. When nobody in the room could say which way that decision was going, I took the question to the person who actually owned the answer rather than let it settle by seniority, and what came back was written guidance for the whole organization instead of a verdict in one review thread.
Replicating myself
Two registers, and I use both deliberately.
Through artifacts. An architecture standard encodes my architectural judgment for every engineer in the organization. A review ruleset encodes my review judgment and applies it automatically, on every diff, whether or not I am in the room. Both reach much further than one-to-one mentoring does.
Through people. I mentor across platforms and levels — including leads on platforms I don’t own, where the work is walking someone through how a lead reasons about a problem rather than what to build. And I write tickets as scaffolding: decomposed one architectural layer at a time, in the order the architecture defines, so that someone new to the codebase learns the shape of the system by shipping through it. The outcome I look for is not the ticket landing. It is that person filing their own architecture-alignment work a month later, unprompted.
Writing and teaching
Author and editor at Kodeco (formerly raywenderlich.com), where I wrote the book Android App Distribution along with several tutorials, and served as Android topic master. Long-running technical blog on this site.
Interested in staff-level Android or iOS work.
