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

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.