Selected technical work

Web development projects and case studies

Selected sites and applications showing how I plan, build, test, and deploy different web projects.

Featured projects

01

Individual website

Butter's Personal Website

A static personal site with a clear identity, responsive reading flow, and maintainable Svelte structure.

  • Svelte
  • TypeScript
  • Tailwind CSS
  • Static deployment
02

Business application

NRG Commerce

A commerce platform using a full-stack monorepo for the public site, catalog, admin, API, contact service, database, and shared code.

  • SvelteKit
  • TypeScript
  • PostgreSQL
  • pnpm workspace
  • Cloudflare
03

Entertainment project

EvoSnake

A browser game exploring interaction design, changing rules, responsive game state, and creative frontend work.

  • Vue
  • TypeScript
  • Tailwind CSS
  • Responsive design

How to read these case studies

Each case separates context, responsibilities, implementation choices, constraints, and verified evidence. Butter is collaborative work for another person; NRG Commerce and EvoSnake are independent product projects. That distinction matters because a public implementation can demonstrate engineering decisions without implying a paid client relationship or business outcome.

Screenshots show visible interface states, while repository and live links provide further inspection where available. Technical descriptions stay within what the source and public behavior support. No case uses invented traffic, revenue, conversion, testimonial, or adoption claims.

Match evidence to the work you need

Butter is the closest reference for a focused marketing or personal presence with supplied content and static delivery. NRG Commerce demonstrates a larger business and full-stack structure with several deployable surfaces, shared contracts, a database, and operational boundaries. EvoSnake demonstrates interaction-heavy frontend state, responsive controls, dialogs, event rules, and a leaderboard flow.

A case study is not a promise that a new project should copy the same stack. It is evidence of how decisions are made under a particular set of constraints. A proposal should start from your audience, content, workflow, ownership, and maintenance needs, then select the smallest architecture that responsibly supports them.

Why the technical decisions are documented

A portfolio screenshot can show polish, but it cannot explain why the code is organized a certain way, which constraints shaped the result, or how failures are handled. The written cases therefore identify scope, role, content boundaries, architecture, and tradeoffs alongside the visible interface. This makes the evidence useful when comparing a visually simple site with a system that has several applications and data responsibilities.

The same evidence-first approach applies to limitations. Static delivery is valuable when content and interactions permit it, not a universal answer. A monorepo can keep shared contracts coherent, but adds workspace and deployment coordination. An interaction-heavy game can demonstrate state modeling without proving business-system security. Naming these limits is part of showing sound judgment.