# NADILI: Product
Source: https://manaienko.com/projects/nadili/product/
Author: Artem Manaienko

# Website, CRM
_and backend._

I design and integrate NADILI's public website, private CRM, backend and worker system for practical answers that change over time.

**Website:** Search, answers, paths and email follows

**CRM:** Knowledge, review and publication

**Backend:** API, workers and scheduling

Explore the product

01 Public website **Search, answers and practical next steps** **Website**02 Internal CRM **A workspace for knowledge and publication** **CRM**03 Backend and workers **The processing system behind both applications** **Backend**

Implemented in NADILI. Private, pre-launch.

Public website

## Search, answers and practical next steps

The public website helps people moving between countries find practical answers. It combines search, reviewed explanations, practical paths and email updates in a multilingual interface. Romania is the current country experience.

### What a reader can do

**Search:** Ask in your own words within a country.

**Read:** See an answer with supporting evidence, scope and freshness.

**Act:** Follow paths that organize related answers into practical steps.

**Follow:** Subscribe to country or path updates by confirmed email.

### A question can become new product content

When an answer is insufficient, a reader can submit a verification request. The request has confirmation and processing states. A reviewed answer can later help other readers.

What happens when an answer needs more work?

A confirmed request can reuse a published answer, join a draft or start a draft from eligible knowledge. The workflow separates missing evidence and processing failures from success.

Drafts stay private until human publication. Automatic request resolution is behind an activation flag and disabled by default outside local and test environments. Public launch remains open.

Internal CRM

## A workspace for knowledge and publication

The internal CRM is where I organize topics, review uncertainty, prepare answers and control publication.

### What the CRM manages

**Organize:** Topics, collection scope and processing rules.

**Review:** Claims, retained evidence and a queue for uncertain material.

**Prepare:** Answer drafts, language versions and practical paths.

**Publish:** Validation, preview and explicit human approval.

### Knowledge and publication have separate lifecycles

Incoming information becomes small claims with evidence. Accepted knowledge can support several answers. Editors revise drafts without replacing the published version; publication creates a versioned snapshot.

How incoming information becomes a public answer

Processing filters material and proposes structured claims. Admission rules decide which claims enter accepted knowledge and which need review. The CRM shows evidence and pending decisions.

Answer preparation uses eligible knowledge. Review supports preview, validation and publication; blocked drafts return to editing. The website receives published content through its API contract.

Backend and workers

## The processing system behind both applications

Both web applications use one backend for product rules, access and shared state. Separate workers acquire information, run processing and record progress. Scheduling and delivery continue outside a browser session.

### What runs behind the interfaces

**API:** Access checks, product operations and progress updates.

**Workers:** Acquisition, filtering and bounded AI processing.

**Scheduler:** Due jobs and reconciliation of external operations.

**Delivery:** Persistent email groups, recipient checks and retries.

### Long-running work has its own lifecycle

Jobs and progress persist in PostgreSQL. Eligible work can resume after a restart, and failed attempts have bounded retries. Closing a browser does not erase its work.

How the product parts work together

The CRM submits work through the API. Workers process eligible material and record knowledge and progress. Editors publish answers. The website serves them, and email handles confirmed follows.

The scheduler, workers and API are separate processes using shared durable state. Review and activation gates remain in each workflow; public cutover and autonomous maintenance are separate release steps.

[Back to all six areas](https://manaienko.com/projects/#scope-overview-title)[Next: Architecture ↗](https://manaienko.com/projects/nadili/architecture/)I design and integrate the product, with coding agents supporting implementation.