Javeln
Type
Platform
Status
Active development
Context
Full product — backend, web, admin and mobile
Period
2026
Source
Private
23
backend domain modules
20
agent tools, read and write
4
repositories, one product
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.
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
- 01Architected 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.
- 02Built 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.
- 03Extracted 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.
- 04Every 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.
- 05Stripe Connect integration for vendor onboarding and payouts, alongside a wallet and transaction ledger.
- 06Production 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.
- 07Zod validation on every route boundary, Jest test coverage across the booking, inventory, notification, review and user modules, and Swagger/OpenAPI documentation.
- 08Delivered the clients too: a Next.js web app (including full light/dark/system theming), an admin console, and a React Native mobile app.
The decisions worth talking through: where the interesting work was choosing between options, not writing the code.
Note 01
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.
TypeScript / Node.js / Express / MongoDB / Zod / Stripe / Claude / Gemini / OpenTelemetry / Socket.io / Next.js / React Native