HomeBound Aisha

Overview

HomeBound Aisha is a multi-page responsive website delivered as a real client project for a home-based cleaning and domestic service provider. The site presents the business professionally across four pages: a landing page with a hero section and service highlights, a dedicated services page with detailed listings and pricing tiers, an about page establishing trust through the owner's story and credentials, and a contact page with a validated enquiry form. The layout was engineered mobile-first, meaning base styles target small screens and progressive enhancements are layered on at wider breakpoints. The project is published on GitHub and demonstrated a complete client delivery workflow from brief to deployed product on GitHub Pages.

Architecture

Tech Stack

• HTML5, Semantic elements: nav, main, section, article, footer with ARIA labels throughout
• CSS3, Custom properties (variables), Flexbox for nav and card rows, CSS Grid for service and testimonial layouts
• Responsive Design, Mobile-first base styles with @media (min-width) breakpoints at 480 px, 768 px, and 1024 px
• Vanilla JavaScript, Contact form validation, smooth scroll via scrollIntoView, mobile navigation toggle
• GitHub Pages, Static hosting with custom domain support

Build Process

/* style.css - design tokens */
:root {
  --color-primary: #2c6e49;
  --color-accent:  #80b918;
  --color-bg:      #fafafa;
  --color-text:    #1a1a1a;
  --font-body:     'Inter', sans-serif;
  --space-md:      1.5rem;
  --space-lg:      3rem;
}

/* responsive.css */
/* Base: single column */
.services-grid { display: grid; grid-template-columns: 1fr; gap: 1rem; }

@media (min-width: 480px) {
  .services-grid { grid-template-columns: repeat(2, 1fr); }
}

@media (min-width: 768px) {
  .services-grid { grid-template-columns: repeat(3, 1fr); gap: 1.5rem; }
}

@media (min-width: 1024px) {
  .services-grid { gap: 2rem; }
}

// main.js - form validation excerpt
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

form.addEventListener('submit', (e) => {
  let valid = true;
  if (!nameInput.value.trim()) { showError(nameInput, 'Name is required'); valid = false; }
  if (!emailRegex.test(emailInput.value)) { showError(emailInput, 'Valid email required'); valid = false; }
  if (!valid) e.preventDefault();   // block submission only when invalid
  else showSuccess('Opening your email client to send the enquiry.');
});

User Interaction Flow

Challenges & Solutions

CSS Specificity Conflicts on Responsive Overrides. Adding media query overrides to flat class names caused specificity battles where mobile styles leaked into desktop layouts and vice versa. The solution was adopting BEM-style naming (.service-card, .service-card__title) and keeping all responsive rules in a separate responsive.css file, which enforced a clear override order and made the responsive layer easy to audit in isolation.

Contact Form Without a Backend. The client needed a working contact form but the site is hosted statically on GitHub Pages with no server. The solution combined a mailto: action attribute on the form (which opens the user's email client pre-populated) with JavaScript-driven client-side validation and a confirmation message. For a more robust no-backend solution, the form was architected to be easily swapped for a Formspree or Netlify Forms endpoint in future.

What I Learned

• How to structure a genuine client project from brief through delivery, including managing scope and collecting feedback iteratively
• Mobile-first CSS methodology and why starting from small screens produces cleaner, less overridden stylesheets than the reverse
• The value of BEM naming conventions for preventing specificity conflicts in multi-file CSS projects
• Implementing accessible navigation: ARIA labels, focus management in modal/drawer patterns, and keyboard navigation
• The limitations of static hosting for form handling and the patterns available to work around them
• W3C HTML and CSS validation as a quality gate before deployment

How I Built It

Phase 1: Client brief and scope. This was a genuine client project, so it started with a brief: who the site serves, what pages it needs, and how the client would request changes. Agreeing scope upfront kept the build focused and the feedback rounds short.

Phase 2: Mobile-first styles with BEM. The CSS was written mobile-first and organised with BEM-style naming (.service-card, .service-card__title), so responsive overrides in the separate responsive.css file never fought with base styles. The override order is explicit and auditable in isolation.

Phase 3: Accessible components. Navigation, the mobile drawer, and the contact form were built with keyboard navigation and ARIA labels from the start, including focus management in the drawer pattern.

Phase 4: The no-backend contact form. GitHub Pages has no server to process forms, so the form uses a mailto: action with JavaScript client-side validation and a confirmation message. The markup is structured so a Formspree or Netlify Forms endpoint can replace the mailto action later without restructuring.

Phase 5: Validation and delivery. The HTML and CSS passed W3C validation as a quality gate, the client reviewed and approved, and the site shipped.

What You Need

Challenges and Lessons Learned

Specificity conflicts on responsive overrides. Flat class names plus scattered media queries created leaks between mobile and desktop styles. BEM naming plus a dedicated responsive.css file ended the fighting. Lesson: CSS architecture is decided by naming and file organisation, not by clever selectors.

Forms without a backend. A mailto: action is a compromise: it works everywhere but depends on the visitor's email client. Architecting the form so a real endpoint can be swapped in later was the right middle ground for a static host, and it taught me to always design for the upgrade path even when the budget says otherwise.

Real client, real constraints. Collecting feedback iteratively and managing scope with an actual client was as valuable as the technical work. Shipping means deciding what is good enough, not what is perfect.

What Is Next

• Replace the mailto form with a Formspree or Netlify Forms endpoint for reliable submissions
• Booking or scheduling integration for the services offered
• Testimonials section with client-approved quotes
• Blog or news section so the client can publish updates without code changes
• Performance and SEO audit with Core Web Vitals targets