Recently I was lucky enough to get the opportunity to work on a website for USPS at Journey Group. The project was a big one: a Nuxt-powered frontend paired with a custom Laravel backend for managing content.

The site was built to showcase stamp details, stories, first-day-of-issue events, and even a digital catalog companion for the USPS’s physical edition.

I started out just working on the frontend, but eventually drifted into backend stuff too—making edits, adding features, and poking around in the CMS.

Here’s a rundown of the stack we used, why we picked it, and some things I wish I’d known when I started.

Stack Overview

  • Nuxt, frontend (SSR + routing + sanity)
  • Laravel, backend CMS + API
  • SCSS, for organized, nested styling
  • Heroku, hosting + deployment
  • Figma, wireframes, design, and team collab

Why Nuxt?

We needed server-side rendering because:

  1. SEO – people actually need to find these stamps and stories in Google.
  2. Performance – faster page loads, smoother experience.

Nuxt also just… makes sense. Routing, state management, and plugins are all built in, so you’re not reinventing the wheel every five minutes.

And honestly, at Journey Group we tend to lean on Nuxt a lot because React can feel like overkill for projects like this. Nuxt hits the sweet spot between “powerful” and “easy to live with.”

Backend with Laravel

On the backend, Laravel powered the CMS where editors added all the stamp and event content. It was great because:

  • We could design the content models however we needed.
  • User roles + permissions were easy to set up.
  • The API layer played really nicely with Nuxt.

I started off just consuming data from the API, but before long I was adding endpoints and tweaking the backend myself. Definitely stretched me beyond frontend comfort zone.

Styling with SCSS

For styles, we went with SCSS. Nesting and variables saved a ton of headaches when things got big. It helped keep the code organized and somewhat sane.

That said, coming back to the code a year later… I can see plenty of spots where I could’ve written things in a cleaner, more reusable way. The kind of stuff you only realize after living with a project for a while.

Lessons learned

This project’s been live for about a year and a half now, and I still dip back into the codebase sometimes. Every time I do, I run into old styles or patterns I wish I’d thought through better.

Some big takeaways:

  • Write code that’s maintainable, not just “working.”
  • Think about how styles and components can scale from the start.
  • Document decisions—future you will thank past you.

I’ve been refactoring bits here and there, but the biggest lesson is simple: code ages fast, so set it up for future you.

Wrapping up

Working on the USPS site was a huge growth experience. I picked up Nuxt tricks, learned more Laravel than I expected, and walked away with a new appreciation for clean, scalable code.

If I had to boil it down: the stack matters, but the way you write your code matters more.