Skip to content
Reldava Tech
All work

ReldavaBot

AI chatbots over your own data, built by people who do not write code.

Role
Sole engineer and product owner: architecture, backend, frontend, integrations, billing, deployment
Period
2025 - 2026
Status
Live
Live at
bot.reldava.com

A chatbot SaaS built from scratch for people who do not write code. Every phase started by writing down the rules the product actually had to honour - the limits, the edge cases, the plain-language name for every setting - and only then by building.

The Brain tab of a bot: a model picker showing its per-chat credit cost, next to creativity, reply length cap and memory window fields.
Every control is named in the language of the person buying it - the model line says what a chat costs, not which API it calls.
The Knowledge tab with the add-source menu open: file upload, pasted text, website crawl, Gmail, Outlook, OneDrive, Dropbox and Google Drive.
Documents arrive as an upload, a website crawl or a connected cloud folder - five of the sources are OAuth connections that keep syncing on their own.
The Search tab: a retrieval style preset, hybrid balance, how many chunks to retrieve, how many to use in the answer, and a reranker toggle.
Hybrid search, a reranker and retrieval depth ship as one preset, with the individual knobs left behind it for the rare case someone needs them.
The product page listing document sources and customer channels side by side, with the site widget open and answering a question about channels.
One orchestrator answers on a website widget, a public share link and four messengers - here it is answering a question about itself in the widget.

The constraint that shaped everything

The audience is not technical. That single fact decides the architecture as much as the interface: every setting a customer can touch has to have a sensible default, a plain-language explanation next to it, and a name that means something outside the codebase. Internal names like hybrid_alpha never reach a screen.

It also decides what cannot be deferred. A non-engineer will not debug a failed crawl, so ingestion reports progress as it happens and says what it could not read and why.

Getting documents in

Upload files, paste text, or point the crawler at a website - with sitemap discovery, robots.txt respected and ETag-aware re-crawling, so the second crawl only pays for what changed. Progress streams to the browser while it runs.

Cloud sources arrive through OAuth: Gmail, Outlook, Google Drive, OneDrive and Dropbox, the last of them push-based through a webhook, so a file edited in Dropbox reaches the bot without anyone pressing a button.

Retrieval good enough to sell

Hybrid search per bot, a Cohere reranker, and a configurable preprocessing pipeline - query rewriting, multi-query, decomposition - each of which can be turned on for the bots that need it and left off for the ones that do not.

Tool-calling is selected automatically from the capabilities of the chosen model rather than hard-coded, conversation memory is a sliding window under a hard token cap, and a Search tab lets an operator tune retrieval against real questions and see which passages came back before any customer does.

One orchestrator, four channels

The embed widget, public share links, the in-dashboard preview and Telegram are all the same channel-agnostic core. A channel supplies a transport and a formatting rule; it does not get its own copy of the retrieval logic. WhatsApp, Messenger and Instagram followed the same seam.

The widget is gated by an allowed-domain list, customisable with a live preview, and installs as one script tag. Share links give every visitor their own conversation, with optional lead capture before the first message and thumbs feedback after it.

The parts that make it a business

Stripe billing with plans and quotas that indexing counts against as well as chat. Conversation logs, analytics, captured leads and API tokens in the dashboard. A separate platform-admin application on its own subdomain, whose access list is not application-mutable by design.

And a help bot built from the product manual, running on the product itself - which is the most honest test a chatbot SaaS can submit to.

A rebrand as an exercise in not breaking things

The product was renamed after it was built: a new palette derived from the logo with every contrast pair measured, a mark vectorised from a PNG on a machine with no tracing tools, and 961 occurrences of the old name across 363 files.

The new stack was made startable alongside the old one - every host port, database name, bucket and Docker identity moved - so the two could be compared live rather than swapped and hoped for.

Stack

  • Next.js 15
  • React 19
  • TypeScript
  • Tailwind 4
  • Drizzle
  • PostgreSQL
  • pgvector
  • Redis
  • BullMQ
  • better-auth
  • Stripe
  • OpenAI
  • Anthropic
  • Gemini
  • Cohere rerank
  • Telegram Bot API
  • WhatsApp Cloud API
  • Meta Graph API
  • Docker
  • systemd

Tell me what you are building

A description of the problem is enough to start. If it is a fit I will say what I would build, roughly what it takes, and what I would not do.

Discuss a project