Dear your team,

I built this instead of recording a video. I hope this gives you a better sense of who I am and what I can 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

About the video ask

I don't perform well talking to myself on camera. I perform better in actual conversations.

If you want to see how I think, let's get on a call and I'll walk you through anything here live. I'll bring the same preparation I brought to building this, and you'll get a much better read on whether we'd work well together than a screen recording would.

The same goes for live whiteboard and algorithmic interviews. I don't have a CS degree, and live-coding under observation doesn't reflect how I actually think through problems. Take-home exercises give you a real sample of my work.

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.

  • docs/prd/PRD-08-runtime-company-name.md

    A PRD written before a single line of implementation. The security section — why .textContent instead of .innerHTML, why inline not deferred — shows the kind of reasoning that usually only surfaces in code review, not planning docs.

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
Comfortable with Supabase, row-level security, OAuth flows, and writing endpoints — not just consuming them. TanStack Query when the frontend needs to cache and share that data. I'm not a backend engineer by title, but I won't block on one for a fetch call.

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
Agent constraints — reuse existing components, use design tokens, enforce WCAG, never hard-code colors — are written into .github/copilot-instructions.md and component APIs. The AI works within the system, not around it.
Structured workflows, not ad-hoc prompts
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. This is why AI-generated code in this project matches the design system instead of working around it.
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".

Before I write a line of code

My setup checklist runs before the first commit — whether I'm starting something new or joining an existing codebase.

Every project

Lint

Hard blocks, not warnings. If it can be caught statically, it gets caught before it ships.

Typecheck

TypeScript strict mode throughout. I'd rather fight the compiler for ten minutes than debug a runtime null at 11pm.

Agent rules

Reusable components (theme tokens, accessibility, keyboard nav), defined in Copilot instructions and PRDs.

Team projects

Prettier + ESLint

Consistent formatting is about eliminating noisy format-diff PRs in code review so the actual logic gets the attention.

Husky pre-commit hooks

Everyone codes however they want. The hook cleans it before it hits the branch. No config policing, no "can you just run prettier" comments in review.

Git hygiene

Atomic commits, useful messages, rebase on main before the PR. I review MRs with actual feedback and don't panic at a merge conflict.