Building MyAutoGlassRehab.com With Nuxt 3: Technical Decisions

Why Nuxt 3 for a Local Business Website

The obvious question: why use a full application framework for what could be a static marketing site? A WordPress template or a Squarespace page would have been faster to launch and cheaper to maintain. There were specific reasons Nuxt 3 was the right tool here.

First, MyAutoGlassRehab was never going to stay a static marketing site. From the beginning, the plan included a customer intake form that would feed directly into the BastionGlass ERP system. That meant the site needed to make API calls, handle form validation with real business logic, and eventually support authenticated customer portals. Building on a static site generator would have required a rewrite within six months.

Second, SEO performance was critical. Nuxt 3's server-side rendering meant every page was delivered as fully rendered HTML, which gave us a significant advantage over client-rendered alternatives. For a business where ranking for local search terms is the primary customer acquisition channel, this was not a nice-to-have. The SEO strategy depended on technical fundamentals that Nuxt provided out of the box.

Third, I was already building BastionGlass on Nuxt 3. Sharing the framework meant shared knowledge, shared component libraries, and faster iteration across both projects. The component architecture I built for the marketing site could be extended directly into the ERP interface without translation.

Component Architecture for Reusability

The component architecture was designed around two principles: reuse across the marketing site and future compatibility with BastionGlass.

At the base layer, I built a set of UI primitives — buttons, cards, form inputs, modals — styled with Tailwind CSS. These components were not auto-glass-specific. They were generic enough to use in any project but styled to match the AutoGlass Rehab brand through Tailwind's configuration layer rather than hardcoded values.

Above the primitives sat domain-specific components. A ServiceAreaCard displayed a city name, service description, and call-to-action. A QuoteRequestForm handled multi-step customer intake with field validation. A TestimonialSlider rotated customer reviews. These components encapsulated both the presentation and the business logic specific to the auto glass domain.

The page layer composed these domain components into full pages. City landing pages shared a consistent template but accepted dynamic content — the specific city name, neighborhoods served, driving conditions, and testimonials from customers in that area. This template-driven approach meant adding a new city page was a content task, not a development task.

Vue 3's composition API and Nuxt's auto-import system made this structure clean to work with. Composables handled shared logic like form state management and API communication. Components auto-imported from the components/ directory without explicit import statements. The developer experience was efficient enough that I could build and deploy a new city page in under an hour.

Preparing for ERP Integration

The most consequential technical decision was designing the site to integrate with BastionGlass from day one, even though the ERP was still under development when the marketing site launched.

The customer intake form was the integration point. On the marketing site, it collected customer information — name, phone, vehicle details, damage description, preferred service date — and stored it in a lightweight backend. But the form's data schema matched exactly what BastionGlass would expect when it came online. Field names, validation rules, and data types were all defined once in a shared TypeScript interface and used by both systems.

This meant the integration was a plumbing change, not a redesign. When BastionGlass was ready to receive leads, we swapped the form's submission endpoint from the temporary backend to the BastionGlass API. The form itself did not change. The customer experience did not change. But suddenly, submitted leads were flowing directly into the ERP's dispatch queue, where Chris could schedule jobs, assign technicians, and track the work through to invoicing.

The customer intake system design is its own article, but the architectural decision worth highlighting here is the value of defining data contracts early. By agreeing on the shape of data before either system was complete, we avoided the messy integration phase that typically follows when two systems are built independently and then forced to talk to each other.

Performance in Practice

Nuxt 3's performance characteristics were strong out of the box, but we made specific optimizations for the auto glass use case. Images were the biggest variable — high-quality photos of completed work are important for trust but heavy to load. We used Nuxt Image with automatic WebP conversion and responsive srcsets so that mobile users on slower connections received appropriately sized images.

The initial page load consistently scored above 90 on Lighthouse performance audits. Time to interactive was under two seconds on 4G connections. These metrics mattered for two reasons: they contributed to search ranking through Core Web Vitals signals, and they reduced bounce rates from mobile users — the majority of the site's traffic.

The choice to use Nuxt 3 added complexity compared to a template-based solution, but it paid for itself through SEO performance, ERP integration readiness, and the ability to iterate on the site without framework migrations. For a business where the website is the primary lead generation tool, that investment was justified.