Everything But Water — Next.js + NestJS replatform of a women's apparel storefront
Constraint
The box they were trapped in
The brand needed performance and SEO without giving up the on-brand design that customers came back for. The existing site wasn't scaling efficiently as the catalogue grew, and slow product pages are product pages search engines stop ranking. The rebuild had to make the storefront fast on the mobile devices customers actually shop on, hold up to the growth they were planning into, and ship in months — not in the kind of platform-migration window that turns a year-end goal into a Q3 problem.
Approach
How we attacked it
Next.js for the storefront with server-rendered category and product pages — so the catalogue is crawlable, indexable, and quick on first paint instead of waiting for a client-side hydrate. Image handling routed through the framework so the hero photography that drives the brand doesn't drag LCP down. A NestJS REST API for the commerce layer with MongoDB underneath for product, inventory, and customer data. AWS for hosting — EC2 for the API, S3 for assets, CloudFront in front of both for global delivery. SEO scaffolding built in from day one: sitemaps, structured data, canonicals, redirect inventory — in the repo, not on the launch checklist.
Decisions
What we picked, and what we rejected
Server-rendered Next.js, not a SPA storefront
Category pages have to crawl and product pages have to load quickly on mobile. A client-side-only storefront means Google sees an empty shell and the customer waits for hydration before they can scroll. SSR makes the page ready to paint and ready to index from the first byte — and the framework gives us streaming and image optimization for free.
Kept the existing commerce data model on NestJS + MongoDB over a platform migration
The order flow, inventory model, and customer data were working. Replatforming working commerce is months of risk for no customer-visible gain. The rebuild scope was the storefront, the API contract, and the deploy pipeline — everything underneath that stayed because it didn't need to change.
CloudFront in front of both the storefront and the asset bucket
One CDN for HTML, images, and static assets means one cache mental model and one set of invalidation rules. Splitting the storefront across two CDNs would have saved a few cents and bought a class of cache-skew bugs that's painful to debug at peak traffic. CloudFront also keeps the perimeter inside the same AWS account as the rest of the stack.
SEO scaffolding from day one, not after launch
Sitemaps, structured data, canonicals, and redirect inventory are not a post-launch checklist for a brand that ranks for category keywords. They're in the repo, generated alongside the pages, and reviewed in PR. Treating SEO as build-time output rather than a launch-week scramble is cheaper and survives the team's next sprint.
Trade-off
What we didn't build
We did not migrate them to a new commerce platform. The catalogue and order flow worked; replatforming working commerce is months of risk a customer never sees. The rebuild was the storefront, the API contract, and the deploy pipeline; the parts underneath that already worked stayed where they were. We also kept the backend a NestJS monolith instead of going micro-services. At the team's size and the catalogue's complexity, a monolith ships faster, is easier to debug under load, and doesn't ask the team to operate a service mesh they don't need.
Outcome
What changed after we shipped
New Next.js storefront live at https://www.everythingbutwater.com, served from AWS with CloudFront in front. Category and product pages render server-side and crawl cleanly; image-heavy hero shots no longer dominate LCP; the team owns the commerce API instead of riding a third-party platform's roadmap.
Talk to us
Have a similar project in mind?
Tell us what you're working on. We'll let you know whether it's a fit.