I build quiet software for the loud parts of life.

Selected work · native, private, useful

Built where friction gets personal

I keep returning to everyday problems that ask for quieter software: capturing a thought before it disappears, or understanding money without turning life into a dashboard.

Two products. One standard: earn the trust.

Voice · macOS

ZenVoice

Thought moves fast. The interface should keep up.

  • Private alpha
  • Native macOS
  • Local transcription

ZenVoice is a native macOS dictation workspace that keeps transcription on the Mac. I’m building it for the moments when typing becomes the bottleneck: a message, a journal entry, a line of code, or a thought that will disappear if the software makes you wait.

  • Swift
  • SwiftUI
  • AppKit
  • AVFoundation
  • SQLite

A small proof of the rhythm ↓

Voice, captured liveReady
Tap the waveform to dictate

Personal finance · iOS

ZenPense

A calmer relationship with the numbers that follow you.

  • In development
  • Native iOS
  • Local-first

ZenPense is a local-first iPhone finance app designed to make money feel legible, not loud. Expenses, budgets, goals, subscriptions, and reports live in one deliberate system—private by default and useful even before the cloud enters the picture.

  • Swift
  • SwiftUI
  • SwiftData
  • Observation
  • Supabase

Watch the noise find its place ↓

Spending, sorted liveReady

Type an expense to watch ZenPense place it.

Flexible budget64% left

Local demo rules recognise common groceries, transport, dining, and subscription words.

Technology stack · used, not collected

The tools behind the work

I choose technology by what the product needs: native where the platform matters, local where privacy matters, and web where reach matters.

A record of use—not a wall of logos.

Languages

The foundations I reach for across native, web, and systems work.

  • Swift
  • TypeScript
  • Python
  • Kotlin
  • JavaScript
  • Java
  • C

Frameworks & data

The structures that turn an interface into a working product.

  • SwiftUI
  • React
  • Next.js
  • Node.js
  • Electron
  • Jetpack Compose
  • PostgreSQL
  • Supabase
  • Firebase
  • Deno

Tools & platforms

Where I design, build, version, test, and ship the work.

  • Xcode
  • Android Studio
  • Git
  • GitHub
  • VS Code
  • Figma
  • Railway
  • Cloudflare
  • Resend
  • Stripe
  • StoreKit

AI workflow

Fast hands for development—without outsourcing judgment.

  • Claude Code
  • OpenAI Codex
  • Ollama

Right tool. Right trade-off.

The person behind the products

The story behind the software

This is not the heroic version. It is the useful one: curiosity came first, projects made the lessons real, and the direction became clearer by building.

Not a résumé. A trail.

The question

I noticed software before I knew how to make it. Some tools respected my attention; others spent it carelessly. I wanted to understand who made those choices—and eventually become the person making them.

The method

I stopped waiting to feel ready. C and Java gave me foundations through BCA. Swift, SwiftUI, web work, and a long trail of broken builds gave those foundations consequence. I learn fastest when a real product pushes back.

The direction

I’m building toward software that feels personal without becoming invasive. That means native experiences, local-first data, and AI that works as a capable tool—not an excuse to surrender judgment. The technology can be ambitious; the experience should stay calm.

A working compass

How I think when the path gets steep

These are not slogans I put above the desk. They are the tests I use when scope expands, the build gets messy, or a new tool makes the wrong thing look easy.

Principles should survive contact with the work.

  1. Start with lived friction.

    The best ideas begin as a repeated interruption in real life, not a feature looking for a reason.

  2. Build one useful thing.

    Scope is a design material. A smaller promise, kept completely, beats a larger one that only demos well.

  3. Keep personal data close.

    If software knows something private, ownership and control should be structural—not a line in the settings.

  4. Let tools be tools.

    Agents can move fast. Architecture, judgment, review, and accountability still belong to the person shipping.

  5. Make calm earn trust.

    Less on screen only works when the hierarchy is stronger. Quiet software should still explain itself.

  6. Verify the claim.

    If I cannot show that something works, I call it an experiment. Honest edges make the finished work stronger.

Learning in public, building in private

The road so far

There was no single leap from student to builder. Each phase changed the question: from how software works, to how it feels, to what it owes the person using it.

No heroic timeline. Just better questions.

  • Before codeNoticing the choices

    Curiosity about interfaces came first: why one tool feels effortless and another keeps getting in the way.

  • FoundationsLearning the grammar

    BCA coursework brought C and Java. Small web projects taught me what consequences feel like.

  • Going nativeFinding a home platform

    Swift and SwiftUI raised the bar: software should feel at home on the device and useful without the network.

  • Building nowProducts become teachers

    ZenPense and ZenVoice turn isolated skills into systems with migrations, edge cases, privacy, and release discipline.

  • NextDeeper, not louder

    Finish what is in motion, go further in native engineering, and make agent workflows hold up beyond the demo.