Work

greatRPC is my answer to an everyday developer pain point: tooling around gRPC is often powerful, but rarely pleasant. The goal was to build something fast, native, and trustworthy enough to live on an engineer’s desktop every day.

The product leans on a Rust core for protocol-heavy work and SwiftUI for a polished Apple-platform experience. That split keeps the UX lightweight without compromising on protocol support or performance.

I built and maintain the package to give Flutter teams a production-ready path to Apple’s authentication flow without hand-rolling native integrations. Over time it became one of the better-known authentication packages in the ecosystem.

The server counterpart exists because authentication is never just a button. The value is in helping teams bridge app, backend, and identity-provider concerns cleanly.

Passkeys are a better user experience than passwords, but they still need careful backend plumbing. This package focuses on the server side of that equation so teams can implement passkeys without starting from protocol details.

This package grew out of a practical need: keep application state manageable without turning every feature into hand-written indexing and retrieval logic. It is part of a broader interest in helping teams scale codebases, not just screens.

state_queue is a tool for situations where simple reactive updates stop being simple. It helps make sequencing explicit so teams can reason about transitions, test them, and avoid subtle UI race conditions.

My work with Serverpod focused on the parts of a framework that affect real teams most: migrations that behave well under edge cases, protocol support that removes friction, and authentication flows that can evolve without breaking existing users.

This engagement combined architecture, delivery, and product quality work. The challenge was not simply building features, but creating a system and team setup that could ship faster without making the app less stable.

That meant introducing better patterns around state, service communication, and release confidence while helping the organization move toward a more scalable Flutter foundation.

The focus here was velocity without chaos. By leaning into shared foundations, generated APIs, and a cleaner navigation model, the app team could move quickly while keeping implementation details understandable.

TELESON needed more than a simple port. The work involved bringing together business logic, local storage, and dependable sync so users could continue working even in poor connectivity conditions.

That balance of product requirements and engineering discipline is where I tend to be most useful.

This work centered on systematizing product delivery. Instead of treating each app variant as a one-off, the goal was to build a shared component and behavior model that could flex for many customers without losing consistency.