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
Selected technical work
Selected sites and applications showing how I plan, build, test, and deploy different web projects.
Individual website
A static personal site with a clear identity, responsive reading flow, and maintainable Svelte structure.
Business application
A commerce platform using a full-stack monorepo for the public site, catalog, admin, API, contact service, database, and shared code.
Entertainment project
A browser game exploring interaction design, changing rules, responsive game state, and creative frontend work.
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.
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.
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.