Selected work · Product to production

The visible product and the system beneath it.

Four examples of how I connect product direction, interface decisions, full-stack engineering, infrastructure, trust, and operating reality.

Discuss your product

01 / 04

Active betaCTO · Product · Platform

Micr

Building an integrated social gaming product while making its reliability, recovery, security, and operating cost measurable.

Role: CTO
Scope: Product direction, UX, architecture, and infrastructure
Stage: Active beta with product surfaces at different stages of release
Current focus: Reliability, recovery, observability, security, and operating cost

The context

Micr is being built to help players move from one-off matches into compatible squads and lasting communities. The product spans matchmaking, community, real-time communication, events, tournaments, creator experiences, and desktop surfaces. That breadth makes product decisions inseparable from the platform underneath them.

My work

I lead the decisions across the full system: what the product should do, how the experience holds together, where technical boundaries belong, how services fail and recover, and what the product can responsibly claim. The goal is not architecture for its own sake. It is a product that can become clearer, safer, more measurable, and more economical as it grows.

Define before claimingTurn broad scale language into concrete workloads, service objectives, recovery expectations, and evidence gates.
Design one productKeep matchmaking, communities, communication, events, and creator surfaces coherent instead of treating them as unrelated features.
Make operations visibleConnect observability, deployment, access control, and recovery work to actual product risk.
Include the economicsTreat variable infrastructure cost and support burden as product inputs, not surprises after launch.

Visit Micr Explore a platform readiness review

02 / 04

Live productProduct · UX · Full stack

ReadmeBio

Turning a link-in-bio page into an authored, living record of what a builder is shipping—without letting live data or deep customization take over the story.

Role: Product, UX, and full-stack engineering
Scope: Positioning, editor UX, integrations, publishing, analytics, billing, and deployment
Stage: Live product with free and Pro publishing paths
Core tension: Offer deep control and live proof without producing a noisy editor or a generic public page

The context

Traditional link-in-bio products reduce a person’s work to a row of destinations. Builders have a different problem: their credibility lives across repositories, launches, shipping cadence, product signals, and current work. Copying all of it into a static profile creates another page that goes stale. Importing everything without hierarchy creates a dashboard no one wants to read.

The product decision

I shaped ReadmeBio around a different model: a living README in which the person authors the narrative and connected sources support it with current proof. The product brings setup, modular composition, visual direction, preview, publishing, and insights into one system while keeping the public profile clean enough to feel intentional.

ConnectBring GitHub, X, Product Hunt, and adoption signals into structured profile material instead of copying updates by hand.
ComposeUse a starter flow and modular canvas to shape voice, hierarchy, blocks, and visual direction in one place.
PublishKeep drafts separate from the public profile, then release to a profile URL or verified custom domain when the page is ready.
LearnUse views, clicks, referrers, top blocks, and form submissions to understand what visitors actually use.

Author the identityLet the person decide what the page says and how it reads. Connected data should support the story, not replace it.
Separate draft from liveMake experimentation safe by keeping editing and variations away from the published page until an intentional release.
Reveal power progressivelyStart with a crisp setup path, then expose deeper block, design, domain, and analytics controls when they become useful.
Price the operating layerKeep publishing, themes, blocks, and core integrations free. Put custom domains, retained analytics, inbox, and exports in Pro.

Visit ReadmeBio Open a published profile

03 / 04

Live productProduct · UX · Full stack

Leadly

Turning fragmented household product-safety information into a calmer, source-linked path toward the next decision.

Role: Product and full-stack engineering
Scope: Product definition, UX, data presentation, and implementation
Stage: Live product
Constraint: High-trust information that must preserve its source and uncertainty

The context

Product recalls and safety information are public, but they are often distributed across sources and written for institutions rather than households. In a high-consequence category, simplifying the experience cannot mean hiding where information came from or overstating what the product knows.

My work

I shaped the product, experience, and full-stack implementation around a simple principle: help people understand what they found, preserve the path back to the underlying source, and make the next step clearer. The interface and the data model had to reinforce the same trust standard.

Preserve the evidenceKeep source context visible so a concise product experience does not become an unsupported claim.
Design for calmUse clear hierarchy and plain language to help users orient themselves without manufacturing certainty.
Connect the stackShape data, interface, and application behavior together instead of treating presentation as a final layer.
Clarify the next moveOrganize information around useful household decisions rather than the structure of the source system.

Visit Leadly Explore a new business launch plan

04 / 04

Live client platformBrand · Web · Operations

Crystal West Cleaning

Connecting the public brand and lead experience to the practical owner workflow that has to support every inquiry.

Role: Brand, web, and operating systems
Scope: Positioning, experience design, implementation, and lead flow
Stage: Live client platform
Constraint: A small operation needs clarity and maintainability more than unnecessary complexity

The context

For a local service business, the website is only the visible end of a larger operating flow. Positioning, service clarity, inquiries, and follow-up all have to fit the way the owner actually works. A polished front end that creates confusion behind the scenes is not a successful system.

My work

I developed the brand and web presence alongside the practical workflow behind it. The work focused on making the offer easier to understand, creating a direct path from interest to contact, and keeping the resulting system manageable for the business operating it.

Start with the offerMake services and customer fit understandable before adding visual or technical complexity.
Design the whole journeyConnect the public site, contact path, and follow-up workflow as one customer experience.
Build for the operatorChoose structure and tooling the business can realistically maintain after launch.
Keep proof honestDescribe the shipped system and responsibilities without inventing conversion or growth numbers.

Visit Crystal West Explore the local business website foundation

Evidence standard

No inflated numbers. No borrowed credit.

A case study should make responsibility and judgment visible. Where an outcome has not been independently measured or approved for publication, I describe the work, the constraint, and the decision instead of manufacturing a metric.

That same standard carries into client work: define the evidence first, build what can change the decision, and verify the critical path before calling it complete.

See how I work

The visible product and the system beneath it.

The context

My work

The context

The product decision

The context

My work

The context

My work

No inflated numbers. No borrowed credit.

Let’s make the next move clear and make the system hold up underneath it.