React Native E-commerce App - Thriftverse

The problem

Selling secondhand clothes in Nepal happens on Instagram. A seller posts a photo, buyers reply in DMs, price and delivery get agreed in a thread, and nothing about it is a record. There is no storefront to send someone to, no stock that decrements when an item sells, and no order that exists anywhere after the conversation scrolls away.

The platform had to give a seller the things a shop has — an address, a catalogue, orders that move through states — without asking them to pay for it up front or learn a retail tool.

What the platform does

A seller downloads the app, creates a store, and gets a personalised storefront URL to share. Listing a product is photos, a description and a price; drafts can be written offline and published once there is a connection. When something sells the seller gets a real-time notification, and buyers and sellers message inside the app.

Buyers browse on the web across eight categories and eleven cities, or take a four-question quiz that narrows the catalogue for them. Checkout is eSewa or cash on delivery. Every order goes to Nepal Can Move, which returns a tracking code that reaches the buyer by email — one to two days inside the Kathmandu Valley, two to four days elsewhere.

There are no listing or monthly fees. The platform earns only when an item sells.

What I owned

I worked on this as one of three developers, on the React Native side — the iOS and Android app sellers use to run their store. Both apps are live: App Store, Google Play. The architecture decisions below were the team's rather than mine alone.

Constraints

Three constraints shaped the build, and none of them are the application.

Payments. Stripe does not operate in Nepal. Checkout runs on eSewa, and cash on delivery is not a fallback here — it is what a large share of buyers actually choose, which means an order can be created, shipped and delivered before any money moves.

Delivery. Nepal Can Move is the courier, and an order is not finished when the app says it is — it is finished when NCM says it is. Tracking codes come back asynchronously and have to reach the buyer.

Connectivity. Sellers photograph and list stock wherever they are. Drafting has to work with no connection and publish when one appears, which makes the local draft, not the server, the source of truth until it syncs.

Key decisions

Tenant isolation in the database, not the application. Every seller has their own storefront over one shared marketplace, so a bug that leaks one seller's orders into another's store is the worst thing the platform can do. Isolation is enforced by Supabase row-level security at the database layer rather than by middleware in the application. Middleware is easier to write and one missed query away from a leak; a row-level policy holds regardless of which code path reaches the table.

The corollary is that this is not a decision you can defer. Retrofitting row-level security onto a schema already carrying data means auditing every existing query against policies that did not exist when they were written.

One deployment, dynamic routes — not a deployment per seller. Branded storefronts are served by dynamic route segments in Next.js rather than by provisioning a site per seller. Per-seller deployments would give slightly more freedom per store and turn every platform change into an N-way rollout, with onboarding gated on a build. A single deployment resolving the tenant per request keeps store creation instant, which matters because seller onboarding drops off sharply once setup runs past about five minutes.

Where it got hard

The hardest part of shipping was not the application. It was App Store review.

A thrift marketplace is close to the middle of everything review scrutinises: the listings are created by users, the photos are user-supplied, and money settles outside the app when a buyer pays cash on delivery. Review turnaround is measured in days, so a rejection does not cost an afternoon — it costs the better part of a week, and the changes asked for are rarely ones you can make quickly.

The app is live on both stores now, but review, not the build, is what set the ship date.

What I'd do differently

Work the App Store requirements from the first week rather than the last.

They were treated as a submission step — something to deal with once the app was finished — when they are really a constraint on what gets built, in the same way eSewa and NCM were. Reading the relevant guidelines against the feature list at the start would have moved the same work earlier, where changing it is cheap, instead of into a review cycle where each round trip is days.