About

I build software with the assumption that someone will maintain it in two years. That someone might be me.

How I Got Here

My first real project taught me more through failure than success. Building a dashboard that broke under real user load, I learned that clever abstractions collapse under production constraints. That lesson stuck: what survives isn't what impresses—it's what works when things go wrong.

Working on accessibility audits for a large application changed how I design. The constraint of WCAG compliance didn't limit creativity—it forced better decisions. Keyboard navigation improved the UX for everyone. Semantic HTML made the code easier to maintain. Constraints became features, not obstacles.

I stopped chasing the newest frameworks around 2020. Not because they're bad—because constantly rewriting working systems wastes time that could go toward solving actual problems. That meant saying no to resume-driven development, but yes to building on proven foundations. Boring technology gives you time to focus on interesting problems.

Today, I focus on design systems and accessible architecture. Not because it's trendy—because these problems compound. A good component library pays dividends for years. An accessible foundation serves everyone. The work changed, but the principles didn't: build for the long term, optimize for maintenance, serve humans first.

What I Believe

The principles that guide my work

Software is for humans first

If it's not accessible, it's not finished. If it's not maintainable, it's not done. The best code serves people, not the other way around.

Boring is good

Proven technologies over shiny frameworks. Stability over novelty. I'd rather build on PostgreSQL than the database that launched last month.

Simplicity compounds

The best code is code that doesn't exist. The second best is code that's easy to delete. Clear code ships. Clever code impresses. I optimize for understanding.

Constraints are features

Accessibility constraints make better UIs. Performance budgets make faster apps. Type systems prevent bugs. Good constraints don't limit—they guide.

Long-term thinking compounds

Every shortcut costs interest. Every quick fix becomes debt. I optimize for the developer who inherits this in 2028—that developer might be me.

Systems over heroics

One person can't scale. Good systems can. I build processes that work without me, documentation that survives me.

Decisions I Care About

How I think when trade-offs matter

Why accessibility is non-negotiable

It's not a feature to add later. It's a design constraint that makes everything better. If I can't build it accessibly, I don't build it. This isn't idealism—it's good engineering.

Why I prefer boring technology

New tech has unknown failure modes. Proven tech has documented failure modes. I'd rather know my risks than discover them in production at 2am. Boring is reliable. Reliable ships.

When I say no to a project

If you need it "done yesterday" regardless of quality, I'm not your person. If accessibility is negotiable, we're not aligned. If you want impressive over effective, find someone else.

How I decide when NOT to build

The best code is no code. Before building, I ask: Can we buy it? Can we configure it? Can we eliminate the need entirely? Building is expensive. Not building is often correct.

What I'm Good At

Capabilities, not keywords

Building Accessible Systems

I don't bolt accessibility on—I design with it from day one. WCAG 2.1 AA is a baseline, not a goal. I've built component libraries, audited applications, and trained teams on inclusive design.

ARIA Semantic HTML Keyboard Navigation Screen Readers

Designing for Scale

Not just performance—architectural scale. Systems that survive 10x growth. Database schemas that handle evolution. APIs that version gracefully. Infrastructure that doesn't wake you up at night.

PostgreSQL Redis Caching Strategies API Design

Frontend Architecture

Component systems teams can understand. State management that doesn't require a PhD. Build processes that don't break on Tuesdays. Design systems that scale across products.

React TypeScript Astro Design Systems

Writing for Developers

Documentation people actually read. Error messages that help instead of confuse. Code comments that explain 'why', not 'what'. Onboarding materials that get people productive fast.

Technical Writing API Documentation Onboarding Docs Style Guides

How I Approach Work

Phase 1: Understand

What problem are we really solving? Who is this for? What constraints will make this better?

Tools:

User research, requirement docs, constraint lists

Phase 2: Build

What's the simplest thing that could work? How do I make this obvious to future developers? What can I delete before shipping?

Tools:

TypeScript, testing, accessibility audits, code review

Phase 3: Sustain

How will we know if this works? What documentation saves us time later? What did we learn? What would we change?

Tools:

Monitoring, user feedback, retrospectives

What I'm Doing Now

Updated: January 2025

Current Work:

I'm working independently on design systems and accessible web applications. Day-to-day: building production-ready component libraries. The interesting problem right now: making accessibility the default path, not the opt-in feature.

Current Learning:

Exploring modern CSS features (container queries, :has() selector) for component-scoped responsiveness. Not because it's trendy—because it solves the "component doesn't know its context" problem. Also deepening: performance optimization and Core Web Vitals.

Current Writing:

Thinking about constraints as design tools, boring technology choices, and building for maintainability. Recent topics: accessibility-first development, design system architecture. If you're interested in any of these, let's talk.

Not Doing:

Not chasing: the latest JavaScript framework, blockchain/Web3 hype, AI-generated code without review. Not interested in: rush jobs, accessibility as "nice to have", projects that prioritize impressive over effective. Work best on: long-term systems, accessibility-focused projects, developer tooling.

Beyond the Code

What I Read

Technical books, philosophy, fiction. Good engineers read widely. Current: design patterns, systems thinking.

What I Build for Fun

Side projects exploring new web APIs. Experiments with accessibility patterns. Developer tools that scratch my own itches.

What I Value

Outside work: learning, teaching, quiet focus. I believe diverse inputs create better outputs.

Let's Work Together

Alignment matters more than experience

I'm a Good Fit If...

✓ You care about accessibility and inclusion

✓ You value maintainability over quick wins

✓ You want systems, not band-aids

✓ You appreciate documentation and knowledge transfer

✓ You're building for the long term

✓ You respect constraints and user needs

I'm Probably Not a Good Fit If...

✗ You need it "done yesterday" regardless of quality

✗ You think accessibility is optional or "nice to have"

✗ You prioritize impressive over effective

✗ You don't value testing or documentation

✗ You're chasing hype over substance

✗ You want heroics over sustainable processes

Get in Touch

I'm currently available for select projects and collaborations.

Best Ways to Reach Me:

→ Email: your.email@example.com (I reply within 24-48 hours)

→ GitHub: @yourusername (where I build in public)

→ LinkedIn: yourprofile (for professional connections)

Before You Reach Out:

→ Check my projects: /tools

→ Read my thinking: /blog

→ Review this page for alignment

I'm Interested In:

→ Building accessible design systems

→ Architectural challenges in frontend systems

→ Developer tooling and documentation

→ Long-term collaborations with aligned teams

I'm NOT Interested In:

→ Cold recruitment without context

→ Rush jobs without proper planning

→ Projects where accessibility is negotiable

→ Blockchain/crypto/Web3 projects