Home
Ashavid
Back to Portfolio
Built by AshaVidE-commerce / Consumer BrandBuilt 2026

Upside Tree

A premium e-commerce platform where the cultural design language was not decoration on top of a storefront, but the reason the storefront needed to be custom-built.

Live productSource
StorefrontAdminSettings in DBPostgreSQL
Configuration lives in the database, so operating the store needs no deploy.

  1. Interface

    What the user touches

    • Next.js
    • Zustand
    • Tailwind CSS
    • Framer Motion

  2. Application

    Where the rules run

    • TypeScript

  3. Data

    What persists

    • Supabase / PostgreSQL

  4. Platform

    What it runs on

    • Stripe

A compact view of the venture

Venture
Upside Tree
Category
Bilingual e-commerce
Stage
Live platform
Core challenge
Cultural identity that templates could not express
Our role
Product design and full-stack build
Focus areas
Commerce architecture, i18n, admin tooling, checkout

Why we started building this

Upside Tree started from a brand with a specific point of view: a Persian identity rooted in pre-Islamic Iranian visual culture, sold to an audience split across two languages and two reading directions.

The obvious path was a hosted storefront. We took that seriously before rejecting it. The blocker was not cost or capability — it was that the parts of the experience carrying the brand were precisely the parts a template treats as fixed furniture.

So the question became narrower and more answerable: what is the smallest custom platform that gives full control over presentation and merchandising without turning every future copy change into an engineering ticket?

Off-the-shelf storefronts are fast until the thing that makes your brand different is the thing the template will not let you change.

What we built

A full commerce platform built on Next.js App Router with Supabase as the data layer, covering the storefront, a bilingual content system, a complete admin dashboard, and a custom purchase flow with Stripe.

  • Bilingual by architecture

    English and Persian are first-class throughout — content, layout direction, and admin-managed copy — rather than a translation layer bolted onto an English store.

  • Database-driven settings

    Branding, SEO, payments, shipping, and transactional email are stored as data and edited through the admin UI, so operating the store does not require a deploy.

  • Custom purchase flow

    Multi-step cart and checkout with guest support, coupon validation, and transaction state that survives interruption.

  • Admin dashboard

    Products, collections, media, customers, and global configuration managed from one operator surface.

  • Loyalty system

    Points and rewards for registered customers, modelled in the database alongside orders.

Why this needed to exist

  • A bilingual store is not a translated store: layout direction, typography, and content length all change with the language.

  • The brand’s visual identity was the product differentiator, and template systems constrain exactly that surface.

  • Every hardcoded setting becomes an engineering request later — store configuration had to live in the database from day one.

  • Checkout is where custom builds usually fail, so the purchase flow needed to be the most conservatively engineered part of the system.

  • The store had to be operable by a non-engineer without a deploy pipeline in the loop.

How we framed the opportunity

The build decisions all traced back to a single question: which parts of a commerce platform genuinely benefit from being custom, and which parts should lean on infrastructure that already works?

Custom where the brand lives, standard where money moves

Presentation, merchandising, and content are bespoke. Payments run through Stripe rather than anything hand-rolled.

Configuration is data, not code

Anything an operator might reasonably want to change was modelled as a database row with an admin surface, not a constant in the source.

Language is a layout concern, not a string table

Treating Persian as a full locale — direction, type, spacing — rather than swapped strings avoided the broken-mirror feel of most bilingual stores.

The admin panel is the actual product for the operator

A storefront nobody can update without a developer is a liability. Admin tooling got the same design attention as the customer-facing pages.

Where the existing options fell short

What hosted platforms gave

  • Fast setup, proven checkout, and a plugin ecosystem.
  • Reasonable defaults for catalogue, inventory, and order management.
  • Enough flexibility for a store whose differentiation is its products rather than its presentation.

What they could not give

  • True bilingual layout rather than a translation plugin.
  • Control over the visual language that carried the brand identity.
  • A settings model shaped around this store rather than a generic one.
  • Freedom to design a purchase flow around the actual customer journey.

The decisions that shaped the product

Make the database the source of truth for the store

Products, collections, settings, and copy all live in PostgreSQL. The application reads configuration rather than embedding it.

Treat both languages as equal citizens

No primary locale with a secondary translation. Both directions were designed and tested as first-class paths.

Keep the risky parts boring

Payments, auth, and persistence use established infrastructure so that engineering attention could go to the experience layer.

How it came together

  1. Phase 1

    Schema and commerce primitives

    Model the catalogue, orders, customers, and settings in PostgreSQL first, so the UI could be built against a stable shape.

  2. Phase 2

    Storefront and bilingual system

    Build the customer-facing experience with locale handling, cart state in Zustand, and the brand’s visual language.

  3. Phase 3

    Admin surface and checkout

    Ship the operator dashboard and wire the Stripe purchase flow with coupon validation and guest checkout.

Where the product stands today

  • A live bilingual storefront with English and Persian as equal locales
  • A complete admin dashboard covering products, collections, media, customers, and settings
  • Store configuration editable without a deploy
  • A working Stripe checkout with guest support and coupon validation
  • A loyalty points system modelled alongside the order data

What building this taught us

  • Build custom only where the differentiation actually lives.
  • Configuration that is not editable by an operator becomes an engineering backlog.
  • Bilingual is a layout problem long before it is a translation problem.
  • The admin panel deserves the same design care as the storefront.
  • Payments are the wrong place to be original.

We build the products we would want to operate ourselves.

Upside Tree is one of the ventures we design, build, and run in-house at AshaVid.

Talk to usBack to portfolio