Senior Full Stack Software Engineer

I design software around how people actually work.

This is an engineering knowledge base about business analysis, workflow modelling, architecture and the decisions that turn ambiguous human processes into production software. The repository is the product; the website is one renderer.

Explore How I Think →Experience Projects

Software follows the workflow

flowchart LR
  A[Human workflow] --> B[Business story]
  B --> C[Actors]
  C --> D[Data objects]
  D --> E[External systems]
  E --> F[Architecture]
  F --> G[Technology]

Chapters

A knowledge base designed to age slowly.

The structure is intentionally simple: durable chapters, case studies, decisions and notes that can keep accumulating for years without changing the shape of the product.

How I Think

The operating philosophy: listen, model workflows, then choose architecture.

Projects

Production work explained as miniature books: workflow, architecture, decisions and lessons.

Decision Journal

Architecture records that preserve context, alternatives, tradeoffs and outcomes.

Writing

Long-form engineering notes that can eventually become chapters in a book.

Experience

Career history as production case evidence, not resume bullets.

Models

Reusable workflow, permission and architecture models.

Listen before designing

Founders and operators often reveal the real system in the order they tell the story. Interrupting too early can erase the hidden constraints.

Model the workflow

Actors, data objects, permissions, external systems and exceptions come before components, frameworks and deployment choices.

Choose architecture pragmatically

Firebase, Cloud Run, Astro, serverless functions or a traditional backend are decisions, not identities. The project decides.

Design for trust

Performance, accessibility, typography and interaction details shape whether users believe the system understands their work.

Evidence

Projects are supporting chapters.

The point is not a gallery of screens. The point is how the business problem became a model, how the model became architecture, and how the architecture changed when reality pushed back.

Public event platform

DeFi Connect 2025 Event Platform

↗

A unified public platform for five concurrent summits in Buenos Aires, built for Party Action People under a compressed September to November 2025 delivery window.

Event platform architecture

flowchart TD
  Sessionboard[Sessionboard] --> API[Content ingestion / API layer]
  API --> Data[Normalized event data]
  Data --> Components[Shared Next.js components]
  Components --> Summits[Summit-specific pages]
  Components --> Agenda[Agenda, speaker and session views]
  Ticketing[Ticketing platform] --> CTA[External ticket CTA]

Event operations

EthCC Conference Platform

↗

Conference software for EthCC operations at serious scale: 1,200 applications, 6,500 attendees, 400+ speakers and a 30-person team coordinating content, schedules and publishing.

Multi-event evolution

flowchart TD
  A[Single event] --> B[Multiple events]
  B --> C[Teams]
  C --> D[Organizations]
  D --> E[Permissions]
  E --> F[Reusable platform]