Titustoy

My retail business needed an online store that customers could browse by category, age, and occasion, pay for securely, and track — while staying structured enough to support multiple sellers later without a rewrite.

1. 01Discover products through search, category browsing, age groups, and gift occasions.
2. 02Add items to a cart that persists on the device for guests and syncs once signed in.
3. 03Check out and pay through Razorpay, with payment confirmed on the server.
4. 04Review orders and their payment and fulfilment status.
5. 05Manage products, inventory, orders, and stores from admin and seller dashboards.

• Web storefront

  Live at titustoy.com

  Next.js storefront covering discovery, category browsing, cart, checkout, and orders. Deployed on Vercel.

• Admin & seller dashboards

  Internal

  Tools for managing products, inventory, orders, and stores, with seller-level data isolation and a central super-admin view.

• Backend & data

  Running on Railway

  NestJS APIs with authentication, authorisation, input validation, and PostgreSQL through Prisma. I manage migrations, seeding, and production troubleshooting.

• Mobile app

  Part of the monorepo

  A React Native (Expo) application that sits in the same monorepo and shares packages with the web and API projects.

Shop the way parents think

Alongside toy categories, the navigation offers age groups and occasions — return gifts, birthdays, gift ideas — because buyers often start from a child or an event, not a product type.

Reassurance where decisions happen

Free-delivery thresholds, secure checkout, and dispatch information sit beside the hero, catalog, and cart instead of being buried in policy pages.

Guest-first cart

Visitors can build a cart without an account. The cart explains that it is saved on the device and that signing in syncs it and reuses addresses.

Empty states that move people forward

An empty cart offers a route back into the shop and to the homepage rather than a dead end.

Store-aware from day one

Products, inventory, and orders belong to a store, and queries are scoped by it. This adds work to every query now, but it means a second seller does not require a data migration or a permissions rewrite.

The server decides when an order is paid

Razorpay payments are initiated server-side, verified by signature, and reconciled through webhooks. Order status and payment status are tracked separately, so a closed browser tab or a delayed callback cannot leave an order in the wrong state.

One monorepo, several apps

Web, admin, API, and mobile apps live together with shared packages for types and logic. The tradeoff is more upfront tooling in exchange for a single source of truth when the data model changes.

Managed hosting over custom infrastructure

The frontend runs on Vercel and the backend and database on Railway. For a one-person product this keeps deployment and environment configuration manageable.

• Next.js
• React
• TypeScript
• NestJS
• React Native (Expo)
• PostgreSQL
• Prisma
• Redis
• Python / FastAPI
• Razorpay
• Vercel
• Railway

• Public storefront with product catalog, category browsing, cart, and checkout.
• Razorpay payment initiation, signature verification, and webhook handling.
• Order and payment status management.
• Admin and seller dashboards for products, inventory, orders, and stores.
• Store-aware architecture with seller-level data isolation.
• Authenticated, validated backend APIs on PostgreSQL via Prisma.
• Payment workflows tested end to end; order fulfilment workflows prepared, with a Shiprocket integration planned.

• Treat payments as a sequence of states to reconcile, not a single success callback.
• Deciding where data boundaries sit — per store, per seller — is far cheaper before launch than after.
• Owning the whole product makes trade-offs concrete: every abstraction has to earn its maintenance cost.