Dear your team,

I built this instead of a cover letter. I hope it gives you a better sense of how I think and what I'd bring to your team.

Learn more Let's talk

A bit about me

I'm a senior software engineer with six years of experience, no CS degree, and a background that goes through nursing, paralegal work, and a photo lab before landing in tech. I started with a bootcamp in 2020 and spent four years at Booz Allen Hamilton before going independent. I think like a designer and build like an engineer.

Things I've leveled up teams on

Design systems

Filling the gap

The team didn't have a designer. I took a night course through Booz Allen, got comfortable in Figma, acquired team licenses, and introduced Storybook as a living component reference. One person filling a gap turned into a workflow the whole team depended on.

Client engagement

Winning the room

Part of stakeholder review cycles from early wireframe through final demo. Built interactive prototypes polished enough that the work routinely beat competing proposals. Being in the room to present those decisions made a larger impact than any individual deliverable.

Code quality

Reviewing the code

Shaped how a team gave and received feedback on PRs — smaller diffs, comments that taught rather than blocked, and a test coverage baseline that caught issues early. The habit changed before any tooling did, and it was the habit that stuck.

What I'm looking for

The best frontend work happens where design and engineering aren't separate conversations. Where someone cares how a component feels in a screen reader and someone else cares why the border radius is 8 and not 12, and that level of care is just how the work gets done. That's the bar I hold myself to.

I bridge the gap between Figma and production that most teams never quite figure out how to staff. Accessibility isn't a checkbox I hand off. I own it from the component up. Someone who can contribute in a design review and a code review on the same day is harder to find than most job descriptions assume.

Reach me directly

How I work

You're looking at it! This page is the project and the explorer below is a peek under the hood.

Built with
  • Astro
  • TypeScript
  • Vercel
  • Lucide
  • Vitest
  • Shiki
  • ESLint
  • CSS Tokens
  • GitHub API
  • Lottie

Files worth reading

  • src/styles/global.css

    Every color, size, shadow, and radius lives here as a CSS custom property. Switching themes is one attribute change on <html> — no JavaScript ever touches a color value.

  • src/utils/github.ts

    The entire explorer was assembled at compile time. GitHub API during astro build, syntax highlighting via Astro's built-in <Code /> component, zero network calls at runtime. The test file next to it specifies exactly what the filtering and language-detection guarantees.

  • src/components/sections/HowIWork.astro

    This section. content-visibility: hidden defers paint until the section enters the viewport, then requestIdleCallback detects when the browser is actually idle — so the spinner shows for the real duration of browser work, not a fake timer.

  • src/utils/companyTargeting.ts

    One param, four fallback sources: ?to= query param → /for/ path segment → sessionStorage → localhost sentinel. Dependency injection throughout means every resolution path and DOM patch is unit-tested with no globals required.

View on GitHub →

How I choose a tech stack

Fast to ship, easy to hand off, boring where boring is correct.

Static first
If the content doesn't need a server, I don't use one. Astro is my default — it ships zero JavaScript unless I ask it to. Fast page loads, zero cold starts, no attack surface from a running process.
Reach for the platform
Native <dialog>, CSS scroll-snap, IntersectionObserver. If the browser can do it, I don't reach for a dependency. Less to update, less to audit, less to explain to the next developer.
Add a framework when the UI earns it
React when the interaction complexity justifies the bundle cost — not by default. I've shipped Astro with React islands for exactly two interactive pieces while everything else stayed zero-JS. That was the right call.
Accessibility is a constraint, not a checklist
WCAG 2.2 AA, keyboard navigation, visible focus styles, screen reader testing, prefers-reduced-motion — these get considered at the design stage, not bolted on at the end. I love a good animation. The focus ring comes first.
I can work both sides of the API
I'm most at home in the frontend but I don't stop at the component boundary. I've written endpoints, worked with row-level security, and debugged auth flows. I won't block a feature because the backend work is in scope.

How I use AI

I've built structured workflows around AI that produce consistent, reviewable output. The patterns here are the same ones I'd bring to any team.

The agent rules live in the repo

Reuse existing components, create design tokens, enforce WCAG. .github/copilot-instructions.md and component APIs. The AI works within the system, not around it.

Structured workflows

Spec → generate → agent review → validate (typecheck, lint, tests, build) → human review. Same sequence every time. Predictable output is the point.

PRDs before prompts

Every feature chunk starts with a written spec: scope, constraints, component reuse rules, acceptance criteria. The agent works from a document, not a vibe.

Multiple agents, one task

I run agents in parallel on different sub-tasks: one generating, one reviewing the contract, one checking accessibility. I treat them as a pipeline with distinct roles.

AI reviews first, I review after

Before I look at generated code, the agent reviews its own output against the spec. My pass is the senior-engineer layer: architecture, edge cases, things the agent can't "see".

I pick the right tool for the task

I work across the OpenAI and Anthropic APIs and treat model choice as a design constraint. I route tasks by context needs, reasoning depth, and failure patterns, with models handling different roles.