Customer website
Service discovery, guided shopping, equipment comparison, and quote or installation requests. The public UX helps people choose a useful next step.
new.u1mechanical.com (opens in a new tab)Public owner-review previewWebsite redesign · full-stack webapp rollout
U1 Mechanical
From a clearer customer journey to a connected website, owner dashboard, and field app. A story of research, implementation, failed attempts, and a verified hosted owner-review rollout.
- My contribution
- Product direction · UX research · full-stack delivery · AI-assisted implementation and verification
- Timeframe
- September 2026 · owner-review rollout
- Status
- Ongoing
01 / The problem
A better front door. A working system behind it.
An HVAC customer needs to understand their options and take the next step. The team behind that website needs a dependable way to review requests, manage work, and support technicians. The redesign had to improve the public journey while preserving the operational applications—and prove that the whole application could run on the intended host.
02 / What I built
I shaped the work around three connected experiences: customer discovery and quote requests, an owner and office dashboard, and a field webapp. Mobbin informed the public UX; React and Next.js delivered the interfaces and server routes; Prisma and Neon carried the data; GoDaddy Node.js hosting carried the rollout. Each failure fed a smaller diagnostic, a targeted correction, and another test.
03 / Explore the rollout
The front door is only the beginning.
One system · three experiences
For the customer. The office. The technician.
Owner dashboard
A protected workspace for the operational side: catalog, customer and request workflows, estimates, and dispatch. Roles govern access to the underlying records.
admin-new.u1mechanical.comReal owner password login verifiedTechnician experience
A focused field interface for assigned work. It shares the application’s data and authorization model, with a separate entry point for technicians.
field.u1mechanical.comHosted access gate verified; field sign-in acceptance remains openSHARED BACKEND
Server routes → authorization → Prisma → Neon
Next.js handles server-side requests. NextAuth and fresh role checks protect operations. Prisma connects to Neon PostgreSQL over secure WebSockets on this host. External storage keeps uploaded files separate from deployed code. GoDaddy runs the same qualified application in three included app slots.
These are three entry points to a shared system, not three independent databases. Host-only cookies require a separate sign-in on each address.
The path to a working release
Research. Build. Fail. Learn. Try again.
The useful part of the story is the loop: each failed assumption changed what was researched, built, or tested next.
- 01Research
Start with what the customer needs to do.
Mobbin research compared service-business heroes, product comparison tables, request forms, and next-step sections. Airtasker, Synthesia, Jobber, and Daylight helped frame clearer choices: browse equipment, compare options, or request an installation.
Use patterns to answer a specific UX question. Implement independently; do not borrow another company’s claims or assets.
- 02Plan
Map the whole journey before choosing the host.
The public website, office dashboard, and field app share a business context but have different access needs. The plan separated application code, database records, uploaded files, roles, and external providers, while preserving the original website and mail setup.
A domain name is only the address. The runtime, authentication, storage, and database connection have to work together.
- 03Implement
Build the front end and the system behind it.
The public refinement improved service discovery, guided shopping, comparison, and request flows. Next.js server routes, Prisma data access, NextAuth sessions, and role checks supported the operational system. The public redesign preserved the accepted dashboard and field layouts.
Connect the experiences through shared data and permissions without forcing every role into the same interface.
- 04Test & fail
A local pass did not guarantee a hosted pass.
The host rejected direct PostgreSQL connections. Early imports failed even when private Preview ran. A wrapped release then failed the provider’s health check. Later, the owner setup form returned 403 in the real browser despite earlier diagnostic success.
Treat each failure as evidence about a specific boundary. Do not confuse a running preview with a published, usable application.
- 05Research again
Make the failing condition small enough to understand.
Transport probes established that secure WebSockets worked. Package inspection identified missing runtime files. Host-specific tests separated provider liveness from app access. A browser diagnostic finally reproduced the owner form’s null Origin and traced it to the referrer policy.
When a test misses the bug, improve the reproduction before repeating the same deployment or asking the user to retry.
- 06Retry & verify
Close the loop with a real hosted sign-in.
The corrected release used Neon’s WebSocket driver, a self-contained integrity-checked package, and a narrow liveness response. Three included hosting apps served the approved addresses. A same-origin form policy fixed owner setup while retaining origin checks; the owner then signed in successfully.
Success meant a visible website, protected applications, the intended database, and a human who could actually use their account.
Research into decisions
Mobbin helped ask better design questions.
The research focused on the public website and quote journey. Operational layouts were preserved. These references informed independently implemented patterns.
Airtasker · heroPair a clear proposition with an obvious next action.View Mobbin reference (opens in a new tab)Synthesia · comparisonUse consistent labels and columns so options can be compared.View Mobbin reference (opens in a new tab)Jobber · request flowExplain the request, allow supporting details, and acknowledge receipt honestly.View Mobbin reference (opens in a new tab)Daylight · next stepsShow distinct paths instead of making every visitor start the same way.View Mobbin reference (opens in a new tab)
Mobbin is a research tool, not a runtime dependency. Envato Elements catalog research also informed the exploration; no new licensed asset acquisition was claimed.
Inspect the hard parts
Four failures that improved the release.
Open a failure to follow the diagnosis, repair, and evidence.
Database connection blocked
- What failed
- Direct PostgreSQL TCP failed on the actual host.
- What we researched
- Test the transport separately from the credentials and schema.
- What changed
- Use the official Neon WebSocket driver with the matching Prisma adapter; retain strict TLS and the working local adapter.
- How it was checked
- Host connectivity read-back, migration rehearsal, and packaged-runtime session checks.
Preview worked; publication failed
- What failed
- Early imports failed, and one published package omitted a required runtime helper.
- What we researched
- Compare the imported artifact with the qualified application, including every required runtime file.
- What changed
- Deliver one self-contained wrapper with payload and per-file integrity checks, then cold-start the final package.
- How it was checked
- The same qualified release bytes were published and checked across all three apps.
Hosting assumptions broke
- What failed
- The provider health check used an internal hostname; the website app accepted only one custom domain.
- What we researched
- Inspect the health-check behavior and the actual plan’s domain and app limits.
- What changed
- Return neutral liveness only at the internal root, keep other unknown-host requests denied, and use included app slots for the remaining addresses.
- How it was checked
- HTTPS, hostname enforcement, shared build identity, and dashboard/field access gates verified.
The owner form rejected the browser
- What failed
- A real form submission returned 403. An earlier diagnostic had omitted the policy that triggered it.
- What we researched
- Reproduce the browser submission with the actual response headers and synthetic data.
- What changed
- Change the setup form’s referrer policy to same-origin while retaining null-origin, foreign-origin, and CSRF rejection.
- How it was checked
- The owner’s retry created the account, followed by successful password login to the hosted dashboard.
The technology, with a purpose
Every layer had a job.
Interface
React, TypeScript, and Next.js for pages and workflows; Tailwind CSS and Radix UI primitives for styling and controls; Framer Motion with reduced-motion checks.
Backend & data
Next.js server routes, Prisma, versioned migrations, and Neon PostgreSQL. Neon’s serverless driver supplied the secure WebSocket transport supported by the actual host.
Identity & files
NextAuth password sessions, role-based access, persistent login throttling, and external Neon storage. Hosted upload acceptance remains a separate task.
Hosting & verification
GoDaddy Node.js apps, custom subdomains, HTTPS, exact-artifact checks, disposable PostgreSQL fixtures, Playwright browser journeys, and live route read-back.
04 / Result & scope
What changed. What comes next.
Based on retained UX research, hosting diagnostics, packaged-runtime tests, deployment receipts, and hosted owner-login verification from September 20, 2026.
Three connected surfaces
The website, dashboard, and field entry point were published over HTTPS using the same qualified application and shared data services.
Real hosted owner login
The owner created their account and signed in to the hosted dashboard. The review catalog contained 16 approved examples.
A repeatable release method
Host diagnostics, migration rehearsal, package integrity checks, and live read-back became a reusable GoDaddy + Neon workflow.
The success was observable
The release record confirmed all 14 linked public pages, shared build identity across three HTTPS addresses, protected-route denial, loaded homepage imagery, and an authenticated OWNER dashboard. That is a concrete delivery milestone; it does not imply increased sales or completed production acceptance.
Testing stayed honest
The earlier local certification passed 288 required results. The later framework and hosting adaptation needed its own evidence. All eight migration journeys eventually had passing evidence across runs; they did not pass as one sealed matrix. Packaged-runtime checks then covered sessions, CSRF, host routing, static assets, and database transport on disposable local fixtures.
The work became reusable
The launch informed the godaddy-neon-webapps workflow: establish the hosting contract, prove the database path, rehearse migrations, preserve auth, package exact bytes, verify the deployed routes, and finish with a human sign-in. Each new app still needs its own roles, data model, and acceptance checks.