Javeln
A services marketplace built end to end: a 23-module TypeScript backend with an agentic AI assistant, plus web, admin and React Native clients.
23
backend domain modules
20
agent tools, read and write
4
repositories, one product
// stack
// architecture
23 domain modules on Express + TypeScript + MongoDB · agentic AI assistant with 20 tools, staged writes and an audit trail · pluggable LLM provider (Claude or Gemini) behind one interface · Stripe Connect payouts · OpenTelemetry + Sentry + Pino→Loki · Socket.io chat · Next.js web and admin, React Native mobile
// overview
A complete product I architected and built across four repositories. The backend is a modular TypeScript and Express service with twenty-three domain modules — bookings, services, inventory, wallet, payouts, chat, social, stories, reviews, search, explore, notifications and admin — on MongoDB, with Stripe Connect for vendor payouts, OpenTelemetry instrumentation, Sentry, structured Pino logging shipped to Loki, and Zod validation throughout. The most interesting part is the AI module: an assistant with twenty tools that can actually act on the platform, behind a provider abstraction that makes the model a config choice rather than a code choice, and a staged-write mechanism so any mutating action is proposed and confirmed rather than executed silently.
// what was built
- ·Architected a 23-module TypeScript backend covering bookings, services, inventory, wallet, payouts, chat, social feeds, stories, reviews, search, explore, notifications, reports and admin — each module owning its own routes, controllers, services, models and validators.
- ·Built an agentic AI assistant with twenty tools that can read platform state and take real actions — create a booking, block a time slot, update availability, mark a booking complete — rather than only answering questions.
- ·Extracted an LLMProvider interface so the model backing the assistant is a config choice, not a code change: Claude and Gemini both sit behind one contract, with a schema converter per provider because their tool-definition formats genuinely differ.
- ·Every mutating tool call goes through a staged-action mechanism with an explicit confirmation step and a persisted audit trail, so an agent can never quietly change someone’s bookings or money.
- ·Stripe Connect integration for vendor onboarding and payouts, alongside a wallet and transaction ledger.
- ·Production instrumentation from the start: OpenTelemetry traces and metrics, Sentry error tracking, structured Pino logging shipped to Loki, request-level rate limiting, Helmet and mongo-sanitize hardening.
- ·Zod validation on every route boundary, Jest test coverage across the booking, inventory, notification, review and user modules, and Swagger/OpenAPI documentation.
- ·Delivered the clients too: a Next.js web app (including full light/dark/system theming), an admin console, and a React Native mobile app.
// engineering notes
The decisions worth talking through
The parts of this project where the interesting work was choosing between options, not writing the code.
Agents that write need a staging step
A read-only assistant is a search box with better manners. One that can create bookings, block slots and change availability is operating on real money and real calendars, where a confident wrong tool call is a support ticket. Staging every write as a proposal that must be confirmed — and logging both the proposal and the outcome — is what makes the capability shippable rather than a demo.