How I Built Stars In Hands: A Custom Next.js Personalized Gift Store

Why I Skipped Shopify for This One

The first real decision on Stars In Hands wasn't a stack choice. It was a refusal. I didn't want the product page to be a landing page that punts the customer off to a separate customizer on some other subdomain. For a personalized gift store, that handoff is where you lose people.

Stars In Hands sells printed keepsakes: custom star maps, moon phase prints, city maps, combo maps, and photo memory posters. The customer picks a date, a place, a time, maybe a photo and a line of text, and we generate a print-ready poster of the night sky (or the moon, or the streets) exactly as it looked at that moment. The buying decision happens inside the editor, not on a marketing page above it. So I built the whole thing in Next.js where the editor and the product page are the same surface.

If you've read my take on whether headless commerce is worth the hype, you already know I don't reach for custom by default. Most stores should be on Shopify. This was one of the cases where custom actually earns its keep, and I want to be specific about why.

Catalog-first vs editor-first

A normal store is catalog-first. Product, variants, reviews, price, add to cart, checkout. The product exists before the customer shows up. Shopify is excellent at that and I'd never rebuild it from scratch.

Stars In Hands is editor-first. The product doesn't exist until the customer makes it. They're not picking a poster off a shelf, they're recreating a memory: the sky over the hospital the night their kid was born, the moon on their wedding night, the corner where they met. Before anyone pays, they need to believe three things:

• The map is accurate for their date and place.
• The preview is actually what'll show up in the mail.
• Checkout will work in their country and their currency.

That third one is why I'm not stitching a Shopify Buy Button into a custom editor. You can do it, but you fight the platform the whole way: cart attributes for personalization payloads, line-item properties that truncate, checkout you can't fully control. When the editor is the product, owning the cart and checkout end to end is the cheaper path, not the expensive one.

When I'd tell you to build custom (and when I wouldn't)

Quick aside, because people ask me this constantly. The tiebreaker isn't "is it ecommerce." It's whether the product experience itself is the differentiator.

Selling t-shirts with 12 SKUs? Shopify. Selling subscriptions, doing standard variants, want to be live next week? Shopify, every time. The moment you're tempted to go custom for a "normal" store, you're usually just underestimating how much undifferentiated plumbing you're signing up to maintain: tax, fraud, shipping rates, PCI scope, the lot.

Build custom when the thing the customer interacts with before buying is genuinely your IP. A live star-map generator that has to be accurate, fast, and calm on a phone is that. That's the one part Shopify can't hand you, so the rest of the store gets pulled along with it. That's the actual decision, and it's the same one I walk through on most of my client projects.

The stack, and why each piece is there

Next.js App Router for the storefront and localized routing. Content lives in a CMS so product copy, magazine posts, FAQs, materials, shipping, and policy pages can change without a deploy. I don't want a typo fix in a returns policy to require a build.

The parts that matter:

• Next.js App Router for localized storefront routes
• CMS-managed product and editorial content
• Custom editors for star, moon, city, and combo maps plus the memory poster
• Date, time, and location handling for the personalization inputs
• PayPal for international buyers
• Razorpay for India
• Locale routes for English, German, French, Spanish, Italian, Portuguese, Dutch, Japanese, and Polish
• A sitemap index pointing at per-locale sitemaps
• Canonical URLs and hreflang alternates
• Product, Organization, WebSite, and Breadcrumb structured data

None of that is there because it's trendy. It's there so personalization, search, and checkout behave like one product instead of three bolted-together systems.

The editor is where trust gets made or lost

The hardest design problem wasn't the rendering. It was restraint. Too many controls and the gift feels like CAD software. Too few and it feels generic, like every other star-map site running the same template.

What the editor has to carry:

• A date that maps cleanly to the customer's event
• A location that reads as precise and recognizable
• Optional time input, for the people who care about getting it exactly right
• Design choices that don't bury the user in options
• A live preview that updates as they go
• Mobile-first behavior, because most of this traffic is on a phone
• Cart data that preserves every single choice

I kept the editor down to the minimum fields needed to make a meaningful print, then pushed all the explanation — how accurate is this, do you need the exact birth time, what should I write — into SEO sections and FAQs below the fold. The person mid-build shouldn't have to read an essay. The person still deciding can scroll.

The non-obvious part: the preview has to stay fast while the customer drags inputs around. A laggy preview loop reads as "this product is janky," and on a gift you're about to spend money on, that doubt is fatal. Keeping that interaction tight is the same discipline I wrote up in Next.js 14 performance optimization — it's not a Lighthouse vanity score, it's the literal feel of the product.

Localization was load-bearing, not a translation pass

A personalized gift store can absolutely sell across borders, but only if localization is part of the architecture instead of a Google Translate layer sprayed on at the end.

On Stars In Hands localization reaches into:

• Route structure
• Hreflang tags
• Sitemap entries
• Currency display
• Product copy
• Trust and support pages
• Checkout expectations
• Shipping and return messaging

This is where translated stores quietly sabotage themselves. A German product page that canonicalizes back to the English one, or ships without hreflang, doesn't support the original — it competes with it for the same rankings and you've split your own authority. The live site exposes proper locale alternates for the homepage, product pages, and magazine pages, so each language pulls its own weight instead of cannibalizing the others.

Two payment gateways, one checkout

Payment coverage was a hard requirement from day one. PayPal covers international buyers who already trust it. Razorpay covers Indian customers who expect UPI, cards, and local methods and bounce if they don't see them.

Running both creates real engineering constraints:

• The checkout flow has to feel identical even though the providers underneath are different.
• The order has to store enough metadata to fully reproduce the personalized print.
• The personalization payload can't get dropped during a gateway redirect.
• Cart and checkout routes stay out of the index.
• The buyer should see the payment method that feels native to their region without thinking about it.

That fourth point about the payload is the one that bites you. For a normal store, a redirect that loses cart state is annoying. Here it's catastrophic, because the cart is the product. The customer's date, location, time, message, and design choices have to survive editor → cart → gateway redirect → order → fulfillment without a single field going missing. I treat the personalization payload as the thing that must never be lost, and pick gateways around that constraint. Choosing PayPal and Razorpay specifically came out of the same logic I lay out in my payment gateway selection guide: match the gateway to where your buyers actually are, not to whatever's easiest to integrate.

SEO that fits how people search for gifts

The public pages expose clean crawl signals: indexable product URLs, canonicals, hreflang across all supported languages, a sitemap index feeding per-locale sitemaps, Product schema with shipping and return details, breadcrumb schema, and magazine pages aimed at informational and gift-intent queries.

The reason this is structured and not generic: personalized gifts get searched a dozen different ways that look similar but aren't. "Custom star map" is a different intent from "moon phase wedding gift," which is different again from "where we met map" or "newborn keepsake print" or "anniversary gift for couple." Same store serves all of them, but they don't want the same page. The architecture has to let each intent land somewhere that actually answers it.

On speed

Performance wasn't a cleanup pass at the end, it was part of the SEO work. The public pages I checked score around 95 with the core audit categories at 100%. But I care less about the screenshot than about two things it stands in for:

• Buyers on a gift editor need the page and the preview loop to feel instant.
• Search engines have less friction crawling and rendering when the public routes are fast, cacheable, and stable.

For a custom build I'd rather have a fast product page, a responsive editor, reliable cart preservation, a clean checkout handoff, and well-delivered images under real load than a perfect Lighthouse number that falls apart the moment someone starts customizing.

Making it readable to AI search

Answer engine optimization isn't a separate discipline from SEO. It's mostly clearer content, better structure, and stronger entity signals. For a store like this, the move is direct-answer sections that a model can extract cleanly:

• What is a custom star map?
• How accurate is a star map?
• Do you need the exact birth time?
• What is a moon phase print?
• What should I write on a star map?
• What's the difference between a star map, moon map, and city map?

Short answer up top, then expand below with examples, FAQs, and links to the relevant product page. A gorgeous page that never actually answers the question loses to a plain one that does. The growth opportunity isn't another generic blog post, it's pages that match real buying intent.

What I'd skip

I'd skip broad "Top 10 Gift Ideas" posts with no angle. Those queries are vague, brutally competitive, and owned by marketplaces. I'd skip thin translated content — if a page exists in German, it should answer the German query naturally, with native phrasing and occasions, not just swapped nouns. And I'd skip hiding the customizer behind a wall of marketing sections. The user should understand the product and start building within seconds.

The lesson worth keeping

Personalized ecommerce needs a different mental model than normal ecommerce. In a normal store the product exists before the customer arrives. Here, the customer creates the product, which means the application's main job is protecting that creative state from the first editor input all the way to fulfillment.

Every architectural question collapses into that:

• Can the customer preview the gift clearly?
• Can the cart hold the full configuration?
• Can checkout complete without dropping personalization?
• Can fulfillment recreate the exact print?
• Can search engines understand the public pages?
• Can translated routes support international discovery?

Get all of those to yes and the store stops being a checkout wrapper. It becomes a product creation system, which is the whole reason it was worth building custom in the first place.

FAQ

Why not just build this on Shopify? For a standard catalog I would have. Stars In Hands is editor-first — the product is generated by the customer — so owning the editor, cart, and checkout end to end was simpler than fighting the platform to preserve a personalization payload through checkout.

Why two payment gateways? PayPal for international buyers, Razorpay for Indian customers who expect UPI and local methods. Different regions, different expectations, one consistent checkout on top.

How is the multi-language support handled? Locale-specific routes with proper hreflang alternates and per-locale sitemaps, so each translated page ranks for its own market instead of competing with the English original.

What does "editor-first" actually change? The product page and the customizer are the same surface, and the cart has to preserve every personalization choice intact. The whole architecture is built around never losing that creative state between the editor and fulfillment.