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.

A bit about me

I'm a frontend 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

Async-friendly teams that trust engineers to manage their own time. A design bar that people actually care about — not just "it works on mobile." Work that has a point to it, even if that point is just making a useful thing really well.

Fast-moving without being chaotic: opinionated enough to make decisions, humble enough to revisit them. I want to work somewhere that treats accessibility and code quality as defaults, not debt to pay down later.

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.

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 use AI as a tool to augment my work, not as a shortcut. It's a teammate that can handle rote tasks and generate first drafts, but it doesn't replace the need for human judgment and creativity.

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

Claude for planning and designing, ChatGPT for logic and debugging. I use Copilot Pro+ for model access so I'm always working with current frontier models.