TASE Logo
Case study 05 / 20
←All Work
TASE ARCHITECTURE

AstaCollections

The price you see is the price you pay. Checkout built for Pakistan.

Sector
DTC retail · Jewellery e-commerce, Pakistan
Role
Sole engineer: design, backend, frontend, deployment
Duration
68 days
Year
2026
↓Scroll to explore showcase↓
Asta Collections
DTC retail · Jewellery e-commerce, Pakistan
TASE // 05

●METRICS

By the numbers.

Production telemetry, active capacity, and engineering scale measured in live deployment.

01
0
data models
02
0
API endpoints
03
0
page routes
04
0
UI components
05
0
items in the catalogue grid
06
0
days

01 — What it does


What it
does.

Asta Collections is a direct-to-consumer jewellery store for the Pakistani market. It sells a single brand's catalogue of rings, pendants, earrings, bracelets and sets, priced in rupees, with the two payment methods local shoppers expect: cash on delivery with a configurable advance, and bank transfer against an uploaded receipt.

Shoppers browse and check out as guests or as registered customers, while the business runs the entire catalogue, orders, pricing, content and checkout design from an admin panel without touching code. It is a single-store deployment with two authenticated realms: an admin realm gated at the edge and re-checked inside every admin API handler, and a customer realm that ties a shopper to their own orders and wishlist.

Designed, built and deployed by one engineer in an active window of 68 days.

ARCH
Catalogue with sort, category, price and material filters, sale badges rendered from the product records.
↳Catalogue with sort, category, price and material filters, sale badges rendered from the product records.

02 — Module surface


22
screens.

Every discrete surface designed, engineered, and shipped in production. Zero placeholder concepts — 100% functional software.

22 OF 22 SURFACES SHIPPED
01SURFACE

Home

02SURFACE

Catalogue

03SURFACE

Product

04SURFACE

Category

05SURFACE

Search

06SURFACE

Cart

07SURFACE

Checkout

08SURFACE

Order success

09SURFACE

Order tracking

10SURFACE

Account

11SURFACE

Wishlist

12SURFACE

Admin dashboard

13SURFACE

Orders

14SURFACE

Products

15SURFACE

Categories

16SURFACE

Bundles

17SURFACE

Reviews

18SURFACE

Coupons

19SURFACE

Checkout designer

20SURFACE

Site content

21SURFACE

Navigation

22SURFACE

Settings

03 — Technical highlight


CORE ARCHITECTURE

Money is computed once, on the server

ARCH
Product detail: gallery, live sale countdown, stock indicator and compare-at pricing, every figure derived server-side.
↳Product detail: gallery, live sale countdown, stock indicator and compare-at pricing, every figure derived server-side.

The shopper's cart is treated as an untrusted local cache to be reconciled against the server. Placing an order runs a single database transaction that recomputes every line from the product record (base price plus any selected variant modifiers), validates required options, checks both product stock and per-variant stock, applies coupon rules including per-customer usage caps, and then commits the order, decrements stock, writes an inventory ledger entry, records an order event and books any coupon redemption together. The order either lands consistently or not at all.

The same pricing computation is exposed through a validation endpoint the cart calls whenever it is shown, which is what lets the browser keep a fast local copy while never being the authority on price. The alternative, trusting the client's totals, is precisely the failure the cart's cached prices later demonstrated.

ARCH
Product detail: gallery, live sale countdown, stock indicator and compare-at pricing, every figure derived server-side.
↳Product detail: gallery, live sale countdown, stock indicator and compare-at pricing, every figure derived server-side.

04 — Architecture


SYSTEM TOPOLOGY

How it
runs.

INFRASTRUCTURE RUNTIMEPROD VERIFIED

A single Next.js application on Vercel serves both the storefront and the admin panel. Server Components and route handlers run against PostgreSQL on Neon through Prisma, using a pooled connection for requests and a direct connection for migrations. Edge middleware guards every admin path before the route runs. Media is stored and delivered by ImageKit, transactional email goes through Resend, and Meta Pixel runs in the browser.

CONSTRAINTS: 4 TOTALZERO COMPROMISE
01 / 04ENFORCED

Two authentication realms on one deployment

Admin and customer, each a signed JWT in an httpOnly cookie, with admin additionally gated at the edge. Unauthenticated traffic stays off management routes without a round trip, while guest checkout stays open.

SPEC CONSTRAINT
02 / 04ENFORCED

A key-value settings store behind everything admin-editable

From payment design to site copy. New pricing, payment methods and imagery go live without a schema migration or a redeploy.

SPEC CONSTRAINT
03 / 04ENFORCED

One transaction for the order path

Stock, ledgers and events commit together, so an order never half-commits under concurrent edits or stock contention.

SPEC CONSTRAINT
04 / 04ENFORCED

The media SDK is created lazily

It constructs against credentials that are absent during build-time page-data collection; deferring creation keeps the build green.

SPEC CONSTRAINT
01 OF 04

05 — Integrations


ECOSYSTEM MAP

What it
talks to.

Every third-party API, external boundary, data pipeline, and payment rail hardened and operating in production.

05

GATEWAYS

11+

SERVICES

ZERO UNCHECKED SINKVERIFIED API
  • 01

    Database

    2 SERVICES
    PostgreSQL on Neonthrough Prisma
  • 02

    Media

    2 SERVICES
    ImageKit for storagetransformation and delivery of images and video
  • 03

    Email

    1 SERVICE
    Resend
  • 04

    Analytics

    5 SERVICES
    Meta Pixel: PageViewViewContentAddToCartInitiateCheckoutPurchase
  • 05

    Authentication

    1 SERVICE
    Self-hosted JWT (jose) with bcrypt password hashing

06 — Problems solved


DIAGNOSTIC LOG & ROOT CAUSE ANALYSIS

What broke,
and how we found it.

Feature lists show what was built. These post-mortems show how obscure edge cases and silent production bugs get diagnosed and permanently resolved.

01 / 03RESOLVED IN PROD

The price on the screen was never the price at the till

01 // SYMPTOM

A shopper who added items, then returned after the catalogue had been re-priced, saw the old amount in the bag and all the way through checkout.

02 // ROOT CAUSE

The cart persists in the browser and caches each line's price at the moment it is added. The order route recomputes every price from the database at submit time, so the figure shown and the figure charged could diverge whenever an admin changed a price mid-session.

03 // ARCHITECTURAL FIX

A validation endpoint recomputes the authoritative price for each line exactly as the order route does. The cart reconciles against it every time it is shown, and checkout re-checks at submit: if anything has moved, the shopper is shown the corrected bag and asked to confirm, so the number on the button is always the number charged.

02 / 03RESOLVED IN PROD

The number zero could not be saved

01 // SYMPTOM

Configuring the store for pure cash on delivery, with no advance taken, quietly reverted to the standing default every time.

02 // ROOT CAUSE

The advance amount was read with a truthy fallback, so an explicit zero, being falsy, collapsed back to the default. A blank field could not be told apart from an intentional zero.

03 // ARCHITECTURAL FIX

A single parser shared by the storefront and the server separates the cases: a blank field keeps the historical default, so an untouched store never changes, and an explicit zero means zero.

03 / 03RESOLVED IN PROD

Product images failed because two services had to talk to each other

01 // SYMPTOM

Product thumbnails disappeared across the catalogue in a way that read like broken links.

02 // ROOT CAUSE

Delivery ran through a chain: a built-in image optimizer in front of a transformation service, which fetched the source bytes from a separate storage service. The cross-service fetch was the point that failed, so the images looked broken although the source files were intact.

03 // ARCHITECTURAL FIX

The built-in optimizer was replaced with a custom image loader and storage moved into the same service that performs the transformation, so the bytes are served by the service that stores them. Collapsing the chain was chosen over adding retries, because removing the dependency removes the whole class of failure.

01 OF 03

07 — Stack and outcome


CORE TECH TOOLKIT // 14 DEPENDENCIES

Built
with.

Every dependency is chosen deliberately for raw execution speed, strict type safety, zero cold-start latency, and battle-tested reliability under high concurrent load.

  • Next.js 16
  • React 19
  • TypeScript
  • PostgreSQL (Neon)
  • Prisma
  • Tailwind CSS
  • Zod
  • jose
  • bcrypt
  • Resend
  • ImageKit
  • Zustand
  • GSAP
  • Vercel
// COMMERCIAL & OPERATIONAL OUTCOME
MEASURED IMPACT

"A storefront where the price you see is the price you pay, with checkout built around how money actually moves in Pakistan, and an admin panel the business runs itself."

Status: 100% Operational & Scaled
TASE ARCHITECTURE VERIFIED ✓
NEXT PRODUCTION ENGAGEMENT

Have one
like this?