Web Design & Development That Delivers.

Overview

A website for a community dog sanctuary: a real organization that needed a practical web presence. I designed and built the full site, including a video hero, donation call-to-action, volunteer sign-up, and regulation pages.

The Problem

The sanctuary's visitors arrive with very different goals. Donors want a quick way to give, volunteers want to sign up, and visitors need the rules before bringing a dog. All of that has to live on one site without the important-but-dry information burying the emotional appeal that motivates donations.

My Approach

I started from visitor intent rather than from a layout. Most arrivals want to do one of three things: donate, volunteer, or plan a visit. I organized the content around those paths and led with a video hero to communicate the sanctuary's atmosphere immediately.

Design & Development Decisions

• Used a full-width video hero for immediate emotional connection, with overlay treatment to keep text legible over motion.
• Gave the donation call-to-action prominent placement so it is never more than a glance away.
• Separated volunteer sign-up and regulation details into their own sections so essential information stays findable without cluttering the main message.
• Built the layout responsive so the site works for the many visitors who will first open it on a phone.

Challenges & Solutions

The main challenge was balance: lead with feeling, but keep practical information one click away. I solved it with hierarchy. The hero and donation path carry the visual weight, while sign-up and regulation content is clearly signposted rather than competing for attention. Keeping text readable over a moving video background also took deliberate work with overlays and type contrast.

Result

A complete, deployed website that serves the organization's real needs: it tells the sanctuary's story and gives every type of visitor a clear next step. It shows I can design around user goals and business needs, not just aesthetics.

What I Learned

Designing for multiple audiences on one site, organizing content by visitor intent, working with video backgrounds responsibly, and taking a real-world project from blank page to deployed site.

1. Project Overview

This is a real client project, not a school assignment. A professor recommended me to another web development professor who helps run an IEEE-affiliated student organization. The organization needed a website it couldn't build on the school's existing page, so I'm designing and developing a dedicated, standalone site for them. My role covers the full development process.

Status: the project is in development and approaching its initial launch. The core website is being finalized and prepared for deployment.

2. The Problem

The school would not allow the organization to add the website functionality it needed to the school's existing website. As a result, the organization had no dedicated web presence, and students had no single place to find information about the club, its events, and the resources it offers. The organization needed an independent site it could control and grow.

3. Goals

• Create a dedicated online presence for the organization, independent of the school's site.
• Make it easy for students to learn about the organization and find what they need.
• Organize upcoming and past events in one place.
• Centralize useful student resources and important information.
• Deliver a professional, responsive website that works across devices and is maintainable as content grows.

4. My Role

I am responsible for the website's full build. That includes the web design, page structure, information organization, responsive implementation, and building the site in HTML, CSS, and JavaScript. I also handle content implementation and incorporate the client's revisions as we prepare the site for deployment. The client provides the organization's content, requirements, and feedback; the design decisions and the build are my work.

5. Design Process

I approached the design by starting from what students need to do, then organizing the site around those tasks. Because the content spans events, past activities, and resources, I chose a multi-page structure so each area has a clear, findable home rather than crowding everything onto one page. Navigation and information hierarchy were the priority: a student should be able to tell at a glance where upcoming events, past events, and resources live. I kept the visual treatment consistent across pages so the site reads as one cohesive product, and designed responsively so it holds up on the phones many students will actually use.

6. Development Process

I translated the design into a working site using semantic HTML for structure, CSS for layout and responsive behavior, and JavaScript for interactivity. The multi-page architecture keeps each section of content in its own file, which makes the site easier to navigate in code and simpler to extend. I kept repeated patterns, like the shared navigation and page layout, consistent across pages so updates and new content can be made in one place rather than page by page. As the site has grown through client revisions, I've tested the responsive behavior and layout as part of preparing it for launch.

7. Client Collaboration

Working with a real client is different from a personal or class project because the requirements come from someone else's needs, not my own assumptions. My job has been to translate the client's goals, like "students need to find events and resources," into concrete page structure and design decisions. I've gathered the client's content and feedback, made revisions based on it, and balanced my design judgment against what he actually wanted. Because the client plans to keep adding content and features after launch, I've also had to build with their future changes in mind, not just the first version.

8. Challenges & Problem Solving

Organizing varied content. Problem: the site has to serve several distinct needs — about the organization, upcoming events, past events, and resources — without any one burying the others. Thought process: forcing it all onto one page would make everything hard to find. Solution: a multi-page structure with clear navigation so each type of content has a dedicated, predictable place.

Designing for an unfinished scope. Problem: the client has more content and features planned after launch, so the site can't be structured as a fixed, finished thing. Thought process: if I hard-code the current content into rigid layouts, every addition becomes a rebuild. Solution: keep the structure and components consistent and modular so new content slots in without breaking the layout or navigation.

9. Current Status

This project is still in development. The core multi-page website — structure, design, responsive layout, and the initial content — is built and deployed to a live staging URL, and it is being finalized for its initial launch. Additional client-requested features, content, and improvements are planned for future iterations after the first release.

10. Result So Far

Because the project isn't finished, I won't claim final metrics. What it has accomplished so far: the organization now has a dedicated platform it controls, students have a centralized place to access information, events, and resources, and the project has progressed from the client's initial constraint — "we can't build this on the school's site" — into a functional website approaching launch.

11. What I Learned

This has been my first sustained real-client project, and the biggest lessons are about process, not just code: how to turn a vague request like "a place for students to find things" into concrete page structure and design decisions; how to design for actual users instead of hypothetical ones; how to handle revisions and changing requirements without losing the design's coherence; and how to build a site that's ready for real-world deployment and the changes that come after it.

12. Next Steps

The immediate focus is finishing the core website and deploying it for the initial launch. After that, the client has additional features, content, and improvements they want to add, which I'll implement in future iterations as the site grows.

Overview

A team-built, LLM-powered web scraping dashboard that helps analysts monitor oil and energy market signals in one place (Python/Flask with a local LLM via Ollama). I joined after the initial dashboard and chat interface had been built; my role centered on the front end: usability, responsiveness, and making the quality of the data visible in the UI.

The Problem

The core system worked, but the interface had not caught up. The chat input and loading flow gave poor feedback, the layout assumed a desktop screen, and, most importantly for an analyst tool, the LLM could present confident-sounding output built on weak data without the interface warning anyone.

My Approach

Because this was an existing codebase, I started by reading, not writing: understanding the structure and conventions before changing anything. Then I listed the friction points from actually using the dashboard and worked through them one at a time, keeping each change small and consistent with the patterns already in place.

Design & Development Decisions

• Rebuilt the chat input and loading flow so users always know the system is working and what it is doing.
• Added light/dark themes through CSS variables so the entire interface switches consistently.
• Made the dashboard fully responsive so analysts are not tied to a desktop.
• Implemented source reliability scoring and live API health monitoring in the UI so data quality is visible at a glance.
• Built a filterable price chart, plus safeguards that identify weak signals instead of allowing unsupported guesses.

Challenges & Solutions

The hardest part was the trust problem: an analyst tool that occasionally presents weak data confidently is worse than one that admits uncertainty. My solution was to move reliability into the interface itself, through source scoring, API health indicators, and weak-signal flags, so the user can judge the output instead of blindly trusting it. Working inside code I did not write was its own challenge; matching established conventions mattered more than rewriting things my way.

Result

The project concluded with a live demonstration, cost analysis, and presentation to the board. For me it proved I can step into a team project, find the highest-value improvements, and ship them without disrupting the team's work.

What I Learned

Reading and extending an unfamiliar codebase, designing UI around data quality and trust, making information-dense layouts responsive, and presenting technical work to non-technical stakeholders.

Overview

A budgeting app I use every week, built with HTML, CSS, and vanilla JavaScript, with Firebase for sign-in and storage. I was the product owner, designer, and tester, and Claude assisted in configuring the math logic, and helped with debugging and testing. I defined every feature and rule, approved the designs, set up GitHub, Firebase, and the security rules, tested on my own phone and laptop, and approved every commit.

The Problem

I get paid every Friday. Most budgeting apps assume monthly pay and divide by 4.33 weeks, but a real month has four or five paydays. My rent is weekly and my other bills are monthly with different due dates, so the question I actually had was which paycheck pays which bill. My pay also changes week to week, and sometimes I cover a bill from a separate savings account. I couldn't find a tool that handled any of that.

My Approach

I started with a one-page budget calculator and put it on GitHub first so every change could be reviewed and undone. Then I replaced the 4.33-week average with a count of the real Fridays in each month. Before building the paycheck cards, I reviewed a clickable mockup and changed the rules (weekly rent, editable due dates) before any code existed. After a few weeks of daily use, I cut the summary from six tiles to three and merged panels that repeated each other.

Design & Development Decisions

• One number at the top, green or red, for what's projected to be left this month.
• A card for each payday listing the bills due before the next one, with checkboxes and a running total.
• A "This week" card: enter your pay and see what it has to cover and what's left until Friday.
• "Pay from other source" for bills covered by side savings, tracked in its own panel.
• Firebase with Google sign-in. A security rule lets each account read and write only its own data.
• A light and dark theme toggle in the header.
• A macOS reminder at 9 AM on Fridays asks what I made that week and saves it to the right week.
• Calculation code lives in its own file, separate from the screen and sync code, and every input recalculates and redraws the whole page so the numbers can't drift apart.

Challenges & Solutions

A tab left open overnight from September 30 to October 1 saved October's pay under September and then wiped it. Now the app checks the month again whenever you come back to the tab or start typing. My phone and laptop could also overwrite each other, so every piece of data now carries the time it was last changed and the newer copy wins. The reminder had its own bug: macOS's open command was quietly dropping the pay amount from the link. I set up a small local server to log the exact URL Safari received, found the problem, and switched to AppleScript.

Result

It's live on my phone and laptop and I use it every week. On Friday I get one prompt and enter one number, and I can see which bills that check covers. It shipped through 12 reviewed commits.

What I Learned

Model the real unit. Once the app counted paychecks instead of months, the numbers matched my bank account. Real devices find bugs a test browser won't. And directing an AI assistant is a skill of its own: clear requirements, checking the output against real use, and asking for a bug review before every commit.