Legimus

Most companies lose leads to response time, not to price. Someone asks a question at 2am, nobody answers until the next morning, and by then they bought somewhere else. Legimus is the answer to that: a digital employee that knows your catalog and your policies because you uploaded them, and that replies to your leads with real context instead of a canned script.

I joined at zero and designed the whole system: the multi-tenant dashboard, the backend APIs, the real-time layer, and the agent orchestration underneath.

Model-agnostic on purpose

The single most consequential decision was refusing to build on one LLM provider.

The obvious path in 2025 was to pick a provider, use its SDK, and ship faster. The cost shows up later: pricing changes, a model gets deprecated, a region gets rate-limited, and suddenly a core product capability is somebody else's roadmap. So the orchestration layer treats the provider as a swappable detail. Conversation management, document processing, and context assembly live on our side of that boundary.

It cost more up front. It means we can move a customer between providers without touching the product.

Real time is a product requirement, not a feature

A chat that lags reads as broken, regardless of how good the answer is. The platform runs on WebSockets with Socket.io, and the multi-tenant model is baked into the connection layer rather than bolted on top, so one organization's traffic never leaks into another's.

Building quality gates for AI-written code

This is the part I did not expect to be the interesting problem.

A large share of the codebase is AI-assisted, and AI-assisted code fails differently than human code. It is plausible, it compiles, it reads fine in review, and it quietly drifts from the schema. Reviewing it line by line does not scale.

So I built the gates instead of the review:

• A test suite across unit, integration, and end to end with Playwright.
• Husky pre-commit hooks that enforce lint and type checks before anything lands.
• Automated detection of database schema changes, validating that migrations stay coherent with the schema they claim to describe.

That last one catches the specific failure I kept seeing: a model changes an entity and writes a migration that looks right and is not.

Context engineering as architecture

Agents behave inconsistently across providers when each one gets its own hand-maintained instructions. I centralized the project context into AGENTS.md files that provider-specific configs reference, structured around the constraints agents actually have: limited memory, a real context hierarchy, no reliable recall between sessions.

The result is that switching the assistant does not change how the assistant behaves on this codebase. Same rule for the product, same rule for the tooling that builds it.

Where it stands

The platform is live at legimus.ai with a multi-organization admin dashboard, role-based access control, i18n, OAuth2 flows, payment gateway integrations, and CI/CD on Docker.