Problems dictate the architecture, not my comfort zone.

Mobile work is a product boundary as much as a platform choice. I work through application architecture, user-facing state, local persistence, background work, device capabilities, permission boundaries, and offline behavior.

• Android application architecture
• Jetpack Compose and user-facing state
• Local persistence and background scheduling
• Permission minimization and device boundaries

Project exampleIT’S SO OVER is a useful example of Android product boundaries: permissioned device signals become behavioral context on-device, while the product remains useful without a behavioral backend or runtime AI dependency. The difficult part is not collecting more data. It is extracting only the context that meaningfully changes product behavior while keeping permissions, privacy, and interruption under control.

Backend systems carry contracts, persistence, state ownership, asynchronous workflows, authentication, failure boundaries, and the evidence needed to understand them in production.

• Java and Spring Boot
• PostgreSQL, Redis, and Flyway
• Streaming and SSE
• API contracts, failures, and observability

Project exampleOrchestrAI explored provider and model orchestration through a production-minded backend. The product was archived, but the work remains a useful example of clear provider boundaries, streaming, persistence, and deliberate failure behavior.

Local software and background services need explicit ownership of processes, resources, lifecycle, recovery, and failure. Linux is part of the product surface when the work lives on the user’s machine.

• Linux and Rust
• Process orchestration and systemd
• Resource-aware execution
• Background services and recovery

Project exampleGeoCall is a small example: local scheduling, SQLite, and systemd turn a repeated manual check into a focused private automation without pretending it is a larger product.

Media systems make resource constraints and long-running operations impossible to ignore. Non-destructive state, local processing, progress, cancellation, and deterministic execution matter because the user’s source material matters.

• FFmpeg and local processing
• Non-destructive project state
• Long-running operations
• Desktop and resource constraints

Project exampleEDIP uses AI to understand editorial intent, while validated plans become deterministic local media operations. The interesting problem is not merely using AI; it is making revision understandable and execution dependable.

AI is one mechanism among others. LLM APIs, provider and model orchestration, and tools such as Codex, Claude, and Gemini can accelerate investigation and implementation, but they do not replace product judgement.

• LLM APIs
• Provider and model orchestration
• AI-assisted engineering workflows
• Judgement remains accountable

Project exampleThe question stays the same: does the mechanism improve the product, preserve clear boundaries, and give the person using it a result they can understand and control?