HPRefuel – Pre-Login & Customer Portal (Fuel Retail)

Frontend Developer – Individual Contributor · 2018 · 4 months · 2 people · 7 min read

Built the pre-login marketing experience and authenticated customer portal UI for HPRefuel in Angular — delivering a responsive, mockup-accurate frontend across both the public and authenticated surfaces.

Overview

Delivered the full frontend for HPRefuel, a fuel retail platform with two very different experiences: a public pre-login marketing interface and a secure customer portal for managing fuel accounts, transactions, and services. As the sole frontend developer, I translated designer mockups into a responsive Angular app with shared components and a smooth handoff between the marketing surface and the account portal.

Problem

HPRefuel needed two frontend experiences that felt joined, even though they served different goals. The public pre-login surface had to explain the platform, build trust, and make sign-up or login easy. The customer portal had to shift to a practical workspace for managing fuel accounts, transaction history, and services. Delivering both surfaces from designer mockups in Angular, while keeping the experience consistent and responsive on desktop, tablet, and mobile, required careful sequencing and strong component organization.

Constraints

  • Two distinct surfaces (pre-login and portal) required different layout strategies and content hierarchies within a single Angular application
  • Full responsiveness across standard devices (desktop, tablet, mobile) required from the outset — not added as a post-build pass
  • Designer-supplied mockups defined both surfaces — implementation required faithful translation with no independent design decisions
  • Angular component architecture required thoughtful structuring to keep pre-login and portal concerns cleanly separated
  • Solo contributor responsible for both surfaces within the engagement timeline
  • Fuel retail customer portal context demands UI clarity and trust — account and transaction data must be presented accurately and unambiguously

Approach

Started by reviewing both sets of mockups together to identify the shared components and visual language. That made it possible to build reusable Angular components for navigation, forms, buttons, cards, and typography before tackling each surface. I built the pre-login surface first to establish brand tone and layout rhythm, then used those design decisions in the portal while shifting into a more task-focused interface. Responsiveness was added during component development using SCSS breakpoints, not as an afterthought.

Key Decisions

Shared component library analysis across both surfaces before building either

Reasoning:

Although the pre-login and authenticated portal looked different, they relied on the same underlying component patterns. Defining that shared vocabulary first allowed me to build components once and reuse them consistently, avoiding duplicate styling and preserving a seamless transition between the two surfaces.

Alternatives considered:
  • Build pre-login and portal as completely separate Angular modules with no shared components
  • Build all components fresh per surface and reconcile after both are complete
  • Use Angular Material as a shared component foundation without custom components

Responsiveness built into each component at build time, not retrofitted

Reasoning:

Adding responsive behavior after the fact usually creates inconsistencies and extra rework. Defining SCSS breakpoints during component development kept each interface reliable across screen sizes and reduced the risk of layout issues later.

Alternatives considered:
  • Desktop-first build with a responsive pass at the end of the engagement
  • Separate mobile-specific component variants per breakpoint
  • CSS framework (Bootstrap grid) for responsiveness with custom design overrides

Pre-login surface built first to establish the platform's visual foundation

Reasoning:

Starting with the public-facing experience made it easier to define the brand tone, spacing, and visual rhythm for the portal. The portal could then follow that foundation while shifting into a more functional, user-focused layout, which kept both surfaces feeling part of the same product.

Alternatives considered:
  • Build portal first as the more complex surface, then pre-login
  • Build both surfaces simultaneously in parallel
  • Build a shared design system first and then both surfaces simultaneously

Tech Stack

  • Angular
  • TypeScript
  • SCSS
  • HTML5
  • RxJS
  • Angular Router
  • Responsive Design
  • CSS Custom Properties

Result & Impact

  • Pre-login + customer portal
    Surfaces Delivered
  • Desktop, tablet & mobile
    Responsiveness
  • Angular with TypeScript
    Framework
  • Solo contributor, full frontend build
    Delivery Model

HPRefuel shipped with both the marketing and account surfaces feeling like parts of one cohesive experience. The shared component approach kept the transition between public and authenticated views consistent, while the responsiveness-first development minimized visual surprises across desktop, tablet, and mobile.

Learnings

  • Multi-surface applications benefit enormously from shared component analysis before any surface-specific build begins — the shared vocabulary is always larger than it appears from the mockups alone
  • Responsiveness built into components at creation time is more reliable than a responsive retrofit — layout assumptions made during a desktop-only build routinely conflict with mobile reflow requirements
  • Pre-login and authenticated portal surfaces are emotionally different products that must feel architecturally like one — the design token layer is the bridge between a marketing tone and a functional one
  • Angular enforced a level of structural discipline — TypeScript, component encapsulation, routing — that jQuery-based projects did not require; the constraint was also the benefit
  • Fuel retail customer portals carry an implicit trust requirement — transaction data, account balances, and refuel history must be presented with the same visual accuracy and clarity as a banking interface
  • Solo delivery across two meaningfully different surfaces requires deliberate sequencing and clear architectural decisions upfront — without them, the two surfaces drift apart and the integration boundary becomes a problem

Pre-Login Interface

Built the public-facing pre-login surface — the first impression of HPRefuel for new and returning customers:

  • Marketing hero section — a full-width landing layout with bold value messaging, supporting copy, and clear sign-up / login actions, translated closely from the designer mockups
  • Feature and service highlights — content sections that explained HPRefuel’s core offerings, loyalty benefits, and fuel services in a clean, scan-friendly layout
  • Login and registration forms — accessible authentication forms with inline validation, error messaging, and a smooth transition into the customer portal after successful sign-in
  • Responsive design across standard devices — the pre-login surface reflowed correctly from widescreen desktop to tablet and mobile, keeping hierarchy and spacing consistent at each breakpoint
  • Navigation and wayfinding — header navigation with a mobile-friendly hamburger menu, smooth-scroll anchors for longer landing content, and a clear visual flow across page sections

Customer Portal

Built the authenticated customer portal — the functional workspace for HPRefuel account holders:

  • Account dashboard — portal home view showing the user’s current fuel balance, recent transactions, loyalty points, and quick access to common tasks
  • Transaction history — paginated fuel transaction list with date, location, volume, and cost details, arranged for easy scanning and quick comprehension
  • Account management — profile details, contact information, and notification preferences with validated forms and save confirmations
  • Fuel card management — interface for viewing linked cards, checking card status, and filtering transactions by card
  • Loyalty and rewards — points balance display, redemption history, and reward options presented in a clear, user-friendly layout

Angular Component Architecture

Structured the app with a shared component model across both surfaces:

  • Shared component library — form fields, buttons, cards, navigation elements, and typography components built once and used consistently across pre-login and portal
  • Surface-specific layout shells — separate Angular layout components for the public and authenticated contexts, each applying the right spacing, hierarchy, and visual rhythm
  • Angular Router integration — clear route separation between public pre-login pages and authenticated portal routes, with a guard-style approach for portal access control
  • TypeScript everywhere — typed component interfaces, form models, and service contracts that improved maintainability and made the code easier to reason about
  • SCSS architecture — a shared design token layer for colors, typography, and spacing, with surface-specific partials to keep the two experiences visually aligned

Responsive Implementation

Made responsiveness part of every component from the start:

  • Component-level SCSS breakpoints — responsive behavior was defined inside each component’s stylesheet as it was built, not added later as a separate step
  • Standard device coverage — validated desktop, tablet, and mobile viewports throughout the build
  • Fluid layout patterns — CSS grid and flexbox used to keep layouts flexible and avoid rigid, fixed-width layouts
  • Touch-friendly interactions — navigation, forms, and action buttons sized and spaced for reliable mobile tap targets
  • Cross-browser validation — consistent rendering and interaction behavior checked across Chrome, Firefox, Safari, and Edge
All projects