Building software ecosystems — not just apps.
Most software starts as an application. I usually end up building three things instead:
📱 the product people use · 📦 the reusable packages behind it · 🛠️ the tooling that makes the next feature faster
Shipping enterprise Flutter software in production reinforced a simple lesson: software succeeds because it's maintainable — not because it shipped one more feature. That philosophy shapes everything below: clean architecture, reusable components, automated quality gates, and developer experience treated as a product surface, not an afterthought.
Each project exists because a real problem surfaced while building the one before it — this isn't a portfolio of unrelated repos, it's a compounding system.
Building enterprise document software exposed localization gaps → maintaining shared packages demanded better tooling → managing AI-assisted workflows led to AI Tray, brain.md, and agentic templates → those same principles now power everything I ship next.
| Project | Purpose | Stack |
|---|---|---|
| Document Platform | Modular Flutter document-editing monorepo — schema, transactions, codecs, embeddable packages | Flutter · Clean Architecture · Modular Packages |
| AI Tray | Menu-bar / system-tray companion that tracks Claude Code and GitHub Copilot usage (session & weekly rings, provider health). v1.3.3, multi-provider architecture, macOS arm64 supported | Flutter Desktop · Provider Platform · Riverpod |
| Localization analyzer | Catches localization bugs while coding: hardcoded strings, missing / duplicate / unused ARB keys. Pure-Dart engine, CLI-first, CI gate, DevTools console, baseline so old debt is tolerated and new debt fails | Dart Analyzer · Custom Lint · CLI · DevTools |
| platform-ci | Reusable, config-driven GitHub Actions for Flutter/Dart — apps, Melos monorepos, packages, CLI, web, desktop, mobile, Firebase, Pages, pub.dev | GitHub Actions · CI/CD · Automation |
| agentic_flutter_template | AI-first Flutter monorepo template — feature-first Clean Architecture, Melos, modular CI, and agent workflows baked in | Flutter · Claude Code · Agent Architecture |
| brain.md | Open, agent-agnostic standard + zero-dependency CLI that gives coding agents a persistent, repo-resident memory in plain Markdown | CLI · Markdown · Agent tooling |
| g | Small CLI that wraps git/GitHub for the sequences I repeat daily (branch from a ticket key, conventional commit) — native git stays the escape hatch |
CLI · Git |
| MacOrganizer | Native macOS utility to declutter Downloads/Desktop without ever permanently deleting anything; ported from a Python prototype | Swift · SwiftUI · CI |
| design_theme | Material 3 tokens, ThemeData adapters and composite widget themes with a live playground | Flutter · Design System |
| Phone Repair | Multi-role repair platform (customer, shop, admin) from one Flutter codebase across mobile, web and desktop; ADR-driven, auth in place | Flutter · go_router · ADRs |
| CELPIP Workspace | Cross-platform exam-prep workspace built around structured practice and progress tracking | Flutter · Riverpod · go_router · Supabase |
More experiments
- custom-navigation-voice-generator — benchmark of open-source TTS engines on Nepali / English navigation instructions, toward personalized Waze voices
- go-backend-learning — real code, tests and commits documenting my move from Flutter into production Go
- roshan_portfolio · rsprojects-showcase — portfolio and project showcase sites
- semantics_coverage — Flutter accessibility-semantics coverage experiment
Hardcoded strings ship to French users as English forever, until QA or a customer notices. The defect is static, so an analyzer can see it. One engine, three consumers:
The baseline is the adoption trick: existing debt is recorded and allowed, so the gate can go live on a legacy codebase on day one and only new violations fail.
One diagram per project, each showing the mechanism rather than the name. Expand what interests you.
AI Tray — usage rings for Claude Code and Copilot in the menu bar
Provider adapters turn CLI output (Claude) and an SDK sidecar (Copilot, experimental) into validated usage; a repository caches it and notifiers drive the rings. Sessions are read straight from ~/.claude/projects, and queued resumes require a budget cap.
MacOrganizer — native SwiftUI declutter tool that never deletes
A thin SwiftUI shell over OrganizerCore, a SwiftPM engine tested without Xcode (57 tests). Every move goes to Trash and is journaled by device and inode, which is what makes a whole run undoable.
Phone Repair — one Flutter codebase for customer, shop and admin
Session-aware routing, Riverpod controllers, repository interfaces, Supabase behind them, and ADRs for each foundational call. Auth and the identity schema are in; the product workflows are still pending.
agentic_flutter_template — monorepo where AI instructions have one home
Feature-first Clean Architecture with packages/ and pluggable modules/. Claude Code, Cursor and Copilot files are thin pointers to a single .ai/AGENTS.md.
Localization analyzer — localization defects found while coding
One pure-Dart engine feeds a CLI and CI gate, a localhost server for a DevTools console, and a planned lint rule. A baseline lets the gate go live on legacy code.
platform-ci — reusable GitHub Actions for Flutter and Dart
Consumers describe intent in ci.yaml and pin @v1. Only quality runs by default; builds, releases, deploys and pub.dev publishing are opt-in.
semantics_coverage — find widgets automation cannot address
A fast static scan and a runtime semantics-tree scan feed one coverage number, a CI gate, and chunked task lists sized so an agent never needs the whole app in context.
design_theme — one theme object for Material 3 apps
A seed colour builds light and dark DesignTheme tokens, adapted to ThemeData and shared with composite widgets through DesignTheme.of(context). A switcher overrides it per subtree.
g — a Git workflow CLI in Go
Wraps the installed git instead of reimplementing it: ticket-keyed branch names, conventional commit messages, short output. Native git stays the escape hatch.
log-time — weekly time logging through a local web page
Claude fetches issue-tracker and calendar data, a localhost-only server renders a week grid, and request files hand Refresh and Submit clicks back to Claude. Nothing posts until you submit.
TTS benchmark — choosing a Nepali navigation voice engine
A standard phrase corpus runs through swappable engine adapters. Missing engines are skipped and recorded instead of blocking the run, and each result captures timing, audio info and errors.
brain.md — repo-resident memory for coding agents
Project showcase — a registry-driven portal for every product
Each product repo stays the source of truth. An integration definition is validated and compiled into a registry the Flutter Web showcase renders, and platform-ci publishes private playgrounds into it.
Portfolio site — React 19, Vite and Firebase
Terminal-first hero, GitHub metrics synced daily as static JSON, a command palette and a hidden /terminal. Push to main deploys; every PR gets a preview channel.
Go backend (in progress) — real-time chat as the learning target
|
|
|
Also in the toolbox: Bloc/Provider/GetX · TypeScript · React · Vite · Tailwind · Laravel · Hive/Isar/Sqflite · Codemagic/Jenkins · Figma · TTS / audio experiments
| Capability | Signal |
|---|---|
| Enterprise Flutter delivery | Production enterprise features — workflow-heavy screens, document handling, deep linking — shipped against tracked stories |
| Existing-codebase investigation | Tracing features across routing, auth, and data-loading layers of a live production app into accurate, ship-ready feasibility plans |
| Shared UI & package extraction | Reusable Flutter component packages (shared UI kits, design_theme) — fields, pickers, dropzones, document chrome, theme tokens — reused across multiple products |
| Localization systems | End-to-end tooling: ARB/l10n at scale, static analysis, custom lints, baseline-aware CI validation — not just string replacement |
| Developer platform engineering | Config-driven, reusable CI (platform-ci), Melos monorepos, small CLIs (g), and a multi-agent Claude Code architecture reused across many repos |
| AI-assisted engineering | Agents as part of the delivery loop, not a shortcut — capability-bound tooling that refuses to assume unverified integrations, plus persistent agent memory (brain.md) |
| Native & desktop apps | Flutter Desktop (AI Tray) and native SwiftUI (MacOrganizer) utilities that respect platform conventions |
A workflow I run with Claude and Jira. The coordinator reads the ticket and only routes; specialist agents do the work; review can bounce it back; every agent reads one shared skill set.
Agent sessions forget; brain.md is the fix. Decisions go through a small CLI into Markdown in the repo, so the next session, even from a different agent, resumes with context.
- Localization analyzer reached "MVP trusted" (2026-07-10) after a CLI-first pivot, with CI and ADRs
- AI Tray at v1.3.3 with a provider-platform architecture supporting two AI vendors, ~120 commits
- platform-ci released as versioned reusable workflows covering every Flutter target plus pub.dev
- Multi-agent Claude Code system (coordinator + 5 specialists, one shared skill set) reused across many repos
- Shipped a native SwiftUI app from a Python prototype, with CI, in a language outside my main stack
Build for maintainability
↓
Prefer reusable systems over one-off solutions
↓
Keep architecture explicit
↓
Automate repetitive engineering work
↓
Test what matters
↓
Document decisions, not just implementation
↓
Treat developer experience as part of product quality
flowchart LR
A[Feature delivery] --> B[Extract shared systems]
B --> C[Automate with CI / tooling]
C --> D[Encode in agent workflows]
D --> A
Primary — Cross-Platform Software Engineer: Flutter · shared UI systems · developer tooling
Alternative framings
- Enterprise Flutter Engineer — workflow-heavy business apps, shared UI systems
- Flutter Platform & DX Engineer — packages, localization tooling, CI
- Developer-tools Engineer — analyzers, CLIs, agent infrastructure
- Product-minded Flutter Engineer — desktop companions & document platforms
- Cross-platform Engineer in transition toward backend & systems ownership (Go, PostgreSQL)
Expanding from strong Flutter client/platform work into backend engineering (Go, PostgreSQL, Docker) and deeper systems ownership — not abandoning Flutter, but building the ability to own a product end-to-end: client, backend, infrastructure, tooling, and delivery.
The concrete target is a real-time chat backend, learned through a challenge ladder from "connect Flutter to Go" up to "run two servers behind Redis and survive killing one":
🚴 Cycling · 🍳 Cooking · 🌍 Traveling · 🎧 Music · 📖 Reading about architecture & systems design