Sunaulo Shopping — Nepal Marketplace

The problem

Four audiences, one set of data. A shopper wants to browse and buy. A seller wants to list, track stock and be paid. A franchise network needs distribution and its commission. Staff need moderation and operations. Build those as four products and they drift; build them as one and every change has to be right for all four.

On top of that, the market is Nepal, which rules out the defaults. International cards are not how people pay, and a meaningful share of users are slow to update an app.

What was built

A React Native shopping app for iOS and Android, a Next.js admin dashboard, and a GraphQL backend, in one Lerna and Yarn Workspaces monorepo with shared internal packages for theme, utilities, Firebase, S3 and Algolia.

Product discovery works by text and by image through Algolia, with multi-level filtering on size, colour and category. There is a "Sunaulo Coin" loyalty layer, OTP sign-in through Sparrow SMS, push via Firebase, and seller stats, payouts and franchise earnings tracked through the admin. Payments are eSewa and Khalti with cash on delivery as the fallback. Media sits on S3 behind CloudFront with on-the-fly resizing; the services run on Docker and AWS ECS.

What I owned

I worked on Sunaulo Shopping as a full-stack developer, across the React Native shopping app, the Next.js admin and the GraphQL services between them.

Working across all three is what made the monorepo decision below feel obvious rather than clever: a change to the data contract is one change, in one place, that lands everywhere it needs to.

Key decisions

One monorepo, not four repositories. Mobile, admin and backend live together, which means a change to the data contract lands in the app and the admin in the same pass. Four repositories would have meant four places for the same change and four opportunities for them to disagree — and the drift is never noticed on the day it happens, it is noticed weeks later when something breaks.

GraphQL as the spine. Apollo with types generated by GraphQL codegen, so the contract between mobile, web and backend is one typed thing rather than three implementations of an idea. That is what makes the monorepo pay off instead of merely being convenient.

Over-the-air updates as a first-class release path. CodePush with Fastlane release lanes, because in a market where users are slow to update, a fix that requires a store release is a fix that does not reach people. Shipping through the store is not the only way to ship.

What I'd do differently

Fewer foundations, and treat upgrading them as real work. The monorepo carried a lot of choices, and every one of them had an upgrade path that had to be maintained. Choosing fewer, and planning their upgrades as a first-class concern, would have kept the whole thing easier to move as a unit.

Reach for managed services sooner on the parts that were not the product. Docker, ECS, EC2, S3 and CloudFront were all run by hand. None of that was what made the marketplace good.

Thin end-to-end tests across the seams, early. The risky parts were the joins — image search, two payment gateways, OTA delivery, multi-party payouts — and those were hardened feature by feature instead. Testing across the seams first would have surfaced the awkward cases before production did.