Independent client · Build record
Emblematic Studio: one catalogue, twenty products, one server route
A material-led product site and quote experience for a custom patch studio. The interesting decision is not the motion design, it is that twenty product types across four families are generated from a single typed registry — and that the entire public site runs on exactly one server route.
Published August 7, 2026. Live at www.emblematicstudio.com.
“I got quotes ranging from $10,000 to $12,000, but Panda Codegen delivered my website for $5,000 and it exceeded my expectations. It looks premium, loads fast, and perfectly captures Emblematic Studio's brand.”
“Communication was clear and responsive, revisions were quick, and the whole process felt professional. Highly recommend for anyone who wants a great website without the agency price tag.”
— Waqas Ahmed, Emblematic Studio. Unprompted review on Trustpilot, August 6, 2026.
Read that as one client's experience, which is what it is. The quotes he compares against are the ones he personally received, not a market survey, and we have no visibility into what they covered. The $5,000 figure is our published Scale tier rather than a discount — our tiers start at $1,500, $3,500 and $5,000 to $10,000, and they are on the website cost guide with what moves a project between them.
What this record does and does not prove
No traffic, ranking or revenue outcome is claimed here. The site is new to search: indexing was enabled and deployed on August 7, 2026, so there is not yet a search history worth reporting. Anyone quoting results for a site this new is describing something Google has barely crawled.
What is checkable today is the build. On the live site you can confirm that pages publish index, follow, that each carries its own canonical, and that structured data is present and specific to the route — Organization, WebSite and WebPage on the homepage, Product and BreadcrumbList on a material page.
The problem was drift, not design
A catalogue of twenty products across patches, keychains, enamel pins and coins does not fail because a page looks wrong. It fails because the same product exists in seven places and they stop agreeing. A product is added to the menu but missing from the quote dropdown. A page is removed but stays in the sitemap. A related-products card points somewhere that no longer builds.
None of those produce an error. They produce a quote request nobody can fulfil and a crawler following a link to a 404. The fix is structural: make one file the only place a product is defined, and let navigation, routing, validation and the sitemap derive from it.
The site had to feel like the product
A custom patch is a physical object you judge by touching it — the density of the stitch, the way a merrowed edge finishes, whether chenille reads as depth or as fuzz. A conventional ecommerce grid of product photos throws all of that away and leaves a buyer comparing thumbnails, which is why most custom-patch websites feel interchangeable regardless of what the factory can actually do.
So the homepage is not a landing page with sections. It is an editorial sequence of eight chapters, each a separate component with its own scroll behaviour, that walks a visitor from a flat drawing to an inspected physical object in the order the studio actually works.
| Chapter | What it has to do |
|---|---|
| Hero | Establish the object before the offer. Specimen framing, thread count, physical dimension. |
| Manifesto | State the position — a drawing becoming matter — so the rest of the page has a thesis to serve. |
| PatchFlip | Front and back. The construction argument that a photograph of the face alone cannot make. |
| MaterialLibrary | Eight constructions as one mark rendered eight ways, rather than eight unrelated products. |
| ProcessThread | Rough idea to inspected object as a route, because the buyer's real question is what happens next. |
| CollectionWorktable | Small objects that reward a closer look. Detail at a scale a catalogue grid cannot show. |
| InspectionProof | Approval made visible rather than reduced to a number — the trust step before the quote. |
| CTA | Make the first stitch. One action, arrived at rather than interrupted with. |
Keeping each chapter as an independent component matters for a reason that is not aesthetic: the homepage stays editable one section at a time. A chapter can be rewritten, reordered or removed without touching the seven around it, which is what makes an editorial homepage survivable rather than a one-off that nobody dares change.
Motion as evidence, not decoration
The scroll animation work uses GSAP with ScrollTrigger, plus SplitText for typographic reveals, DrawSVG and MorphSVG for the stitch-map illustrations, Flip for layout transitions, and CustomEase so the easing matches the brand rather than a library default. Smooth scrolling is handled by Lenis, bridged into the GSAP ticker so both share one frame loop instead of competing for it.
All GSAP plugins register in exactly one module. That sounds like housekeeping and is not: plugin registration scattered across components is the standard way a GSAP site becomes impossible to tree-shake and starts throwing registration errors in production builds. One registration point means one place to audit what ships.
The part worth copying is the gating. Lenis activates only above 900px, on fine-pointer devices, and when the visitor has not asked for reduced motion. Below that, native scrolling is the designed experience rather than a degraded one — and a visitor with a vestibular disorder gets the content immediately, with the route-transition panel skipped entirely rather than merely shortened.
Four decisions that carry the site
One registry, seven consumers
Twenty product types live in a single typed catalogue that drives the mega-menu, mobile navigation, catalogue index, product pages, related cards, quote options and the sitemap. Adding a product is one union member and one object.
One runtime route on the whole site
Everything is prerendered. Only the quote endpoint executes per request, because email needs a Node runtime. Dynamic params are disabled, so an unknown slug is a 404 rather than a render attempt.
Validate twice, store nothing
The browser checks artwork type and size; the server repeats both rather than trusting them, sanitises the filename, and reads the file into memory only to attach it. Nothing is persisted, so nothing has to be secured or deleted later.
Motion that degrades honestly
Smooth scrolling activates only above 900px, on fine-pointer devices, and when reduced motion is not requested. Everywhere else native scrolling is the intended experience, not a fallback that was forgotten.
What we chose not to build
A case study that lists only what exists is marketing. These are the scope decisions, stated so a buyer can judge whether they would have made the same ones:
- No database and no object storage. Quote artwork is attached to one email and never persisted, so there is nothing to secure, back up or delete on request. If the studio later needs a CRM or a retention policy, that is a project rather than a setting.
- The quote rate limiter is an in-memory counter. It does not survive an instance restart and is not shared across instances. It is a speed bump, not durable abuse control, and it is documented as such rather than presented as protection.
- No automated test suite. Verification is typecheck, lint, production build and manual browser testing across navigation, responsive behaviour, motion preferences and quote delivery.
What a build at this tier does and does not include is set out in what a custom website starting at $5,000 includes, and the scope questions that move a project between tiers are in how long a custom website takes.
Each is defensible for a studio taking quote requests by email. Each becomes a real requirement the moment volume, regulation or a sales process changes — which is the useful thing to know before it happens rather than after.
What was built
| Layer | Implementation |
|---|---|
| Framework | Next.js 16 App Router, React 19, TypeScript in strict mode |
| Catalogue | 20 product types across four families, from one typed registry driving seven consumers |
| Pages | 8 material pages, 12 product pages, 3 planning guides, all statically generated with dynamic params disabled |
| Quote flow | Four-step brief with session recovery, allowlist validation, honeypot, same-origin check and HTML escaping |
| Motion | GSAP with a single plugin registration point; smooth scrolling gated on viewport, pointer type and motion preference |
| Accessibility | Skip link, modal mobile navigation with focus trap and restore, ARIA state, forced-colors styles, reduced motion in both CSS and JS |
| Search visibility | Per-page metadata and canonicals, apex-to-www 308, generated sitemap and robots, route-specific JSON-LD |
Frequently asked questions
Frequently Asked Questions
Why does this case study quote no traffic or ranking results?
Because the site is new to search. The production build was corrected to allow indexing and deployed on August 7, 2026; before that it carried review-build directives that told search engines to stay away. There is therefore no meaningful search history to report yet, and any figure quoted this early would describe a site Google has barely crawled. What is verifiable today is the build itself and its search-facing configuration, both of which you can inspect on the live site.
What does 'one runtime route' actually mean?
Every page on the site is prerendered at build time. The only route that executes server code per request is the quote endpoint, because sending email requires a Node runtime. Product, material and guide pages are generated from the catalogue with dynamic parameters disabled, so an unknown slug returns the standard not-found page rather than attempting to render. The practical consequence is that almost nothing can fail at request time, and the surface area anyone has to secure or monitor is one endpoint rather than a site.
Why does a twenty-product catalogue need a typed registry?
Because the same twenty products appear in seven places: the desktop mega-menu, the mobile navigation, the catalogue index, the individual product pages, related-product cards, the quote form's options, and the sitemap. Without a single source they drift, and the failure is silent -- a product quietly missing from the quote dropdown, or a sitemap entry for a page that no longer exists. Adding a product here means extending one typed union and one object; everything else follows from it, including the server-side validation that rejects a product value the catalogue does not contain.
What happens to artwork a visitor uploads with a quote?
It is validated, attached to one email, and never stored. The browser checks extension and size, the server repeats both checks rather than trusting them, the filename is sanitised, and the file is read into memory only to build the outgoing message. There is no database and no object storage, which is a deliberate scope decision rather than an omission: nothing is retained, so nothing has to be secured, backed up, or deleted on request. If the studio later needs a CRM or retention policy, that is a real project rather than a setting.
How much does a website like this cost to build?
A catalogue site of this shape — around twenty product types, static product and guide pages, a multi-step quote form with file upload, and custom motion work — sits in our Scale tier, which starts at $5,000 and runs to $10,000 depending on scope. The variables that actually move the number are the count of distinct page templates rather than pages, whether product photography exists or has to be produced, how much bespoke animation the design calls for, and whether content is supplied or written. A catalogue of the same size with stock templates and no motion work is a materially cheaper project than this one, and we would say so rather than quote the same figure.
Why build an editorial homepage instead of a standard ecommerce template?
Because the product is judged by touch, and a grid of thumbnails removes exactly the information a buyer needs. A patch is assessed on stitch density, edge finish and how a material behaves in the light, none of which survives a 400px product card. The homepage is built as eight independent chapters that move a visitor from a flat drawing to an inspected object in the order the studio actually works. Keeping each chapter a separate component is what makes it maintainable — sections can be rewritten or reordered individually, so the page stays editable instead of becoming a bespoke artefact nobody dares touch.
What is deliberately not finished?
Three things, and they are documented rather than hidden. The quote rate limiter is an in-memory counter, which does not survive a serverless instance restart and is not shared between instances -- adequate as a speed bump, not as durable abuse control. There is no automated test suite, so verification is typecheck, lint, build and manual browser testing. And submitted briefs are not persisted anywhere, so there is no CRM, retention policy or deletion workflow. Each of those is a defensible scope decision for this project, and each becomes a real requirement if volume or obligations change.
Catalogue drifting out of sync?
If your products live in the menu, the sitemap, the quote form and the CMS separately, they are already disagreeing. We make one of them the source and derive the rest.
What other clients said
Different projects, different people. Each one links to the review on Trustpilot so you can read it in full rather than take the excerpt on trust.
“I was hesitant at first because the price seemed more than reasonable and I had never heard of them. I am so glad I chose to work with them.”
“Hassan was super helpful and communicative throughout the process.”
“They worked with me to make a website that I could afford.”
“Hassan was available to me at any time, and his response time was always less than an hour.”